RSCH-001Published

Context Management in Coding Agents

Larger context windows did not make coding agents proportionally more reliable. The engineering problem is deciding what the agent should see, when it should see it, and what that context costs.

Who this is for. For software and agent engineers working on multi-step repository tasks. Assumes comfort with tests, CI, APIs and production trade-offs.

  • 18 chapters in 5 parts + 2 appendices
  • 38k words
  • 37 figures
  • 71 min engineer core
  • ~3 h complete archive
  • Updated 2026-09-22 · v1.0

The finding in 60 seconds

  1. The context window is an attention budget, not a bucket.

    Chroma tested 18 models across eight lengths and found performance generally degraded as input grew, with non-uniform, model-specific curves S. Correct but irrelevant tokens can still reduce performance.

  2. Subtraction beats addition, and the evidence is lopsided.

    5K tokens of targeted retrieval beat a 100K summary P. Masking matched summarisation at lower cost S. Fewer tools beat more tools S. A first audit should test for waste before changing strategy.

  3. Compression damage shows up as unreliability before it shows up as lower accuracy.

    Compressed agents become intermittent: they solve a task, then fail the same task on a rerun S. Teams measuring single runs conclude compaction is free until production disagrees.

  4. The cache can flip the sign of an optimisation.

    In the worked price model, a 24% token cut that made the prefix dynamic raised cost 6.9× C. Token count alone is not a cost model.

  5. There is a stopping point.

    About 16 hours of sequenced work, most of it deletion, covers the large majority of the benefit. Past the stop rule, your binding constraint is somewhere else.

Choose your path

Pick the entry point that matches the time you have. Every path ends with something you can do.

Recommended for working engineers

The 71-minute engineer core

8 chapters carry the complete argument from mechanism to measurement to an operating plan. The remaining chapters are evidence, catalogs and reference material to open when the decision in front of you needs them.

  1. 1Why more context can hurt coding agentsWhat is context, mechanically, and when does adding more make coding agents less reliable?10 min
  2. 2Anatomy of a coding agent's contextWhere do the tokens in a coding agent's context actually go, and which parts can you control?6 min
  3. 3Choosing your methods: a 55-minute procedureGiven my own agent and workload, which method should I adopt first, and in what order after that?5 min
  4. 4Retrieval: how code should enter contextShould code enter context by grep, embeddings, the symbol graph or agentic search, and what does the evidence actually say?9 min
  5. 5Compaction, offload and memoryHow do compaction, offload and memory lose information, what does that cost in measured terms, and what should you do with your wiki?15 min
  6. 6The tool surface: MCP, skills and progressive disclosureHow much context do tools, MCP servers and skills consume, and what does a healthy tool surface look like?8 min
  7. 7Evaluating a context changeHow do you prove a context-management change helped, with what statistical design, and at what cost?9 min
  8. 8Your optimisation planGiven everything so far, what exactly should I do, in what order, and when should I stop?9 min

Why this research exists#

When a coding agent fails on a real repository, the transcript often looks reasonable. The decisive fact may be behind a compaction boundary, displaced by unused tool definitions, or contradicted by a signature the agent invented earlier.

Those failures are quiet, and they are mostly context failures. This research asks what should be in a coding agent's context at each step, what should not, who decides, and how you would know the decision was right.

One constructed first-measurement example looks like this:

One 152K-token mid-session context (illustrative)

Stacked bar: tool results 38%, tool definitions 25%, retrieved code 14%, agent messages 8%, system prompt 6%, instruction files 4%, summaries 2%, skills 1%, user turns 1%.25%14%38%8%
  1. System prompt9,000 · 6%
  2. Tool definitions38,000 · 25%
  3. Instruction files6,500 · 4%
  4. Skill descriptions1,800 · 1%
  5. Retrieved code22,000 · 14%
  6. Tool results58,000 · 38%
  7. Agent messages12,000 · 8%
  8. User turns1,700 · 1%
  9. Summaries3,000 · 2%
Figure 1. In this constructed composite, tool definitions and results hold 63% of the window while the instruction file is 4%. The worked actions recover about 32%; the first two remove or defer waste, while the latter two require verification C.
View data
SegmentTokens
System prompt9,000
Tool definitions38,000
Instruction files6,500
Skill descriptions1,800
Retrieved code22,000
Tool results58,000
Agent messages12,000
User turns1,700
Summaries3,000

