What is Context Engineering?
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
Context engineering is an engineering discipline, not a promise that a longer prompt or a named rule file makes a model reliable. A useful context contract specifies the task, principal and tenant, allowed sources, source revisions, freshness, sensitivity, token and latency budgets, output contract, and failure behavior. It complements prompt engineering: wording matters, but the system must also select, order, and validate the information around that wording. Separate stable instructions, retrieved knowledge, working state, durable memory, and runtime tool results. Retrieved documents, comments, summaries, and tool output can be stale, malicious, incomplete, or unauthorized. Apply access control before retrieval and ranking; preserve citations; keep a no-evidence path; and never let a model, document, or rule file authorize data access or external side effects. Provider-specific files such as project rules or Agent instruction files are adapters, not universal standards. Their loading path, precedence, scope, and version support must be tested in the target Host. Measure any context change on representative tasks using task success, evidence coverage, contradiction and leakage rates, latency, cost, and human correction rather than fixed token ratios or claims that context "eliminates" hallucinations.
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.