Context is a budget, memory lives outside it
An agent's attention is finite and gets worse as the window fills. Keep only what matters in view, load the rest when needed, and write long-term state to files.
More tokens is not more memory
It is tempting to think a big window means the agent can hold everything. Anthropic's context engineering guide says otherwise. Context is a finite attention budget, and as the token count grows the model gets worse at using any one part of it. The guide calls this context rot.
The goal is therefore the smallest set of tokens that carries the most signal. That changes how you write a system prompt: not a pile of rules for every case, but instructions at the right altitude, a few canonical examples, and tools that do not overlap. The guide prefers a couple of good examples over a long list of rules.
Every tool result adds to the pile, which is why the previous lesson cared so much about output size.
Load it when you need it
The first habit is not to load things in advance. Instead of putting a whole codebase into the window, the agent holds references, such as file paths, and loads them at runtime. When it needs the contents, it calls a tool and reads just that part.
This is just-in-time loading: look up the file that matters, read it, move on. The guide notes that the best setups are often hybrid: a little loaded up front for speed, the rest fetched at runtime.
Notes outside the window
A long task outlives any window. The answer is to write down what matters somewhere the next turn can find it. Anthropic's guide names structured note-taking as the agent's external memory.
The harness team showed what that looks like. Each session starts with no memory at all, so the first session creates a progress log, an init.sh script, a first git commit and a JSON list of features, all marked failing. Every later session reads the log and the git history, runs a basic end-to-end check, and then does one feature. It may only flip a passes field. The team chose JSON because models overwrite it less readily than Markdown.
Ralph, the bash loop, applies the same idea more bluntly: each iteration starts with a fresh context and learns the state from a plan file on disk.
Managed Agents goes one step further. The session log is append-only and lives outside both the model and the harness, so a crashed harness replays it and carries on.
$ cat progress.md✻ Done: parser handles nested lists✻ Next: fix table alignment, then run the full suite> read progress.md and continue✻ Reads the log and the last commits✻ Runs the smoke check, then starts on table alignment# The agent did not remember. It read.
Why does the long-running harness start every session by reading a progress log and git history?
What compaction does
Sometimes you cannot avoid a long single session. Compaction is the harness summarising the conversation and starting a fresh window from that summary. In Claude Code the summary is kept together with the five most recently touched files.
It is a lossy copy. Anything the summary leaves out is gone from the window, which is exactly why important facts belong in a file. A decision written into a notes file survives; a detail you only mentioned in passing might not.
The other tool for the same problem is the subagent. It may spend tens of thousands of tokens on a search, then hand back a summary of 1,000 to 2,000 tokens. The noise stays in its window, and yours stays clean.
Which is the best home for a decision the agent must still know after compaction?
Chapter complete
You've finished chapter 3 of 6 in How agents work.
Agents cooperate in three shapes: a lead that hands out work, a maker checked by a separate evaluator, and peers sharing a repository. In all three, files carry the messages.
Next chapter