AiBook · Jeremy Schoemaker · 2026 · ch-21.html

Your Agent’s Fake Memories

(Spine Ch. 21.)

“When I was younger I could remember anything, whether it had happened or not; but my faculties are decaying, now, and soon I shall be so I cannot remember any but the things that happened.” Mark Twain, Chapters from My Autobiography XIII, North American Review (1907)

Turn 87. The agent is still quoting a wrong assumption it made on turn 3, and it says it with the same calm confidence it uses for facts. Meanwhile every turn drags where it used to snap, the bill has tripled since month one by my own rough count, and nothing new works that didn’t work before. I built that. I gave it perfect memory on purpose, wrote it up as a feature, and told people it was the smart part of the design. It took me three months and a manuscript-review agent hedging across eight rounds of contradictory feedback to figure out what I had actually shipped. The joke at my house is that the home agent knows Georgia’s vet appointments, medication schedule, and the exact brand of food she’ll actually eat, all of which I have forgotten at least once, which is probably why she sleeps next to the Mac Studio now and not next to me.

Figure 21.1: Clark, when asked who he is.

Figure 21.1. I asked Clark, the agent that runs everything in my house and wears my logo on the cover of this book, who he thought he was. He said he was my alter ego and sent this. Nobody trained him on this. Nobody asked for the Speedo. That confidence is the whole chapter in one image. That is what a personality is: a memory nobody verified, held with total confidence. Clark has never been to a beach.

Bottom line: Agents don’t actually remember anything, they carry context. Unbounded context makes them dumber and more expensive. Forgetting (aggressive summarization, pruning, rolling windows) is the feature that keeps them sharp and cheap.


When it bites


The pattern

The agent’s “memory” is not memory. It’s a window. Everything it “knows” is in the current context: past turns, retrieved docs, tool outputs, the works. That window has three problems:

1. It’s finite and you pretend it’s not. A 200K window sounds huge until you add a 40KB log dump, fifty retrieved tickets, and a 100-turn history. You’ve got 30K left for the answer. The agent then chooses between token efficiency and solving the job, and usually picks wrong. I, Jeremy, once shoved a 40KB log dump into an agent’s context because reading the log myself felt like effort, then spent the afternoon wondering why the smartest model on the market had suddenly turned into a guy nodding along in a meeting he did not read the deck for.

2. Old information is indistinguishable from new. Turn 2 guessed the database was down. Turn 200 confirms the app works. Both are in the window. The model has no way to know which obsoletes the other. It remembers everything equally.

3. More context doesn’t mean more knowledge. A 50-turn history is not “better state” than a three-line summary of decisions and current facts. The summary is signal. The history is signal plus noise plus the model’s own earlier confusion. It feels like more, so teams carry it anyway, and it costs more for worse output.

The pattern is: carry only the state that changes the next decision. Drop the rest. Not “remember.” Compress.

This breaks into four moves:

  1. Summarize ruthlessly. A loop that runs 100 turns should not carry 100 turns. Carry: decisions made, state that changed, the one contradiction that matters. Ditch the intermediate tries, the failed branches, the false starts. If you won’t re-read it in 6 months, it’s clutter. My own rule of thumb, learned the expensive way: I have never once, in my life, gone back and read turn 44 of anything.

  2. Prune by relevance window. Recent is more relevant than old. A coding agent working on a file needs the last three decisions, not every edit from the session start. A customer-support agent needs the current ticket’s summary and the customer’s account state, not every interaction since 2023.

  3. Roll the window, don’t fill it. If you have 200K and you’re eating 150K on history, you’re not using context. You’re running in 50K. Cut the history to 40K, open 160K for the real work.

  4. Write the state to disk, then distrust it on the way back in. Compression only helps inside one run; between runs there is nothing, so my /refresh-resume skill ends a session by writing artifacts to disk, and pickup reads them back at the start of the next one.

