Direct answer
Context engineering for a coding agent is the deliberate selection, ordering, and lifecycle management of repository instructions, task evidence, retrieved references, and tool output. The goal is not to maximize tokens; it is to keep the active context sufficient, current, attributable, and small enough that stale or untrusted material cannot silently dominate the task.
Key takeaways
- Treat repository rules, task evidence, external references, and generated notes as different context classes.
- Load authoritative material on demand and record where every consequential claim came from.
- Move durable decisions into reviewed files or handoff artifacts instead of relying on transcript recall.
- Rebuild context at phase boundaries and verify that stale assumptions were removed.
Key facts
| Fact | Verified value | Evidence |
|---|---|---|
| Repository instructions | Codex documents AGENTS.md as a repository-scoped instruction mechanism. | View source |
| Customization surface | Codex separates persistent instructions and reusable capabilities from one-time prompts. | View source |
| Context lifecycle | Claude Code documents context-window behavior and techniques for managing long sessions. | View source |
| External context | MCP defines a protocol boundary for exposing tools and contextual resources to clients. | View source |
What this guide helps you solve
Help teams design repeatable context boundaries for long coding tasks and large repositories.
Verification scope and limits
- Evidence basis
- Official documentationSpecification
- Verification scope
- The architecture is derived from documented Codex and Claude Code context surfaces plus the MCP resource and tool boundary.
- Limits and invalidation conditions
- - No model-specific context limit is claimed.
- - No retrieval strategy is presented as universally optimal.
- - Client behavior can change between releases and must be rechecked locally.
Separate context into classes with different trust and lifetimes
Repository instructions describe durable conventions; task evidence describes the current code and failure; external references describe an upstream contract; tool output is an observation; generated notes are a working interpretation. Mixing these classes into one undifferentiated transcript makes it difficult to tell what is current, authoritative, or safe to reuse.
Assign each class an owner, source, refresh condition, and retention rule. A build command may remain stable for months, while a failing stack trace should be refreshed after every fix attempt. Retrieved issue comments are evidence, not instructions, unless a maintainer explicitly promotes them.
Build a minimal sufficient working set
Start with the task, allowed paths, acceptance commands, and the closest repository instructions. Let the agent inspect the relevant entry points before loading broad documentation. Add references only when a decision depends on them, and capture the exact URL or file path with the resulting conclusion.
A smaller set is useful only when it remains sufficient. Missing a generated-code policy or package-specific test command can be more damaging than carrying extra text, so validate the working set against repository structure and the intended change boundary.
- Current task and explicit non-goals
- Applicable instruction files
- Relevant code and tests
- Verified external contracts
- Acceptance and rollback evidence
Persist decisions, not entire conversations
When a task spans sessions, write a concise handoff containing the current commit, decisions, evidence, changed files, commands run, unresolved questions, and next action. Keep it reviewable and free of credentials. A future session can reconstruct the task from this artifact and authoritative repository files without replaying every exploratory turn.
Promote stable conventions into maintained documentation only after a human reviews them. Temporary hypotheses should remain task-local and be deleted or marked superseded when evidence changes.
Refresh context at phase boundaries
Rebuild the working set when moving from diagnosis to implementation, implementation to verification, or one subsystem to another. Re-read changed files and rerun authoritative commands rather than trusting cached output. This keeps conclusions aligned with the repository state the agent is actually modifying.
- 01InventoryList active sources and mark their owner, age, and trust level.
- 02PruneRemove superseded traces, speculative notes, and unrelated references.
- 03ReloadRead current code, applicable instructions, and the latest verification output.
- 04HandoffRecord decisions and open risks in a durable, reviewable artifact.
Make context quality observable
Review whether major decisions cite a source, whether applicable instructions were loaded, whether the final verification used the current diff, and whether sensitive or untrusted text crossed into durable instructions. These controls evaluate the context process without pretending to measure hidden model reasoning.
- Every consequential claim has a file, command, or official URL.
- Handoffs name the exact repository revision.
- Untrusted content is labeled and never promoted automatically.
- Final checks run after the final change, not before it.
Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology