Prompt engineering asked: what words make the model behave? Context engineering asks a better question: of everything the system knows, what belongs in the model's window for this decision, and in what form?
The window is the agent's entire working memory. The model does not know your codebase, your standards doc, or what it did ten minutes ago — it knows what is in the window right now. Treat that space as the scarcest resource in the system, because it is.
The budget mindset
A 200k-token window feels infinite until an agent fills it: every file read in full, every tool result appended forever, every retry stacked on the last. Two things degrade as the window fills — and both degrade before you hit the hard limit:
- Attention dilutes. Models attend less reliably to any given fact as total content grows. The instruction on line 50 competes with the file dump on line 4,000. "It's in the context" is not the same as "the model will use it."
- Cost and latency scale per call. The loop re-reads the whole window every iteration. A bloated context taxes every remaining step of the task.
So budget deliberately. A workable starting allocation for a coding agent: roughly a tenth of the window for standing instructions and tool definitions, a quarter for retrieved knowledge relevant to the current step, a quarter for recent action-observation history, and the rest held as headroom for the model to think and act. The numbers are negotiable; having an allocation at all is not.
Retrieval: load knowledge just in time
The naive pattern — embed the corpus, fetch the top-k chunks, staple them to the prompt — works until it doesn't. Its failure modes are well known: chunks arrive without their surrounding argument, top-k returns near-duplicates, and the query the user typed is often not the query that would find the answer.
Three upgrades pay for themselves quickly:
- Let the agent search, not just receive. Give retrieval to the model as a tool it can call with its own reformulated queries, multiple times if needed. An agent that can ask "handoff patterns between sub-agents" after the user asked "how do I split work" beats any single-shot retriever, because retrieval becomes part of the loop and the model can react to what came back. (This is the same principle as chapter 2's verifier: move judgment inside the loop.)
- Chunk along the document's own structure. Split at headings and paragraph boundaries, keep the heading path attached to every chunk —
Ch 3 › Retrieval › Chunking— so each fragment carries its location in the argument. A chunk that knows where it came from can be cited, and a citation the reader can click is the difference between an answer and an assertion. - Return references, not payloads, when the payload is large. For big artifacts, retrieval should hand back an identifier and a summary, with a tool to pull the full content on demand. Most retrieved material influences one decision and then squats in the window for the rest of the run.
Compaction: forgetting on purpose
A long-running agent must eventually shed history. The crude move is truncation — drop the oldest turns — and it fails in a characteristic way: the agent forgets its own earlier decisions and relitigates them.
Better: summarize, then drop. When the history crosses a threshold, have the model write a structured digest — decisions made, facts established, dead ends ruled out, current state of the task — and replace the raw turns with the digest. What must survive compaction is exactly the content that prevents repeated work: what was decided and why, and what was tried and failed. An agent that loses its dead ends will walk into them again, and dead ends are expensive the first time.
Sub-agents, from this angle, are compaction by architecture: the explorer burns fifty thousand tokens reading and returns a five-hundred-token brief. The main agent buys the conclusion without inheriting the search. That trade — context isolation in exchange for a handoff cost — is usually the right one whenever a phase of work is read-heavy and its output is small.
Memory across sessions
Everything above manages one session's window. Agents that work over days need state that survives the window entirely: files the agent reads on startup and edits as it learns — project conventions, user preferences, a log of what it shipped last time.
Keep durable memory small, structured, and load-bearing: facts the next session will actually act on, not a diary. A memory file that grows without pruning becomes one more context tax — you have just moved the bloat from the window to disk and reimported it every morning. Write little, prune often, and let anything reconstructible from the codebase or the history stay there.
The discipline
Context engineering is not a bag of tricks; it is a posture. For every token, someone decided it belonged in the window — the question is whether that someone was you, exercising judgment, or a default, appending blindly. Systems built with the first posture get more accurate as they run longer. Systems built with the second get worse.