A coding agent knows exactly two things about your task: what the model learned in training, and what is in its context window right now. Your codebase, your conventions, the bug report, the output of the last test run: if it isn't in the window, the agent doesn't know it.
“Context engineering” is the name that stuck for deciding what goes in that window, when, and in what shape. For coding agents, it matters more than prompt wording ever did.
What fills the window
On a typical coding session, the context holds:
- The agent's own system instructions and tool definitions, including every connected MCP server.
- Your rule files, such as
CLAUDE.mdorAGENTS.md. - The conversation: your prompts and the agent's replies.
- Every file the agent read, and every command output it saw.
The last item grows fastest. One verbose test run or one large file can take more room than all your instructions put together.
More is not better
Context windows are now large, and it is tempting to fill them. But models get less reliable as the input grows: they miss details in the middle, follow early instructions less closely, and get distracted by text that looks relevant but isn't. Research on long inputs keeps finding the same thing, sometimes called “context rot”.
The goal is not to give the agent everything. It is to give it the smallest set of information that makes the right next step obvious.
Three tiers of context
A useful way to organise what your agent should know is by when it needs it.
Always on. What applies to every task: how to build and test, the handful of hard rules, a short map of the codebase. This goes in the root rule file, and it should be short, because it is paid for on every session. Think one page, not ten.
On demand. What applies to one area: the API conventions, the billing rules, the design system. Put it where the agent will find it when it goes there: nested rule files in each package, docs linked from the root file, or skills the agent can load. The agent fixing CSS never pays for the billing rules.
Just in time. What applies to one moment: “this migration folder is append-only”, right before the agent edits it. “This endpoint broke in March because of X”, right when it opens that file. Hooks and memory tools can deliver this kind of context at the exact step it matters, instead of hoping the agent remembers a line it read an hour ago.
Keep tool output small
Most context waste comes from tool output, not from your instructions. A few habits make a big difference:
- Quiet test runners. Run only the relevant tests, and use a reporter that prints failures, not every passing test.
- Search, then read. Searching for a symbol and reading the right 50 lines beats reading a 2,000-line file.
- Trim logs. The last 30 lines of a build log usually hold the error. The first 3,000 don't.
- Fewer tools. Each MCP server adds tool descriptions to every request. Disconnect the ones you don't use for this project.
Put the efficient commands in your rule file so the agent uses them without being asked:
## Commands
- Test one file: pnpm vitest run path/to/file.test.ts --reporter=dot
- Typecheck: pnpm -s typecheck (prints only errors)
- Search before reading: rg -n "symbolName" apps/Long tasks: subagents, notes and fresh starts
Use subagents for exploration. Claude Code and other agents can hand a search or an investigation to a subagent that works in its own context and returns only a summary. The main session gets the conclusion without the forty files that were read to reach it.
Write state to a file. On a long task, ask the agent to keep a short progress file: what is done, what is next, decisions made. When the context fills up and gets summarised, details get lost. A notes file survives.
Start fresh between tasks. A session that fixed a bug, then refactored a module, then wrote docs, is carrying a lot of irrelevant history into the fourth task. Clearing the context between unrelated tasks is free and often gives better results than continuing.
What stays outside every window
Context engineering has a hard limit: the window is gone when the session ends. Whatever the agent learned, such as the gotcha it hit or the correction you made, is lost unless something writes it down. The next session starts from your rule files and nothing else.
That is the part we focus on at Memmo: capturing what each session learned, having a person approve it, and serving it back in the right tier: a short briefing at the start, relevant memory with each prompt, and warnings right before an edit. Whatever you use, plan for that last step. A well-engineered context that forgets everything at the end of the session still makes you teach the same lesson twice.
A quick audit
- Is your root rule file under a page? What could move to a nested file?
- Do your test and build commands print only what matters?
- How many MCP servers are connected, and how many did you use this week?
- Do long tasks keep a notes file?
- Where do lessons from today's sessions go?