Context Management for Coding Agents
The useful context is not the largest possible context. It is the smallest evidence set that lets the agent make the next correct decision.
A repository is larger than a prompt
Even when a model supports a large context window, indiscriminately loading a repository is usually the wrong abstraction. Generated files, vendored dependencies, unrelated features and old logs consume space without helping the current decision.
Coding agents therefore need context management, not merely context length. The system must decide what to inspect now, what to keep, what to summarize and what to retrieve again later.
Four useful context layers
Think about agent context in layers:
- Task context: the request, acceptance criteria and conversation decisions.
- Project context: repository instructions, architecture notes, package manifests and conventions.
- Working context: files, symbols, tests and diagnostics directly relevant to the current step.
- Execution context: tool results produced during the task — diffs, compiler output, test failures and command results.
These layers change at different rates. Project instructions may remain stable for many tasks; execution context can become stale after a single edit.
Retrieve evidence instead of dumping files
A useful investigation often starts broad and narrows: list the relevant directory, search for a symbol, read the implementation, locate its tests, then inspect neighboring code only when evidence points there.
This has two advantages. It conserves context budget, and it makes the agent's reasoning depend on files that are actually connected to the task rather than on accidental textual similarity elsewhere in the repository.
A file being present in the model's context does not guarantee that the model will use the right part of it. Selection, organization and verification still matter.
Refresh context after actions
Agent state changes as tools run. After editing a function, an earlier copy of that function is stale. After a build, new diagnostics may supersede the previous error. After a dependency update, a lockfile may contain facts that did not exist at the start of the task.
Good workflows repeatedly reconnect decisions to the current repository state: inspect → change → observe → re-read or test where necessary.
Common context failure modes
Too little context produces guesses about APIs, conventions or dependencies. Too much context introduces noise and consumes attention. Stale context causes the agent to reason about code that no longer exists. Untrusted context can contain text that tries to redirect the agent away from the user's task.
The remedy is not one magic token count. It is disciplined retrieval, explicit instruction hierarchy, tool boundaries and verification against the current working tree.