Everything else in this research follows from taking that picture seriously: measure first, delete what is dead, shape what is loud, make every loss reversible, and stop when the numbers say your constraint has moved elsewhere.

The learning path

Five parts, one arc: understand the problem, learn the methods, measure them, make the hard calls, then act. Each chapter answers one question.

  1. Part I

    Understand the problem

    What context is mechanically, when more of it makes agents less reliable, and where the tokens actually go.

    2 chapters · 16 min

    1. 1Why more context can hurt coding agentsWhat is context, mechanically, and when does adding more make coding agents less reliable?10 min
    2. 2Anatomy of a coding agent's contextWhere do the tokens in a coding agent's context actually go, and which parts can you control?6 min
  2. Part II

    The methods

    The ten methods that survive scrutiny, how to choose among them, and the four surfaces where context is spent.

    6 chapters · 68 min

    1. 3Ten methods that survive scrutinyWhich context-management methods survive scrutiny, why does each work, and what does each cost?23 min
    2. 4Choosing your methods: a 55-minute procedureGiven my own agent and workload, which method should I adopt first, and in what order after that?5 min
    3. 5Retrieval: how code should enter contextShould code enter context by grep, embeddings, the symbol graph or agentic search, and what does the evidence actually say?9 min
    4. 6Compaction, offload and memoryHow do compaction, offload and memory lose information, what does that cost in measured terms, and what should you do with your wiki?15 min
    5. 7Sub-agents and isolationWhen does splitting work across sub-agents help, when does it destroy the task, and how can you tell in advance?8 min
    6. 8The tool surface: MCP, skills and progressive disclosureHow much context do tools, MCP servers and skills consume, and what does a healthy tool surface look like?8 min
  3. Part III

    Measure it

    How to prove a context change worked, what to track, and what context really costs once the cache is priced in.

    2 chapters · 17 min

    1. 9Evaluating a context changeHow do you prove a context-management change helped, with what statistical design, and at what cost?9 min
    2. 10Metrics and the real cost of contextWhat should you measure, and what does context really cost once the cache, latency and people are counted?8 min
  4. Part IV

    Decide and avoid

    The hard calls with no clean answer, the ways context management fails, the traps that look like hygiene, and real cases.

    4 chapters · 38 min

    1. 11Twenty-five hard callsWhich context decisions have no clean answer, and how do you decide them for your own situation?12 min
    2. 12Forty-four failure modesHow does context management fail, what is the tell for each failure, and how do you contain it?8 min
    3. 13Sixteen antipatternsWhat looks like good context hygiene but is not, and how do you tell the difference?8 min
    4. 14Eight case studiesWhat do these decisions look like on real, documented incidents, including ones where the change made things worse?10 min
  5. Part V

    Act on it

    A sequenced 16-hour plan, a scored diagnostic, daily habits and the tooling landscape.

    4 chapters · 27 min

    1. 15Your optimisation planGiven everything so far, what exactly should I do, in what order, and when should I stop?9 min
    2. 16The diagnostic: score yourself, get one actionWhere does my team stand on context management today, and what is the single next thing to do?4 min
    3. 17Sixty-two habits that compoundWhat small, daily practices pay for themselves, and when does each one apply?6 min
    4. 18The tooling landscapeWhich open-source tools, plugins and local MCP servers improve context use, and which are worth adopting?8 min
  6. Part A–B

    Reference

    Copyable templates and the full list of falsifiable lessons.

    2 chapters · 13 min

    1. ATemplates you can copyWhat are the fill-in forms that make this operational, and which field in each carries the value?3 min
    2. BFifty-eight lessons, each falsifiableWhat are the transferable lessons, why is each true, and what would prove each one wrong?10 min

Reference

How to read the evidence

Every non-obvious number carries a label. Click any label to see its source rules.

  • Sourced — A study, paper, or first-party engineering write-up with a stated method
  • Practitioner-reported — A credible operator or project account without a published method
  • Derived — Follows from a labelled claim by stated reasoning, not independently measured
  • Composite — A constructed illustration, not a real incident