¶ Pattern: Context Persistence
Type: Pattern
Status: Published
Version: v0.2
Last synthesized: 2026-06-10
Reviewed by: AI-drafted; human content-review pending
Open tensions: 3
An hour of good work. Two participants, one human and one model, turning a vague worry into something with edges — a counter-argument that held, a distinction neither had seen walking in, three half-formed claims worth keeping. Then the tab is closed. The next morning the human remembers that something was figured out, but not the shape of it; the model remembers nothing at all. What was built between them is gone, and the only trace is the feeling that it happened.
This page is about that loss, and about refusing it on purpose.
The loss has a name we use in a project-specific sense: context evaporation — the disappearance of a shared working context once the session that held it ends. It is not forgetting in the ordinary sense. Forgetting decays; evaporation is instant and total on at least one side of the exchange. The model does not fade — it resets. And the human, who does fade, is left holding a context that was never fully theirs to begin with, because half of it lived in the conversation rather than in either head.
So the pattern is simple to state and unglamorous to run: anchor the transient brainstorm to something that persists. Write the insight down, into a store the next session can read, before the session that produced it is gone. Everything operational on this page is a consequence of that one move — and the reason it earns a page rather than a footnote is that the two participants lose context for different reasons, so the anchor has to serve two different absences at once.
¶ The human side is old, and we did not invent it
For the human, anchoring thought to an external store is not new and we do not present it as such. It is one of the better-described moves in the cognitive literature.
The reference is Andy Clark and David Chalmers and "The Extended Mind" (1998). Their thought experiment is exactly the situation this pattern manages. Inga remembers, from biological memory, that the museum is on 53rd Street. Otto, whose memory does not hold, carries a notebook; he reads the address from it and goes. Their claim — the parity principle — is that if a part of the world does a job that, done in the head, we would call remembering, then that part of the world is doing the remembering. Otto's notebook is not an aid to his memory. For the purpose at hand it is his memory, because it is reliably there, automatically trusted, and consulted the way a belief is consulted.
That is the whole human case for Context Persistence in one image. A note vault — a structured store of one's own notes, the practice the field now calls personal knowledge management, the discipline of capturing, organizing, and retrieving what one knows — is Otto's notebook with a search box. The insight written into it last night is available this morning not because the human reconstructed it, but because it was anchored outside the head where evaporation cannot reach it. We name the literature plainly so the pattern is not mistaken for a discovery: persisting human context is a solved problem with a thirty-year theory behind it and a crowded market of tools in front of it.
What is not solved is the other half.
¶ The agent side is new, and it fails differently
Run the same move for the model and the theory stops fitting, because the model's loss is not Inga's gradual fade and not even Otto's clinical one. It is structural, and it has two distinct failure modes that the word "memory" tends to blur together.
The first is the reset. A model with a system prompt and a tool set begins each session with whatever context it was handed and ends with that context gone — there is no continuous self that carries yesterday's conversation into today's. For the agent, evaporation is the default condition, not an accident. This is the absence the Newcomer Protocol already pointed here to fill: the agent's competence in this practice is "reconstructed at the start of every session, from artifacts the network maintains." Context Persistence is the maintenance of those artifacts.
The second failure mode is subtler and it is the reason "just keep everything in the context window" is the wrong fix. Even within a single long session, before any reset, a model does not hold a large context uniformly. Chroma's 2025 report, "Context Rot", tested eighteen frontier models and found performance degrading as input length grew — even on deliberately simple retrieval tasks, the ten-thousandth token is not handled as reliably as the hundredth. The relevant claim from three sessions ago does not just survive less well in a longer window; it can be actively crowded out by the volume of context around it. So the naive anchor — append everything, never prune, let the window be the memory — does not persist context. It dilutes it. This is where the pattern hands off to its sibling, the Pattern: Context-Window Economy: persistence decides what survives, economy decides what is loaded back in, and a store that ignores the second produces a perfectly preserved context the model can no longer read.
Put the two together and the agent-side anchor is doing something the human-side anchor never has to. Otto's notebook can grow without bound; Otto reads only the page he needs. A model handed its entire history every session is not Otto consulting a page — it is Otto forced to re-read the whole notebook, cover to cover, before every question, and getting worse at it the thicker the notebook gets. The persistent store for an agent is therefore not a transcript. It is a curated surface: the insights that survived the friction, written in a form the next session can load selectively rather than wholesale.
¶ What the anchor actually is
Stated operationally, the pattern is a discipline with three obligations, and the implementation is deliberately boring — the boredom is the point, because a persistence layer that is clever is a persistence layer that will not be run.
- A capture moment, inside the session, before it ends. The insight has to be written while the context is still live, because reconstruction after evaporation is exactly what the pattern exists to avoid. In a running stack this is the moment a brainstorm is committed to a persistent store — a database holding the structured record, a note vault such as Obsidian holding the human-readable one. Which tool is incidental and will change; the obligation does not.
- A form both participants can read. The human reads prose; the model reads tokens it can weight. The same insight has to land in the store as something a person will recognize next morning and as something a model can be handed next session without drowning. A store legible to only one of the two has anchored the context for one participant and let it evaporate for the other.
- A selection rule, not an accumulation rule. Because of context rot, the store cannot be a log that only grows. Something has to decide what is worth keeping — which insights survived the friction — and the Pattern: The Shared Ledger of Knowledge is where that decision is given structure. Context Persistence raises the requirement; the ledger is one answer to it.
None of these three is hard to build. All three are easy to skip under deadline, and skipping any one returns the network to the closed tab.
¶ Where this is still thin
Three tensions stay open, and naming them is better than papering over them.
First, the selection rule has no settled criterion. "Keep what survived the friction" is a principle, not a procedure — and a store that keeps too little loses the insight, while a store that keeps too much rots the context it was meant to preserve. Where the line sits, and whether the human or the model should draw it, we do not resolve here. An anchor calibrated wrong fails as quietly as no anchor at all.
Second, a persistent store is also a persistent liability. Everything Context Persistence preserves, it preserves indifferently — including the session's mistakes. An anchored error does not evaporate; it waits in the store to be loaded back into the next session as though it were knowledge, which is the failure the handbook treats under Anti-Pattern: Context Poisoning. The same discipline that saves the good insight saves the bad one, and the pattern as stated has no immune system.
Third, there is the question the pattern raises and cannot answer: whose context is it. When an insight forged between a person and a model is anchored in a shared store and reloaded into both sides next session, the ownership of that insight stops being obvious — a tension the handbook carries forward to The Epistemic Ownership Dilemma. Note that no empirical study has been located on context-persistence practices in human–AI learning networks specifically: the human-side (PKM) and agent-side (context engineering) literatures exist separately, and their joint application here is project practice rather than a documented finding.
The pattern, then, is not a solved storage problem. It is the recognition that a good hour between a human and a model leaves nothing behind unless someone, before the tab closes, decides what was worth anchoring — and accepts that the same anchor will hold the errors too.
¶ References
- Andy Clark and David J. Chalmers, "The Extended Mind," Analysis 58, no. 1 (1998): 7–19. The parity principle and the Otto/Inga notebook thought experiment — the foundational case that a reliably consulted external store can do the cognitive work of memory. Overview and primary claims: https://en.wikipedia.org/wiki/Extended_mind_thesis
- Personal Knowledge Management — the discipline of capturing, classifying, storing, retrieving, and sharing one's own knowledge; the "second brain" / external-memory practice. Institutional guide (Massachusetts General Hospital Libraries): https://libguides.massgeneral.org/c.php?g=1439663&p=10691666
- Kelly Hong, Anton Troynikov, and Jeff Huber, "Context Rot: How Increasing Input Tokens Impacts LLM Performance," Chroma Technical Report (July 2025). Eighteen frontier models show non-uniform degradation as input length grows, even on simple retrieval tasks — the basis for why a persistent store must be curated rather than appended. https://www.trychroma.com/research/context-rot
↑ Back to Part III — Protocols and Practices · Handbook · Home