Give the task sufficient, current context

Start with the evidence needed to make the task answerable. Include the goal, relevant original material, important constraints, and a way to check the result. Add context when the investigation shows why it matters.

Anthropic's context-engineering guidance emphasizes useful, sufficient context and dynamic retrieval. It does not establish that removing any extra file automatically improves every answer.

Select around the failure

For a retry bug, useful starting material includes the failing behavior, retry function, caller's attempt-number convention, and relevant test or contract. The function alone may be insufficient: the caller can explain an apparent off-by-one error.

For an API migration, include the installed version, affected call site, current official documentation, and the intended behavior. A general summary of the library can leave out exactly the parameter that changed.

Preserve authority and revision

Name which specification and source revision are authoritative. If two sources disagree, keep that disagreement visible until it is resolved.

A source pointer makes a short handoff useful. “The caller uses one-based attempts; see caller.js at this revision” is checkable. “The previous agent said it was fine” is not enough evidence for an independent reviewer.

Keep sufficient surrounding text for definitions and exceptions. A quoted line without the enclosing contract can be misleading.

Let the tool retrieve deliberately

Coding agents can inspect further files through their configured tools. A chat interface may use uploaded sources, projects, search, or other available capabilities. Verify what it actually accessed; availability is product-specific.

Use the repository's instruction mechanism for stable commands and constraints, and the current task record for changing progress. The guides for AGENTS.md, CLAUDE.md, and GEMINI.md explain their different loading behavior.

Try a controlled handoff

Prepare a packet containing the task, relevant files, original failure, constraints, and open questions. Ask:

Identify the evidence needed to explain this failure. Use the supplied sources first. If a missing caller, configuration, or requirement changes the answer, name it and inspect or request it before proposing a fix.

After the investigation, add the newly relevant evidence to the packet. Remove superseded material or label it as superseded. Keep the original reproduction so the task does not drift.

What goes wrong

A large attachment set can contain irrelevant or conflicting material. A tiny excerpt can omit a decisive definition. A stale project document can compete with current code. A summary that drops source pointers makes the next stage depend on the previous model's interpretation.

Stored attachments are not universally resent in full on every turn. Cost and working-context behavior depend on retrieval, caching, and the product.

How to check

Have the next stage state the requirements and source revision it used. Verify those statements against the packet, then check the actual result.

If an omitted file changes the conclusion, restore it and record why it is necessary. If irrelevant material obscures the task, remove it. Judge context selection by supported conclusions and checked behavior.