The rule I had to be taught is in pickup itself: a resume’s facts age well, its diagnoses rot. On 7 August 2026 a resume named a skip reason as bottleneck #1; one GROUP BY showed it was 1.8% of failures and an unmentioned reason was 78%. On 5 September 2026 a resume said rounds should take a minute; one SHOW STATUS found the database at 152 of its 151 connections. Re-measure the one number the priority rests on before you act. Memory you can trust is a dated artifact on disk, written by the thing that had the context, re-checked before anybody moves on it. The ledger discipline that makes those artifacts readable is Ch. 35.


One worked example

Start with the one number I actually earned. My aigate dashboard, for the 30 days ending 8 September 2026, shows the mbp:resume session at 72,286 requests, 8,747.2M tokens, and $4,955.24. Divide it out: about 121,000 tokens and 6.9 cents on every single request. That is the steady-state size of one turn in a loop that carries its history around with it. Nobody decided on 121,000 tokens. It accreted.

Now the shape, and this part is arithmetic rather than a run: I have no dated incident where I shrank a window and caught the cost or latency delta on the way down. I shrank plenty of windows and never once put a stopwatch on one. I am not going to hand you a percentage, because a made-up 40% would be exactly the kind of confident fake memory this whole chapter is about.

Labeled illustration, worked with a calculator: a manuscript-review agent over 20 chapters, 8 rounds of feedback each. Eval version reads the chapter once, produces feedback, done. Prod version carries all eight rounds, each about 2KB. By round 8 that is 16KB of history plus chapter text (12KB) plus system prompt (4KB). The window is not even tight. But the agent has now seen the same chapter eight times in eight contexts, so it starts hedging: “as mentioned in round 3, but also considering round 7’s point…” It is confabulating consistency across contradictory feedback, because both rounds are equally present. It is not dumb, it is drowning. And I was the one holding its head under, on purpose, because I thought eight rounds of context made it thoughtful.

Fix: carry only the active feedback for this round, plus a line-by-line ledger of what changed and why (Ch. 35). Drop rounds 1-7 from history. The agent stops self-contradicting, gets faster, and gets cheaper.


The quiet failure

The loud failure is the overflow: token limits hit, context truncated, visible breakage. The quiet failure is subtler:

You built “perfect memory” and made the agent dumber.

I shipped this exact thing and called it a feature in the changelog. “Full conversational memory.” Two words, one bullet point, 3x the token bill. Shipped by the idiot who wrote the changelog, which was me.

The agent carries everything: full history, all attempts, all mistakes, all contradiction. It “remembers” perfectly and can’t tell which piece is load-bearing. It treats a bad guess from turn 10 as evidence equal to the final state on turn 200. It produces verbose, hedging output that sounds like it’s covering its ass, because it is, across contradictory contexts at once.

Second quiet failure: the cost ramp you don’t notice. The per-request price stays flat and boring while the request itself quietly triples in size, so no line on any dashboard ever turns red; you find out in the monthly total, not in the metric you were watching. Nobody calls it a problem (“it still works”) until the month the bill jumps and performance tanks. In my case, as I remember it, that was month three.

Third quiet failure: the “memory” that’s actually garbage collection neglected. You carry full history because deleting is hard. You tell yourself “we might need it for debugging” for three straight months, and the only thing you ever debug with it is your own decision to keep it. The old history is technical debt with an invoice. It’s the same instinct that filled a 40GB drive with Napster downloads in 1999: grabbing it felt like value, and you played maybe nine of those tracks twice.


Do / don’t

Do

Don’t


Where this sits in the book

Ch. 20 (If You Can’t Measure Done) closed the loop chapter: an agent that knows when to stop. This one opens Part III (Knowledge): what it carries while it runs. Next: retrieval, the move that lets you fetch what you need instead of carrying everything (Ch. 22).


Sources and receipts

Thesis is Jeremy’s (selective forgetting over unbounded memory), kept as practitioner claim, consistent with Ch. 12 (context budget):

Verified:

What I could not verify: