The 200-Line Lie: Why My Agent Kept Forgetting My Goals

For weeks I had the same quiet frustration. I’d tell my agent to remember a goal, an idea, a preference. It would say it saved it. And the next session it would act like the conversation never happened. I’d repeat myself, it would save again, and the cycle continued. I started to assume this was just what long-running AI was: confident in the moment, amnesiac the next morning.

I was wrong about the cause, and the real one is worth a post because anyone building on these tools will hit some version of it. The memory file was correct on disk and wrong in practice.

What was actually happening

My setup gives the agent a persistent memory: a plain text file it reads at the start of every session and appends to as it learns things about me and my work.

The harness only loads the first 200 lines (or 25KB, whichever it hits first) of that file into context at startup. Everything past that boundary never reaches the model. No error. No warning I noticed. The file on disk was complete and correct. The agent just never saw the bottom of it.

And because new memories were appended to the end, the newest things I saved were exactly the ones falling off the invisible edge. The agent wasn’t ignoring my goals. It literally could not see them. From its side, they had never been written.

That is the failure mode worth naming: not a crash, but a silent gap between what you believe is stored and what the system actually reads.

The fix: two tiers and a guard that yells

Split the store into two tiers. One tier is an always-loaded policy: only the core rules and high-frequency facts, deliberately kept under the load budget with headroom so it never spills past the cap. The other is a lookup store, a complete catalog of everything (mine is up to 257 entries) that is never auto-loaded, so its size doesn’t matter. The agent reaches into it when a topic comes up. “Always present” and “fetch when relevant” are two different jobs, and cramming them into one file is what broke.

Make the silent failure loud. The guard is a short script that counts the always-loaded file’s lines and bytes, compares them against the cap, and exits with an error if it’s over, or if a stored memory exists that nothing in the catalog points to (an orphan you’d only find by luck). It converts an invisible degradation into something that stops me. If a system can silently drop your data, the first thing to build is the thing that refuses to let it.

The lesson worth keeping

Every byte you hand a model competes for a fixed budget, and the boundary is usually enforced quietly. Truncation, summarization, eviction: most of it happens without a stack trace. Two rules I’m keeping.

First, never trust “it’s saved” to mean “it’s loaded.” Those are different claims, and the gap between them is where weeks of frustration hide.

Second, separate state from context. State is everything you’ve persisted; context is the slice the model actually sees this turn. Budget that slice like the scarce resource it is, and give the agent a reliable way to fetch the rest on demand.

I’d been blaming the model for being forgetful. I’d built it a memory it was structurally unable to read past line 200.

dxdev LESSON · paste into your AI coding agent
LESSON: The 200-Line Lie (silent memory truncation)
SOURCE: dxdev.com/blog/the-200-line-lie
WHAT HAPPENED: A long-lived agent memory was a plain file read at session start and appended to over time.
The harness only loaded the first 200 lines / 25KB of it into context; everything past that boundary never
reached the model, with no error raised. Because new entries were appended to the end, the newest saved
facts were exactly the ones dropped. The file on disk was complete and correct; the model just never saw
the bottom of it.
THE RULE: Persisted state is not loaded context. Any long-lived, growing memory / context / system-prompt
that loads under a cap will silently drop whatever falls past that cap, newest-first if you append at the end.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Every long-lived memory/context/system-prompt source has a known HARD load limit (lines, bytes, or tokens) that is checked, not assumed from on-disk size.
  2. Append order is reconciled with truncation order: new writes do NOT land in the region that gets dropped at load.
  3. The always-loaded context is split from an unbounded read-on-demand store, so growth never pushes live content past the cap.
  4. A guard fails loudly (non-zero exit / hard error) when the always-loaded tier exceeds its budget or when a stored item is unindexed/orphaned.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.