Method, scope and quality bar

The research question#

At inference time, a model can act on two sources: patterns encoded in its weights and information placed in the current input. The repository, yesterday's conversation, CI logs and the ticket affect the next action only when the harness retrieves and presents them. That machinery is rarely designed as one system. It accretes.

The question is not "how do I fit more into the window?" Buying a bigger window increases capacity, but capacity alone does not guarantee reliable use of relevant context. The question is:

The strong claim under test: before changing the model or adding tools, teams running long repository tasks should test whether context discipline is their binding constraint.

Context failures are also the quietest. An agent with a bad loop spins visibly. An agent with bad evaluation reports a number you can argue about. An agent with bad context management quietly gets things wrong, and the transcript looks reasonable the whole way down.

Sub-questions and where they are answered#

Eight design commitments#

Fixed before writing, to avoid the usual failure of "context engineering best practices" content: mostly restated blog posts, some vendor pitch, very little measurement.

Method#

This publication is an author-led, evidence-informed narrative synthesis and practitioner framework. It brings selected empirical studies and practitioner reports together to develop an operating framework and recommendations. It does not report a reproducible systematic-search and inclusion protocol or an independent peer or research-method review; it therefore does not claim systematic or exhaustive coverage.

1. Ground truth. Three bodies of work read against each other: empirical long-context research (for the shape of the degradation curve), the 2026 agent-context papers (for measured changes at compaction boundaries) and practitioner engineering writing (for mechanism, discounted for product claims). Vendor numbers about vendor products are upper bounds.
2. Derive the frame. A segment entered the anatomy only if a documented class of failure is exactly "this segment was too large, too small, stale or in the wrong place".
3. Catalogue. Ten methods chosen by four tests (mechanism, evidence, independence, decidability), with a published benched list. See how the ten were chosen.
4. Measurement layer. Evaluation design specific to context changes, because their effects are small, fully harness-confounded, and show up in variance first.
5. Apparatus. Hard calls, failures, metrics, antipatterns, cases, tooling, lessons, habits, templates and a scored diagnostic.
6. Personalise. A sequenced plan with a measurement gate per phase, so nothing is adopted on faith.

Out of scope#

Stated so that the omissions are choices, not oversights.

• Model internals: attention variants, kernel-level cache eviction, positional encodings. Referenced only where they explain observable behaviour.
• Training-time context: long-context pretraining and compaction-aware training appear only where they change what an operator should do today.
• Non-coding agents: browser, GUI and research agents appear only where a finding transfers. Coding agents are special because the filesystem is simultaneously the task, persistent memory and a major evidence source; it is not complete ground truth.
• Prompt quality: how to write a good instruction is prompt engineering. How much of it to load, when and at what cost is context engineering.
• Security: context poisoning through prompt injection is named as a failure with containment; the adversarial surface is another research programme's subject.

Internal completion check#

I used 27 criteria and two "anti-bar" questions to track the planned scope. In my own assessment, 27 of 27 criteria and both anti-bar questions passed; three criteria have stated caveats. This is my self-assessment, not an empirical result or a score reviewed by an independent peer or research-method reviewer; the tally is not externally reproducible.

The criteria below are condensed summaries. They omit full operational definitions and criterion-by-criterion evidence and verification records; readers cannot independently reproduce the tally from this table. No independent peer or research-method reviewer scored the checklist.

The three caveats#

• Case studies, "majority sourced", is true only on a generous reading. Of eight cases, four are S, two are P first-party accounts, and two are labelled composites C. Strictly, S is a plurality, not a majority. Six of eight describe real events; four have a published method.
• Derived claims are under-labelled. Rule R3 (long-context findings transfer to agents only by inference) applies far more widely than the explicit D labels suggest. Treat every application of static-text research to a live agent as derived, whether or not it carries the label.
• One of the central empirical claims is under-verified. The observation-masking result was captured from the paper's summary. It is corroborated in direction and is not the sole support for any conclusion, but re-read it before citing. The sources page lists every figure in this category.

The two anti-bar questions: author's self-assessment#

1. If a reader with a real agent cannot, after reading the methods and the diagnostic, name their single largest wasteful segment and the change that would shrink it, the work has failed. My self-assessment marked this as passed because the one-question version branches to a named action, and a reader whose largest segment is tool definitions reaches the representative-sample deletion check in under fifteen minutes. This is a design rationale, not an observed reader study.
2. If any section could be replaced by "just use a bigger window" or "just run /compact" without loss, it is filler. My self-assessment marked this as passed: the research treats larger windows as added capacity rather than a complete reliability solution, and discusses losses from naive compaction. No independent peer or research-method reviewer scored this checklist.

Relationship to sibling research#

About this edition#

This web edition was rewritten from the original research package (about 72,000 words across 32 files, locked 2026-09-05) for readability and navigation: plain language, one question per chapter, a learning path in five parts, figures and charts, a one-page summary, an FAQ and a glossary. Claim wording, numeric attribution, evidence labels and caveats were edited in this edition; it is not a verbatim transfer, and readers should not assume those details were carried over unchanged. The current sources page lists this edition's citations and known verification limits. This edition does not claim a full-package peer or research-method review.

How to cite#

Alhamoud, G. (2026). Context Management in Coding Agents (RSCH-001, v1.0).
https://ghassan-alhamoud.com/research/context-management-coding-agents/