Claude Opus Context Engineering for Coding Agents

Claude Opus context engineering is the practice of giving an agent the smallest current evidence package that lets it plan, edit, and verify a repository task. Start with a task contract; assemble architecture, dependency, decision, and test artifacts; then refresh only the evidence whose revision changed. A one-million-token context window is capacity, not a substitute for that workflow.

Define the Agent’s Task Contract

Before gathering context, write a contract the agent and reviewer can both check: the desired behavior, out-of-scope behavior, allowed files or services, dependency boundary, acceptance criteria, and stop conditions. This prevents a broad model capability from becoming a broad task.

As verified on July 30, 2026, Anthropic identifies the current model as claude-opus-5, with a one-million-token default and maximum context window. The related SERP query “Claude Opus context window” is a reminder to verify model details at publication time, not a reason to load an entire repository.

The contract answers: what must change, what may not change, what evidence makes the work complete, and who can approve a boundary exception. If any answer is unknown, resolve it before asking for an implementation plan.

Build the Four Context Artifacts

The artifacts below are reusable engineering records, not a four-part prompt. Each should point back to primary source files, owners, and the revision it represents.

Architecture map

Describe major modules, runtime boundaries, entry points, data flow, and public interfaces. Keep it short enough to navigate, then link to the code that proves each part. A map tells the agent where to orient; it should not claim every dependency is current forever.

Dependency map

For the target surface, include direct callers, downstream consumers, external services, generated clients, feature flags, and compatibility rules. Distinguish a verified edge from a suspected one. This is where teams expose the change surfaces that a nearby-file-only workflow misses.

Decision history

Record active architectural decisions with date, owner, status, evidence, and expiry trigger. “Why is this API additive?” is different from “where is this API implemented.” Keep rejected alternatives when they explain a guardrail, but do not pass a decade of stale discussion into every task.

Test and ownership map

List the relevant unit, integration, contract, and end-to-end tests, plus the owners who can resolve a failure. Tie acceptance criteria to observable checks. For the capability framing behind these artifacts, see Claude Opus 5 codebase context.

Move the Agent Through Four Working Stages

Context changes by task phase. Route each artifact when it is needed instead of repeatedly pasting a static repository dump.

Orient before planning

Give the agent the task contract, architecture map, target paths, and a small set of key interfaces. Ask it to identify unknowns and relevant owners. An orientation response should be a map of evidence needed next, not an implementation guess.

Plan before editing

Add verified callers, constraints, and test expectations. Require an ordered plan with intended files, compatibility risk, and an explicit “cannot determine” list. This mirrors Anthropic’s guidance that difficult multi-file tasks benefit from a complete specification; teams still need to review the plan.

Retrieve before crossing modules

When the plan crosses a service boundary, retrieve the contract, consumer, migration, and test evidence for that boundary. Anthropic’s tool-use model lets applications provide client tools and tool results, so the agent can receive targeted evidence rather than treating recalled text as a source.

Verify before completing the task

Provide the final diff, changed contracts, targeted tests, project gates, and reviewer checklist. Ask the agent to compare the output with the task contract and list unresolved assumptions. A passing command is evidence; it is not a proof that the task never touched an omitted dependency.

For a structured retrieval option at the cross-module stage, see Claude Opus knowledge graph.

Worked Example: A Cross-Service API Change

Suppose Service A adds preferred_locale to a profile response consumed by Service B and a web client. The task contract says the field is optional, must not change authorization, and needs contract coverage before release.

The orientation package includes the profile route, response schema, service ownership, and release policy. The plan package adds Service B’s client, the generated type boundary, the migration rule, and contract-test location. Before editing across modules, the agent retrieves each consumer’s version policy and the tests that assert the response. At verification, reviewers compare the diff against the plan, run the contract tests, and confirm that a missing field remains compatible.

This is deliberately a workflow example, not a claim that any model will find every consumer. Teams that need the package to travel across tools can use a neutral, versioned contract such as Share repository context across coding agents.

Recognize When the Agent Is Losing Context

Stop and refresh when the agent repeatedly searches the same locations, gives incompatible module summaries, omits a previously cited constraint, or starts proposing edits without naming their consumers and tests. These are workflow signals, not a diagnosis of the model.

Anthropic’s context-window guide cautions that larger context is not automatically better and that all messages, tools, and outputs count. A smaller, revision-bound package is often easier to audit than a growing transcript.

Refresh Context Without Restarting the Entire Task

Keep shared repository facts separate from task-private notes. If a schema, dependency, or decision changes, refresh that artifact and its revision marker. Preserve the old task evidence for audit, but mark it superseded rather than silently blending it into a new summary.

Do not call this automatic memory. It is a team-maintained context layer with explicit ownership. A new session can load the current package; it cannot safely assume that a prior conversation’s inferred facts are still true.

Use a refresh receipt for each material update: repository revision, artifact changed, reason, person or job that verified it, and the affected open tasks. That small record makes a handoff inspectable without forcing the next agent to reread the whole history. If the receipt cannot name the source revision, treat the context as a lead to verify rather than an instruction to implement.

For a long-running task, make the receipt part of the completion gate. The implementer records the revision and tests it used; the reviewer records whether those facts still matched the merge candidate. This creates a narrow restart point after interruption and prevents a successful-looking transcript from becoming the only account of repository state.

Include the task’s approved access boundary in that receipt as well. A replacement session can then distinguish facts it may retrieve from files it must not open, even when a prior plan named both. That distinction protects the repository and makes the restart decision reviewable.

FAQ

Where should teams store shared repository context?

Use version-controlled project artifacts or a governed retrieval store that can link each fact to source, revision, owner, and refresh date. Keep the task contract close to the work item, not hidden in a reusable global summary.

Which context should remain private to one task?

Keep temporary hypotheses, raw logs, credentials, customer data, and unreviewed agent observations task-private. Promote a fact to shared context only after a responsible owner can verify and maintain it.

Who should maintain architecture and dependency notes?

The code or service owners should own correctness; the platform or developer-experience team can own the format and refresh mechanism. A single “AI context owner” cannot validate every domain relationship.

Can the same context package support different coding models?

Yes, if it is tool-neutral and uses source paths, revisions, provenance, and clear access rules. Model-specific instructions can sit beside it, but should not redefine the shared repository facts.

What should happen when a session ends unexpectedly?

Persist the task contract, evidence references, plan, tool trace, changed files, tests run, and unanswered questions. Start the next session by rechecking revisions, not by blindly continuing an old summary.

Conclusion

Effective Claude Opus context engineering is a controlled handoff between repository evidence and a bounded task. Use four maintained artifacts, route them by phase, refresh facts that changed, and keep approval with accountable engineers. The result is more reviewable agent work, not a promise of automatic repository memory.