MemoryPatternProven

Externalized state

Also called: state offloading, filesystem as memory

Externalized state keeps the durable facts of a task in files rather than in the conversation, so the window holds pointers instead of being the record. It is what makes a long task survive a context that cannot.

James Phoenix
Understanding Data Updated July 26, 2026

A context window is the worst place to keep anything you need later. It is finite, it is lossy the moment you compact it, and it disappears when the session ends. Yet the default way people work treats the conversation as the record of what happened.

Externalized state inverts that. The plan lives in a file. Decisions live in a file. Progress lives in a file. The window holds the current task and pointers to the rest.

What changes

Text
plan.md          what we are doing and why, updated as it changes
decisions.md     what was chosen, what was rejected, and the reason
progress.md      what is done, what is next

The agent reads what it needs and writes back as things change. Nothing important depends on the conversation surviving, which means the conversation is now free to end.

Why it fixes several problems at once

  • [Context rot](/context-engineering-dictionary/context-rot) stops mattering. When the durable facts are on disk, a bloated window is an inconvenience rather than a loss. Clear it and reload.
  • Handoff becomes free. A new session reads three files and is caught up. There is no summarising step to get wrong.
  • Decisions stop being re-litigated. A rejected approach written down with its reason does not get re-proposed every time history is compacted away.
  • It is inspectable. You can read what the agent believes, and correct it, which you cannot do with a summary buried in a transcript.

Getting it right

  • Write at decision points, not continuously. Files updated every turn become noise and cost tokens to re-read.
  • Keep them short enough to reload whole. If decisions.md grows past what you would paste into a window, it needs splitting or pruning.
  • **Record the *why*.** "Chose Postgres" ages badly. "Chose Postgres because we need transactional writes and already run it" survives the next agent asking why not SQLite.
  • Treat them as the source of truth. If the file and the conversation disagree, the file wins, and the agent should be told so explicitly.
Tip
The strongest signal that a task needs externalized state is finding yourself explaining the same background again after a compaction. That is not a prompting problem. It is state living in the wrong place.

Related terms

Engineering context for real systems?

Getting the right information into the window at the right time is most of the job. If you want that thinking applied to your product, that is what I do.

See how I can help