The Scratchpad Is the Memory the Runtime Refuses to Keep

An agent has no memory of its own work. Each session opens with a blank context window, and everything the previous session learned, the approaches it tried and abandoned, the naming it settled on, the reasons behind the choices already made, is gone the moment that session ends. This is not a defect to be patched. It is the shape of how these systems run: the context window is working memory, and working memory does not survive the boundary between one session and the next. The consequence is that a long-running project pays for the same discovery again and again, once per session, unless something outside the runtime carries the knowledge across. A durable store outside the context window, a file in the workspace for a coding agent or a record in whatever datastore a deployed system already runs, is the cheapest thing that can do that, and for most long-horizon work it is also the most reliable. But the store is only half of it. What makes it function as memory is not the store at all. It is the discipline that the agent read it at the start and write it at the end, enforced as mandatory steps rather than left to the model’s judgment.

The cost of a cold start compounds

Start a fresh session on a project of any real duration and the agent does not know what happened yesterday. On any single day that reads as a trivial annoyance, the kind of thing a paragraph of re-briefing would erase, and for a single day it roughly is. The problem is that the cost does not stay flat. It compounds, because each session that starts cold repeats work the last one already finished. A question the team closed three sessions back gets pried open again, because the closing lived only in a context window that has since been discarded. A morning disappears into re-deriving that some approach is a dead end, with nothing on record to say it was already walked. A new name lands crosswise to a convention nobody wrote down anywhere the agent would encounter it. None of these is catastrophic on its own. Together, across weeks, they are a project that keeps relitigating its own past.

The clearest way to see the cost is to set the two ways of operating against each other. In one, every session begins from nothing. The agent carries nothing forward: not the paths already closed, not the vocabulary the team settled on, not the constraints the earlier design decisions impose, so it reasons from scratch and sometimes reasons its way back to a place the project already left. The drift accumulates quietly, and it accumulates faster the longer the project runs. In the other, the agent opens the session by reading a stored record that tells it where work stands, which paths are closed, and which decisions are binding, then picks up from there and, before closing, writes back what changed. A single day separates those two ways of working by very little. A month separates them by the entire difference between a project with continuity and one that is perpetually reintroducing itself to its own history. The scratchpad exists to make the second the default. Its price is a record somebody keeps current. The price of skipping it is rediscovery, re-billed each session, and that tab only lengthens as the project runs.

An external store is the memory the model does not have

The reframe that makes the pattern click is to stop thinking of the scratchpad as notes and start thinking of it as memory that lives where the runtime cannot erase it. The context window is fast, rich, and completely volatile. It holds everything during a session and nothing after. If continuity is going to exist, it has to be stored somewhere the session boundary does not reach, and a durable store outside the runtime is exactly such a place: it survives the reset and is present at the start of the next session regardless of what the last one did. Whether it takes the form of a versioned file or a row in a datastore is an implementation detail beneath that guarantee, and the guarantee is the point. The store is not a convenience bolted onto the agent. It is the persistence layer the agent structurally lacks, supplied from outside.

Placed against the project’s other durable artifacts, the scratchpad occupies a distinct and specific layer. The codebase is the settled truth of what the system is; it changes, but every change is deliberate and reviewed, and it is the authoritative record of behavior. The agent’s standing instructions, whatever layer holds the project’s stable rules and conventions, are the settled truth of how the agent should operate; they change rarely, because they encode decisions meant to hold across every session. The scratchpad is neither of those. It is the layer that keeps moving, the part of the project’s state that changes run to run and has no other home. Current task status, the decision made an hour ago and the reasoning behind it, the approach that looked promising and turned out to be a dead end: none of that belongs in the code, and none of it belongs in the standing rules, because it is not stable and not settled. It is in flight. The scratchpad is where in-flight state lands so that the next session can find it. Understanding it as its own layer, sitting beside the code and the rules rather than overlapping either, is what tells you both what to put in it and what to keep out.

State is what belongs, and code is not state

The content rule follows directly from that layering. The scratchpad holds state, meaning the things that change between runs and cannot be re-derived by inspecting what already has an authoritative home elsewhere. A handful of categories cover most of what that amounts to in practice. Failed approaches come first, because a dead end is expensive knowledge, and a project that does not record where it hit a wall is doomed to re-pay the price of finding it again. Then the vocabulary: any term that carries a specific meaning in this project, because a shared naming convention that lives only in someone’s head is one the agent has no way to honor. Then the choices that shaped the architecture, each kept next to the reason it was made, because a decision stripped of its rationale invites a future session to reverse it the moment that rationale stops being obvious. And finally, where the work actually sits right now: the task underway, whatever is blocking it, the move that comes next, so the next session opens oriented rather than having to reconstruct its own footing. The decision log deserves particular weight. Of everything in the scratchpad, the record of what was chosen and why is the entry that most reliably prevents the most expensive failure, which is a future session quietly undoing a conclusion the project already reached.

