Context Engineering for AI Coding Agents: 7 Practices Backed by Research

The model you pick matters less than what you put in front of it. Research from 2023 to 2026 keeps finding the same thing: models get less reliable as their input grows, an auto generated AGENTS.md can make an agent slower and more expensive without making it better, and a well designed tool interface can lift an agent more than a model upgrade. Context engineering is the practice of deciding exactly what the agent sees on every step.

This review takes seven practices that coding agent teams recommend and checks each one against the study behind it: what was measured, how big the effect was, what to change in your setup, and what it does to your bill. Where the evidence is thin or comes from a vendor, we say so.

What is context engineering for AI coding agents?

A coding agent runs in a loop. On each step it reads files, runs a command, looks at the result and decides what to do next, and on each step it resends a growing pile of instructions, code, tool output and history to the model. Context engineering is choosing which tokens go into that pile, in what order, and which ones get dropped.

Anthropic framed it in September 2025 as the successor to prompt engineering. A prompt is written once. Context is assembled again on every step, so it has to be managed like a budget: every token you add competes for the model's attention with every token already there.

Our AI coding agents 2026 research overview covers the six layers modern agents give you to control context, from rules files to hooks. This post goes one level deeper and asks which practices actually hold up when someone measures them.

The 7 practices at a glance

1. Keep the working context small

For a coding agent, distractors are everywhere: an old version of a function, a similar helper in another folder, a stale stack trace from three steps ago, a test log for a different failure. They look relevant, so the model attends to them. A 1M token window is a ceiling, not a target.

What to do:

• Start a fresh session for each task instead of letting one conversation run all day.
• Exclude build output, lock files, vendored code and generated files from what the agent can read. Cline supports a .clineignore file, and most agents respect .gitignore.
• Put the task statement and the most important constraint at the start or end of your message, not buried in the middle of pasted logs.
• Paste the one failing test and its error, not the whole test run.

2. Keep AGENTS.md minimal, and write it yourself

The authors' conclusion is direct: unnecessary requirements make tasks harder, so a human written file should state only minimal requirements. That matches the advice of practitioners who add a line to AGENTS.md only after the agent has failed at something.

What to do:

• Delete any AGENTS.md or CLAUDE.md that an agent generated for you, unless you have read and trimmed every line.
• Keep what the agent cannot discover by reading the code: the exact test command, the package manager, the one directory it must never touch.
• Remove anything that restates what is already in the README or obvious from the code.
• Treat each line as a cost. If a rule does not fix a failure you have actually seen, it probably does not belong.

3. Retrieve context just in time instead of preloading it

The opposite pattern is common in home made agents: embed the whole repository, retrieve the top 20 chunks for every request, and paste them all in. That fills the context with near misses before the agent has even looked at the problem.

What to do: give the agent fast search tools (ripgrep, a symbol index, the language server) and let it pull files when it needs them. Use pre-retrieval only for small, stable material such as an API schema or a style guide. If you do use retrieval, keep the result count small and rerank before inserting.

4. Design what your tools return, not just what they do

Every tool result lands in the context and stays there for the rest of the session. A grep that returns 800 lines, a test runner that prints every passing test, or a build log full of warnings can each cost thousands of tokens and push the useful facts into the middle.

What to do:

• Wrap noisy commands. Run tests in a quiet mode that prints only failures, for example pytest -q or vitest --reporter=dot.
• Cap search output and tell the agent how many matches were cut.
• Return errors in one short, specific line rather than a full stack trace when the top frame is enough.
• Load only the MCP servers a task needs. Each one adds its tool descriptions to every request.

5. Put test and execution results back into the context

This is the strongest argument for one specific kind of context: the output of a real check. A failing assertion with expected and actual values is a few dozen tokens that carry more signal than pages of instructions. It is also why the ACE paper in practice 7 could improve agents without labelled data, by using natural execution feedback.

What to do: give the agent one exact test command and tell it a task is not finished until that command passes. Feed back the failing case, not the full log. If a part of your codebase has no tests, ask the agent to write a failing test that reproduces the bug before it touches the code.

6. Isolate exploration in subagents, and budget for the tokens

What to do: use a subagent when you want to keep a large, messy exploration out of the main thread, such as finding where a value is set or reviewing a finished diff. Keep the actual editing in one agent. Ask subagents for short, structured answers, and run them on a cheaper model when the task is search rather than judgement.

7. Persist what the agent learns, and compact with care

Compaction, summarising a long session and starting again from the summary, is now built into most agents. ACE is a warning about how to do it: append and edit small entries rather than rewriting everything into a short paragraph. The same idea works by hand with a notes file that the agent updates as it goes.

A small progress file the agent keeps on disk survives context resets and costs only a few hundred tokens to reload:

# NOTES.md (task: fix duplicate invoice emails)
## Decisions
- Root cause: retry in send_invoice() has no idempotency key
- Fix in billing/mailer.py only. Do not touch the queue worker

## Done
- Failing test added: test_invoice_sent_once

## Next
- Add idempotency key, run: pytest tests/billing -q

## Gotchas
- Local SMTP mock must be started first: make mail-mock

What to do: before you compact or start a new session, have the agent write decisions, finished work, next steps and gotchas to a file. Keep the exact commands and file paths. When a lesson repeats across tasks, promote that one line into AGENTS.md, and delete it later if it stops earning its place.

How context engineering lowers your coding agent bill

Coding agents are input heavy. In a typical step the agent sends about 30,000 tokens and gets back about 1,000, so roughly 86% of the bill on a model like Claude Sonnet 5.5 is input. Every practice above shrinks that input. One more lever works alongside them: prompt caching. On Anthropic models, reading a cached prefix costs 10% of the normal input price, and writing it costs 1.25 times the input price for a 5 minute cache. Caching only works if the start of the context stays the same from step to step, which is one more reason to keep rules files short and stable.

For full rupee numbers by model, see our guides to Claude Sonnet 5 pricing and the cheapest AI model for coding agents.

A context engineering checklist for your next agent session

Limits of this evidence

These studies are useful, but read them for direction, not exact numbers. Most were run on benchmarks built from public Python repositories, which may differ from your codebase. Some used models that are now one or two generations old. The Anthropic results come from internal evaluations that outsiders cannot reproduce, and SWE-bench Verified itself has known contamination problems, which is why OpenAI stopped reporting it in February 2026. The safest reading is the pattern they share: less but better context, real feedback from tests, and tools that return short, useful output. If you want to check a practice on your own code, our guide to evaluating AI coding models on your own tasks shows how to measure it.

Frequently asked questions

Sources and method

Figures are quoted from the papers and posts below as reported by their authors. We did not rerun any of these experiments. Rupee examples use Velona list prices on 16 October 2026 with the request sizes stated, and Anthropic's published cache multipliers of 1.25 times input for a 5 minute cache write and 0.1 times input for a cache read.

• Gloaguen et al., Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (ICLR 2026)
• Engineer's Codex summary of the AGENTS.md study
• Chroma Research, Context Rot
• Liu et al., Lost in the Middle: How Language Models Use Long Contexts (TACL 2024)
• Anthropic, Effective context engineering for AI agents
• Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
• Chen et al., Teaching Large Language Models to Self-Debug
• Anthropic, How we built our multi-agent research system
• Zhang et al., Agentic Context Engineering (ACE)
• Anthropic prompt caching documentation
• OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities