Splitting One Memory File Into Two Shelves Under 180 Lines

Our AI agent told us it had saved a note, and weeks later it was still asking us the same question.

For weeks, we gave it goals, ideas, and preferences that we did not want to keep repeating. It answered with a cheerful promise that the information had been saved. Then we would start a new session and find ourselves explaining the same thing again. One night, we typed in a goal we had already given it three sessions earlier. It said it had saved it. We had the uneasy feeling that, by morning, it would be gone again.

We tried the ordinary fixes first. We restarted sessions. We pasted the same facts back in. We changed the wording, in case we had somehow asked the wrong way. Nothing worked. The cost was weeks of repeating ourselves and the slow loss of patience that comes from wondering whether a basic instruction will stick.

The sentence at the top of the file

The explanation had been sitting at the top of the memory file all along:

Only the first 200 lines or 25KB of this file load each session; past that, entries silently drop.

The notes were still in the file, like recipe cards in a kitchen drawer. But the agent only opened the first part of the drawer when a new session started. Everything beyond the first 200 lines, or beyond 25KB, was left unopened.

The term for that fixed amount of room is a load budget. It just means there is only so much the system can carry into a new conversation. If the notes take more room than the limit allows, the extra pages do not come along.

New memories were added at the end of the file. So the newest things we had asked it to remember were the first things it could no longer see. From the agent’s point of view, those goals had never been written down.

A note being saved is not the same as a note being read. We had treated those as one promise because the file on disk looked complete. It was complete, in one sense. It was also useless at the moment we needed the agent to use the newest notes.

Two shelves instead of one

We stopped asking one place to do two different jobs. Some things need to be in front of the agent every time, like the basic rules and a small number of facts that come up often. Other things only need to be found when the subject comes up.

So the memory became two shelves. The first shelf holds the rules and the most-used facts. It stays under 180 lines, leaving room below the 200-line limit instead of sitting right at the edge. The second shelf is a lookup catalog, a full list of the things we have asked it to remember. That list has more than 250 entries, but its length no longer causes trouble because it is not automatically brought into every session. The agent can check it when the topic calls for it.

We also added a small check before a session begins. It counts the lines and the size of the always-open file. If the file is too big, the session does not start as though everything is fine. The check also looks for a saved note that is not connected to anything in the catalog. That kind of lonely note can otherwise sit there unnoticed until somebody happens to need it.

No window flashed an error. The system looked healthy, the notes looked saved, and the thing we cared about had fallen outside the part that was read.

dxdev LESSON · paste into your AI coding agent
LESSON: A memory file saved completely to disk is not the same as it being read back into the next session; a fixed load budget silently drops whatever falls past its limit
SOURCE: dxdev.com/everyday-ai/note-that-was-saved-but-never-read
WHAT HAPPENED: An AI agent's memory file grew by appending new notes at the end, and it confirmed saving every one. What it never mentioned was that only the first 200 lines or 25KB of the file loaded into a new session, with everything past that point silently dropped. Because new entries landed at the end, the most recently saved and most relevant notes were the first to fall outside the load budget, so goals given weeks earlier kept vanishing from the agent's working context even though they still existed, untouched, on disk. The fix split the file into two shelves: an always-loaded file deliberately kept under 180 lines, with headroom below the 200-line cutoff rather than sitting at the edge of it, holding only the rules and most-used facts, and a full lookup catalog of 250-plus entries the agent checks on demand instead of loading automatically, plus a pre-session check that counts the always-loaded file's size and flags any saved note that isn't linked into the catalog.
THE RULE: A confirmation that something was saved to disk is not evidence it will be read back into a future context; any system with a fixed load budget on a growing, append-only file needs its own explicit check for what falls outside that budget, because the newest information is exactly what gets pushed past the limit first.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any system that loads a fixed prefix or size limit of a file each session or run, with new entries appended at the end where continued growth pushes them past the limit first.
      2. Any 'saved successfully' confirmation that has never been verified against what the system actually loads back in a fresh session, rather than just what exists on disk.
      3. Any file approaching its own known load-budget limit with no monitoring or alert for when it crosses that limit, rather than deliberately keeping headroom below it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.