Context engineering: keep AI agents focused on the task

Context is a budget

AI agents do better when the useful information is easy to find and the distracting information is absent. Anthropic frames this as context engineering in its guide to effective context engineering for agents: the goal is to curate high-signal tokens for the current task. For a coding agent, context includes the user request, project instructions, selected files, search results, tool schemas, command output, diffs and the agent's own notes. When all of that is dumped in without structure, the model may chase side issues or miss the one rule that matters.

Build a context packet

For any nontrivial task, prepare a short packet before asking for implementation. The packet should include: objective, files likely in scope, files off limits, verification command, relevant docs and stop conditions. Example: Objective: add a settings toggle. Scope: src/settings and tests/settings. Off limits: generated site files. Verify: npm test -- settings. Stop: ask before changing auth or database migrations. The packet gives the agent an explicit scope before it edits files.

Retrieve late, not everything early

Large context windows tempt people to paste whole repositories, but that often produces noisy reasoning. A better pattern is hybrid. Provide a map of where the answer probably lives, then let the agent inspect exact files just in time. The same principle appears in agentic coding tools that can read files, run commands and search the project; Claude Code describes those capabilities in its overview. Give the agent enough direction to search well, then require it to cite the files it actually used.

Keep tools narrow

MCP can connect agents to external systems, and the MCP architecture guide explains the host, client and server pattern. Context engineering applies to tools too. A server with twenty vaguely named actions creates cognitive load. A server with three precise read-only tools is easier for the model and safer for the user. Tool names should say what changes state. If a tool sends, deletes, deploys or charges money, the workflow should make that obvious before the call.

Use notes for long tasks

Long agent runs fail when earlier decisions disappear into chat history. Ask the agent to maintain a short task note when the job spans many files: assumptions, files touched, commands run, blockers and remaining work. The note should not become a second codebase. It is a working memory index. At handoff time, it helps the next agent continue without rereading every command output.

Problems to check

• Context hoarding: every related document is pasted. The agent spends attention on stale or irrelevant detail.
• Invisible constraints: the human knows deployment is forbidden, but the agent only sees a feature request.
• Noisy command output: long logs hide the actual error. Summarize the failing line and keep the full log available only if needed.
• Tool overload: the agent has more external actions than the task requires.
• Stale summaries: a compacted conversation says work is done when files changed afterward. Recheck state before finalizing.

Practical workflow

1. Write the objective in one sentence.
2. List likely files and forbidden areas.
3. Give one verification command or say why none exists.
4. Let the agent inspect files before editing.
5. After edits, ask for changed files, checks run and remaining risks.

Keep the reproduction command and observed failure in the task note until the check passes. If the agent discovers a different cause, update the note so later work uses the current evidence.

Small context example

For a bug fix, the context packet can be as small as six lines: failing behavior, expected behavior, reproduction command, likely files, forbidden files and verification command. That is often better than a long project explanation. If the agent needs more, it can ask or inspect. Remove information that does not change the next step, while retaining errors and constraints that could affect it.

After the run

Context engineering continues after implementation. Ask for a final state summary: what changed, what evidence supports success, what remains uncertain and what should be ignored as unrelated. That summary becomes clean context for the next turn and reduces the chance of repeating stale investigation.

Keep evidence when you shorten logs

A useful condensed test result includes the command, exit status, failing test name and relevant error lines. Keep the full log available by file path. Avoid replacing a failed command with a note saying that verification was attempted: that loses the distinction between a failed test and a test that never ran. For a hypothetical settings bug, the note might say that the saved value changed correctly, but the page still showed the old value after reload. That observation narrows the next investigation to loading or rendering state. A summary should preserve this sort of distinction even when the surrounding output is long.

Sources and further reading

Documentation checked October 4, 2026. Product features and availability can change.

• Anthropic context engineering guide
• Claude Code overview
• MCP architecture guide