What is Context Engineering?
Updated on
Context Engineering is the design and operation of the information supplied to a language model for a specific task: instructions, task data, retrieved evidence, state, tool results, and their provenance, permissions, freshness, and budget.
Quick Facts
| Full Name | Context Engineering Paradigm |
|---|---|
| Created | Emerged with the popularization of long-context LLMs and AI IDEs |
How It Works
Assembly lifecycle
A production context pipeline begins with a task contract, resolves the authenticated principal and tenant, authorizes candidate sources, retrieves and ranks evidence, normalizes source metadata, allocates a token budget, assembles the request, and records what the model actually saw. The output then passes validation before it can update state or invoke a tool. This lifecycle matters because retrieval quality alone cannot protect an application from unauthorized, stale, contradictory, or oversized context.
Trust and lifetime boundaries
Stable system instructions, user input, retrieved knowledge, working state, durable memory, and runtime tool results have different owners and lifetimes. Preserve source, revision, authority, sensitivity, and freshness metadata across retrieval, summaries, and handoffs. Treat external content as untrusted data even when it appears in a developer document or tool response; neither the model nor retrieved text may grant access or approve side effects.
Budgeting and graceful degradation
A context window is a hard capacity limit, not a quality target. Reserve output headroom, account for tokenizer-specific size, prioritize required evidence and constraints, and reject the run when an essential item cannot fit. Optional evidence can be summarized, fetched just in time, or omitted with an explicit reason. Silent truncation is dangerous because it can remove a policy, citation, or counterexample while leaving the request syntactically valid.
Compaction, memory, and recovery
Long-running agents need checkpoints and compaction, but a generated summary is a lossy derivative rather than a new source of truth. Store durable facts separately from conversational prose, retain references to authoritative records, version summaries, and allow correction and deletion. After a context reset, reconstruct the minimum state required to continue and revalidate permissions instead of replaying old authority.
Evaluation contract
Pin the model, tokenizer, context revision, retrieval fixtures, and scoring rules. Compare task success, evidence and citation coverage, contradiction rate, unauthorized disclosure, latency, token cost, recovery behavior, and human correction on representative slices. Anthropic's context-engineering guidance emphasizes finite attention and high-signal selection; LangChain's documentation distinguishes model, tool, and lifecycle context. Neither source supplies a universal token ratio, so teams must measure their own workload.
Key Characteristics
- Task contract: defines outcome, constraints, evidence scope, budgets, and verification before assembling a request
- Trust-aware layers: distinguishes instructions, knowledge, memory, and runtime results by source and lifetime
- Permission-first selection: applies tenant and object authorization before relevance ranking or compression
- Provenance and freshness: records source, revision, authority, validity interval, and citation expectations
- Budgeted assembly: reserves response headroom and degrades or fails safely when required context cannot fit
- Evidence-based evaluation: compares context revisions with reproducible tasks, safety cases, latency, cost, and recovery
Common Use Cases
- Preparing a bounded coding task packet with relevant interfaces, tests, risks, and acceptance criteria
- Building RAG responses that filter by permissions, freshness, authority, diversity, and result size
- Maintaining Agent state with explicit consent, expiry, correction, deletion, and tenant isolation
- Adapting a reviewed project contract to a tested AI coding client without assuming a universal rule-file convention
- Evaluating a retrieval, memory, or context-compression change against an evidence-backed regression set
Example
Loading code...Frequently Asked Questions
How is context engineering different from prompt engineering?
Prompt engineering focuses on instructions and expression. Context engineering additionally governs evidence selection, state, provenance, permissions, ordering, budgets, and evaluation. They overlap; neither replaces trusted authorization, validation, or application logic.
Does more context reduce hallucinations?
Not reliably. Extra context can be stale, contradictory, irrelevant, or adversarial and may obscure needed constraints. Select evidence by task, permission, authority, freshness, and coverage, then evaluate unsupported-claim and citation rates on real tasks.
Are AGENTS.md, Cursor Rules, or similar files a context engineering standard?
No. These files are client-specific integration conventions. Verify the target client's version, path, precedence, scope, and opt-in behavior. Keep normative project requirements in a reviewed source of truth and treat provider files as narrow adapters.
Can a retrieved document or tool result grant access?
No. Treat retrieved content and tool output as untrusted data. Authentication establishes a principal; trusted server-side policy must authorize the tenant, object, action, purpose, quota, and side effects for every request.
How should a team evaluate a context change?
Pin the model, tokenizer, context revision, and representative fixtures. Compare task success, evidence and citation coverage, contradiction rate, unauthorized disclosure, latency, token cost, recovery behavior, and human correction against a baseline.