Context Engineering for Claude: Build a Smaller, More Reliable Working Set

More context is not automatically better context. A large collection of files can introduce stale requirements, duplicated facts, contradictory policies, and irrelevant detail. Context engineering is the practice of selecting, structuring, and refreshing the information Claude needs at each stage of a task.

Start With the Decision

Define the output and the decision it supports. A contract-risk memo needs governing terms, amendments, jurisdiction, and review criteria. It does not need every email ever exchanged with the customer. A code migration needs interfaces, tests, dependency constraints, and deployment rules—not the entire issue tracker.

Write a context contract:

Task: assess whether Release 4.2 is ready for a staged rollout.
Authoritative sources: approved requirements, test report, incident register.
Freshness cutoff: documents updated after 1 July 2026.
Excluded: superseded launch plans and unapproved design explorations.
Output: recommendation, evidence, risks, unknowns, and next validation step.

Create an Authority Map

Classify sources as governing, supporting, historical, or unverified. Add owner, version, and effective date. Tell Claude how to handle conflict: governing policy overrides meeting notes; current specifications override archived drafts; measured production data overrides an estimate unless methodology is invalid.

Do not ask the model to infer which file named “final” is actually final. Authority is an organizational decision and should be stated explicitly.

Build Context in Layers

Use four layers:

1. Operating rules: audience, privacy boundaries, source hierarchy, and acceptance criteria.
2. Task brief: current objective, scope, deliverable, and deadline.
3. Evidence: only the documents or code required for the present step.
4. Working state: decisions, open questions, tested hypotheses, and next action.

Keep the first layer stable and the others replaceable. This reduces instruction drift and makes it easier to restart a task without replaying an entire conversation.

Retrieve Before You Stuff

For large knowledge collections, use search or retrieval to find likely relevant passages, then give Claude the passages with provenance. Retrieval quality matters: test whether known questions return the correct policy, version, and section. Include neighboring text when a paragraph depends on definitions or exceptions.

For tool-enabled agents, tool definitions and accumulated results also consume context. Anthropic's official guide to managing tool context describes approaches such as tool search, prompt caching, programmatic tool calling, and context editing. Choose based on the actual source of context pressure.

Summarize With an Audit Trail

When compressing long work, preserve decisions, evidence identifiers, unresolved conflicts, failed attempts, and exact next steps. Separate verified facts from inference. A short summary that omits why an option was rejected can cause the agent to repeat work or reverse a sound decision.

Use a handoff block:

Confirmed: API contract requires backward compatibility through v3.
Evidence: api-policy.md, section 4.1.
Rejected: changing the response envelope; breaks two supported clients.
Open: whether the migration can run inside the maintenance window.
Next: benchmark migration on a production-sized anonymized snapshot.

Remove Context Deliberately

Archive superseded drafts, old tool results, verbose logs after their findings are captured, and examples that no longer reflect the desired output. Retain raw evidence outside the active prompt so reviewers can retrieve it when needed.

Never remove a security constraint, approval requirement, or material unresolved risk merely to save tokens.

Test the Context System

Create representative tasks and measure factual support, contradiction rate, source citation accuracy, task completion, latency, and cost. Include a stale document, a conflict between sources, and a question whose answer is absent. A reliable system should flag the problem rather than blend sources into a plausible answer.

Context engineering succeeds when Claude receives the smallest trustworthy working set that still supports the decision. The objective is not to fill the window. It is to make every included piece of information earn its place.

Operational Checklist

Before a production task begins, confirm that the brief names a decision owner, the source hierarchy is explicit, every governing document has a version, and sensitive material has an approved processing path. During execution, record new decisions and remove tool output once its result is captured. At handoff, test whether a new reviewer can reproduce the conclusion from the summary and cited sources.

Track context-related failure categories rather than treating every weak response as a model problem. Useful labels include obsolete source, missing exception, conflicting instruction, retrieval miss, excessive irrelevant context, lost working state, and unsupported inference. Their distribution tells the team whether to improve document governance, retrieval, task decomposition, or prompting.

Assign an owner to the context system. That person should review high-authority sources, unresolved conflicts, retrieval tests, access controls, and summary templates on a defined schedule.