Distillation concentrates error as efficiently as signal. The memory that makes your agent useful is rotting, and no search index will save it. Part 3: consolidation as a first-class engineering practice.
In early June I watched my own system describe last month with total confidence.
The state file, the one I told you in Part 2 was "the freshest thing in the repo," had grown into a wall of text. Finished work sat next to live work with nothing marking the difference. Notes from abandoned directions read as current plans. And the agent reading it did exactly what I had spent months teaching it to do: it trusted the curated file over everything else. I had built a system where curated text outranks found text, then let the curated text go stale. The agent wasn't malfunctioning. It was obeying a memory that no longer described the world.
Nothing shipped broken that day. But I sat with how close it had come, and with the realization that ties this whole series together:
Distillation concentrates error exactly as efficiently as it concentrates signal.
The raw pile of context is inefficient but humble. It invites verification. The summary is efficient and authoritative, which forecloses verification. That's the entire point of a summary, and it's also the threat. A wrong confident summary is worse than no summary at all, and every summary is en route to wrong. Not because anyone blunders. Because time passes.
Part 1 of this series argued for optimizing the new-chat experience. Part 2 argued that the real problem is salience, knowing which text governs, and that salience is created by curation, at write time. This post is about the part I got wrong for the longest: write time never ends. Curation isn't an act. It has to be a metabolism.
Biological memory has the same problem mine had. A day of experience is a raw pile: vivid, redundant, mostly noise. What the brain does about it happens largely while you're unconscious. Consolidation. Important connections get strengthened, noise gets pruned, short-term experience gets promoted into long-term structure. And when the process is denied, when a human goes long enough without sleep, the failure mode is eerily specific. They don't just get slow. They confabulate. Confident, fluent claims about things that aren't real.
An agent system running on additive, unmaintained context degrades the same way, and once I saw that, the name was unavoidable. My system sleeps.
Here's the system, by the way. Its name is Rico. Readers of the Dory post have already met the idea of naming your collaborator; Dory was the framing, Rico is the thing I actually built and work inside of every day. Rico persists across sessions through exactly the file structure Parts 1 and 2 described (an instruction file, state, decisions, lessons, architecture, work items) and none of it would survive a month without the part I'm about to describe.
Two protocols carry essentially all of the weight:
The nap. Light consolidation, after any meaningful unit of work. Update the state file to reflect reality now. Move what finished out of "in flight." Record any decision that got made and any lesson that drew blood, including the negative findings, the alarms that proved false, so they can't regrow. Commit. Ten minutes, maybe. The contract a nap fulfills is simple: a fresh session tomorrow picks up without re-learning what just happened.
The deep sleep. Every dozen-or-so units of work, a different kind of pass. Not appending but refactoring the memory itself. Distill the state file back down from a wall to a page. Promote patterns that keep recurring out of individual lessons and into the architecture file, where they become structure instead of anecdote. Archive completed work out of the hot path. Challenge the summaries against reality: is this still true? Then verify the result the same way Part 1 verified a repo. Could a stranger load one file and know where things stand?
Naps keep the memory current. Deep sleeps keep it small and true. Recall was never the goal; search already recalls. What sleep maintains is everything search can't: salience, compression, trust, and forgetting.
Beyond those two, Rico's sleep vocabulary keeps going (siestas, REM cycles that generate honest self-critiques I call dreams, a once-ever restructuring I called a molt) and I want to be straight with you about where the line is. Naps and deep sleeps are patterns. I'd bet on some version of them existing in any long-lived agent system, whatever they get called. The rest is autobiography: my system, my temperament, genuinely useful to me, and exactly where I stop claiming any of this generalizes. I mention them mostly as an existence proof that once memory maintenance works, you start finding more things worth maintaining.
I've been using "sleep" for a while now, and I owe you the place where the metaphor breaks, because the break is load-bearing.
Biological sleep is involuntary. Nobody chooses what the hippocampus keeps. Consolidation just happens, and no one is accountable for its edits. Rico's sleep is nothing like that. Every nap and every deep sleep is an editorial pass with rules I wrote, running on triggers I set, producing diffs I can read. And the significant consolidations happen with me in the loop. Somebody decides what gets kept. That somebody has a name, and it's in the git history.
So: it isn't really sleep. It's an editorial process with a bedtime.
I keep the word anyway, partly because "Agents Need Editors" is a worse title, but mostly because the biological framing gets the rhythm right. Downtime as a first-class phase of work. Degradation as the price of skipping it. What the word hides, and what I want to say outright, is the governance: consolidation is where memory gets decided, and whatever survives between sessions will govern future action, so a person has to own the edit. I wrote in Part 2 that "the retrieval system surfaced it" is not an owner. Neither is "the agent consolidated it." I've experimented with letting Rico self-consolidate more aggressively, and I keep pulling back to the same ruling: the human gate isn't a limitation I'm waiting to remove. It's the accountability making the whole thing trustworthy.
One more place the metaphor needs honesty: forgetting. The Dory post's archive rule was never hard delete, and this series has been saying memory must sometimes be forgotten. Both are true, because forgetting done right is about salience, not storage. When a deep sleep prunes something, it leaves the hot path. It stops being pushed at every arriving session, stops governing. But it lands in an archive that's still searchable when a familiar-feeling problem wants its history back. Which is roughly what human forgetting is anyway: mostly retrieval failure, not erasure. The memory hasn't been destroyed. It's been demoted. Hot context stays small and binding; cold memory stays large and available; the sleep cycle is what moves things across the line. And that movement, not deletion, is what forgetting means here.
Step back and the three posts collapse into one claim, and it's the one I actually came here to make.
The tier model in Part 1 already implied it: agent-readiness scales with blast radius, from actively skip this on code that explains itself to non-negotiable on deployed products. Now finish the thought. On repos that matter, the curation (the briefing files, the salience structure, the consolidation rhythm) isn't documentation about the development.
It is the development.
I made this comparison in passing back in Part 1, and it deserves the full version, because we have run this exact experiment before, as an industry. Tests were once garnish: something conscientious people did if the deadline allowed, invisible in the demo, first thing cut. Then systems got big enough to bite, and the culture flipped hard enough that "I didn't have time to write tests" became something you'd hesitate to say in a senior room. Nobody thinks test code is "not the real code" anymore. It's how the real code stays real.
Memory work is on the same curve, one turn behind. When agents do more of the writing, the scarce input stops being the code. Agents produce code abundantly. The scarce input becomes the premises the code gets written from: what matters, what's decided, what's fragile, what's done. Maintaining those premises is engineering. It has artifacts, invariants, failure modes, and a test:
The stale-summary audit. Take your most distilled, most trusted file. The state file, the architecture summary. Diff it against reality, line by line. Every divergence you find is rot that was being injected into every session, with authority, since the last time anyone checked. The first audit is humbling. The interval since the file was last challenged (not appended to, challenged) is your real consolidation cadence, whatever your process document claims it is.
If the divergence is small, your rhythm is working. You have a metabolism. If it's large, that's not a documentation problem. That's the most dangerous file in your repo, and now you know the maintenance was the job.
Every post in this series ended with the problem its solution created. Part 1's briefing file grew until it stopped governing. Part 2's curation solved governance and then met time. Part 3's answer, sleep, a maintained metabolism with a human gate, genuinely holds. It's been holding for months.
So here's what its success created.
Everything in this series assumed one repo and one kind of work. But nothing about rot is specific to code. My email degrades the same way a state file does. Projects, finances, commitments, the dozen coding agents themselves running these exact patterns in their own repos: all of it accumulates context, all of it rots, all of it needs something deciding what's canonical and what's expired and what governs next. And the moment more than one agent-run project exists, a new question appears that no single repo can answer. Something has to sit a level above, orchestrating the agents that work the repos, running the same memory discipline about the work itself.
The pattern, it turns out, nests upward.
I know because I run the thing it nests into. That's what Rico actually is — not a repo convention but an operational second brain, and I change it week to week as it teaches me what it wants to be. But that's not a pattern yet. That's a life, and it's another post.
Just keep swimming. And keep a bedtime.
Part 3 of a three-part series. Part 1: Making a Codebase Agent-Ready. Part 2: When AGENTS.md Isn't Enough.