Knowing what to exclude matters as much, and the exclusions are not arbitrary; each one is a category that either drifts or endangers. Anything that already has an authoritative home stays out, and the clearest case is code: a snippet copied into the scratchpad is a second version that starts diverging from the real implementation the moment it lands. Once the two disagree, the copy is worse than useless: it is actively misleading, and nothing flags the divergence. When a note needs to lean on something that lives elsewhere, it should point to the location and never carry a duplicate, so a single authority holds and the note merely indexes it. Credentials are excluded on firmer ground than tidiness. A key that lands in a persisted, shareable store is a key surrendered to whatever can later reach that store, and no deletion after the fact reliably takes it back. Anything personal or sensitive about a user is excluded on identical grounds. What keeps the scratchpad healthy is holding workflow state and nothing else, because state is the one thing it exists to carry, and everything else it might collect is either a hazard or a copy of something that already lives elsewhere.

State the agent was never told to read might as well not exist

Here is the failure that quietly defeats otherwise sound implementations of the pattern. A team writes a careful scratchpad, records the right things, keeps the wrong things out, and then assumes the agent will read it. It will not. By default an agent will not hunt for a store nobody pointed it to; it works from the context it is handed and the request in front of it, and a durable memory it has no instruction to open is, from the agent’s point of view, not there. The knowledge is present in the store and absent from the session, which is the same as absent.

Closing that gap requires making the read mandatory, and there are two reliable mechanisms for it, differing in how much they trust the agent to comply. The lighter one is a standing instruction in the agent’s configuration that puts the scratchpad among the very first things to consult when a session opens. This works because the standing instructions load reliably, so the directive to open the scratchpad sits in front of the agent before it does anything else, every time. The stronger one is a lifecycle hook, a piece of deterministic machinery bolted into the harness or the serving loop that pushes the stored state into view before the session so much as begins on a request, taking the agent’s discretion out of the loop entirely. The instruction depends on the agent following a written rule; the hook does not depend on the agent at all. Either is defensible, and on a serious long-running project running both is reasonable, because they fail in different ways and reinforce each other. What is not defensible is the third option, the one teams reach for by default, which is to hope the agent finds the store on its own. The read has to be enforced, by an instruction the agent reliably sees or by machinery that does not ask the agent’s permission, because a memory that is only sometimes consulted is a memory you cannot build on.

The write is the half that gets dropped

The read gets attention because it is the visible half, the moment the memory pays off. The write is where the pattern actually falls apart, because it is the half that feels optional in the moment and is not. Before a session ends, the agent has to update the store to reflect what the session did: the decisions it made, the dead ends it hit, the new position of the current-state entry so the next session opens pointed at the right place. Skip that step and the read at the start of the next session retrieves yesterday’s state, and the continuity the whole pattern promised silently stops working. The read and the write are not two features that happen to sit near each other. They are one mechanism with two ends, and a mechanism connected at one end carries nothing.

This is why the write, like the read, cannot be left to discretion. It benefits from the same enforcement, a standing instruction that names updating the scratchpad as a required closing step, or harness machinery that prompts for it, and it also imposes a genuine demand on the human in the loop, who has to treat the end-of-session update as part of finishing the work rather than as cleanup to be skipped under time pressure. The temptation to skip it is strong precisely because its cost is deferred. The session that skips the write ends fine; the session that pays for it is the next one, which inherits a store that no longer describes reality. The discipline is uneven in exactly the way that makes it easy to neglect, and neglecting it is how the pattern quietly dies.

A memory worth trusting has to stay true

There is a failure mode sharper than an unread or unwritten store, and it is a written one that has gone stale. An out-of-date store is more dangerous than an empty one, and the reason is the same reason the pattern works when it works: the agent treats it as authoritative. That trust is the point. It is what lets the agent skip the rediscovery and act on recorded state instead of re-deriving it. But trust is indiscriminate. The agent has no way to tell a current entry from one that was true last month and quietly stopped being true, so it acts on both with equal confidence. An outdated decision gets honored as if it still held. A convention that was changed weeks ago gets applied as if it were live. Nothing here is the agent malfunctioning; it is doing exactly what a memory is for, standing on the state it was handed instead of re-earning it. The break is not in the agent. It is in a store that quit being accurate without quitting being trusted.

That is what raises accuracy from good hygiene to a requirement the whole pattern rests on. A scratchpad’s value is entirely a function of whether its contents are true right now, because its contents are consumed without suspicion. The read and the write exist in part to keep it true: the write is what keeps the store current, and the store is only worth reading because the write kept it current. The deeper discipline of keeping it lean, pruned, and structured so it stays accurate under sustained use is its own subject, but the principle that governs it starts here, in the recognition that a trusted memory and a stale memory are the same store wearing two different amounts of danger. The moment its contents diverge from reality, every session that reads it inherits the divergence and builds on it, and the cost of that is higher than the cost of never having written it at all.

Memory is an artifact plus a discipline

The scratchpad pattern is easy to underestimate because the artifact at its center is trivial: a durable store the agent reads at the start of its work and writes at the end. The triviality of the artifact is what hides the fact that the artifact is not the pattern. The pattern is the store plus the enforced habit of reading it at the start of every session and writing it at the end, plus the standing that habit gives it as a source of truth the agent can act on without re-deriving. Remove the enforcement and the store becomes a note that sometimes gets read and sometimes gets updated, which is to say a note that cannot be relied on, which is to say not memory. Supply the enforcement and a stateless agent gains something it structurally does not have, continuity across the boundary that discards its context, and the compounding cost of the cold start collapses to a single maintained store. The runtime will not keep the memory. Building the artifact and then holding the discipline that keeps it true is how you keep it instead, and for any project that outlives a single session, that is the difference between an agent that accumulates knowledge and one that keeps starting over.