Use this guide to inventory, select, constrain, refresh and test context instead of simply making a prompt longer.
What is context engineering?
Anthropic's context engineering guide describes context engineering as selecting and maintaining the information available to a model at inference time, including instructions, tool definitions, retrieved data and interaction history. It argues for a compact, high-signal context and describes just-in-time retrieval, compaction, notes and subagents as possible techniques. This is conceptual practitioner guidance, not a standard, universal design or guarantee of quality or security.
The useful distinction is simple: context engineering deals with what the model sees, in what form, in what order and under what constraints. It does not cover the model's weights, its training data or the inference infrastructure.
Context and execution meet, but they are not the same job. A context manager may select a tool definition or a retrieved passage, while the surrounding runtime still decides whether to execute a requested call, how to isolate state and when to stop. To map those responsibilities, understand the surrounding agent harness. Keeping the boundary clear stops a well-formed context being mistaken for effective authorisation or safe execution.
Context engineering versus prompt engineering
| Dimension | Prompt engineering | Context engineering |
|---|---|---|
| Scope | The instruction text given to the model | All information available at inference: instructions, tools, retrieved data, history, state |
| Operating work | Wording, structure, examples in the prompt | Selection, ordering, budgeting, freshness, permissions, compaction, retrieval policy |
| Failure mode | Ambiguous or conflicting instructions | Stale, irrelevant, over-budget or unauthorised context |
| Evaluation | Does the model follow the instruction? | Is the context relevant, complete, current and within budget? |
| Relationship | A subset of context engineering | The wider discipline that includes prompt engineering |
One does not replace the other. A well-engineered context includes well-crafted instructions, but it also manages the retrieved knowledge, the tool definitions, the history and the working state.
The components of an agent's context
The context inventory worksheet below is an editorial synthesis. Adapt it to your task and system.
| Component | Job | Source | Owner | Selection rule | Freshness rule | Trust or permission boundary | Budget or limit | Failure signal | Test |
|---|---|---|---|---|---|---|---|---|---|
| System instructions | Define task, tone, constraints | Product owner | Product owner | Fixed per task | Review on task change | Change-controlled system layer; untrusted content cannot amend it | Token budget | Model ignores constraint | Representative task test |
| Tool definitions | Describe available tools and parameters | Engineering lead | Engineering lead | Include only tools the subject may use | Update on tool change | Tool permissions | Token budget | Model calls unauthorised tool | Permission test |
| Retrieved knowledge | Supply task-relevant passages | RAG pipeline | Data owner | Relevance threshold, permission filter | Refresh on source change | Source permissions | Passage count, token budget | Irrelevant or restricted passage retrieved | Retrieval relevance test |
| Interaction history | Maintain conversation state | Session store | Engineering lead | Compaction policy, retention | Prune per policy | Session isolation | Token budget | Context overflow, stale history | Compaction test |
| Working state | Track intermediate results | State store | Engineering lead | Persist per task | Clear on task completion | Task isolation | Token budget | State corruption | State integrity test |
Start with the task, decision and failure modes
Before adding context components, define:
- The task. What specific question or decision will the model support?
- The decision boundary. What may the model answer, and what must it defer?
- The failure modes. What goes wrong when context is stale, irrelevant, over-budget or unauthorised?
The task determines which context components are needed and what their constraints should be. A customer-support agent needs different context from a code-review agent.
Turn these decisions into a small context contract. Record what evidence must be present before the model may answer, which information must stay out, and what the runtime should do when a required source is missing or contradictory. For example, an answer that supports a policy decision may require a current policy passage and its version, while an informal navigation answer may tolerate a narrower evidence set. The contract should name the owner who can change those rules and the tests that expose a breach.
Define omission behaviour as deliberately as inclusion. If retrieval returns no eligible passage, the model should not silently fill the gap from general knowledge when the task requires internal evidence. It might instead state that the approved corpus did not supply an answer, ask a clarifying question or route the case to a person. Which response is appropriate is a product and risk decision, not a universal context-engineering rule.
For the wider organisational build, see build the wider internal AI knowledge base, which covers the governance, source selection and operating model that frame the context layer.
Select high-signal instructions and retrieved knowledge
Instructions should be compact, unambiguous and task-specific. Avoid instructions that conflict with each other or that the model cannot act on. Test instructions against representative tasks before release.
Retrieved knowledge should be relevant, current and permission-respecting. The retrieval policy determines which passages are eligible for context. A passage that is topically relevant but restricted to a different team should not enter the context for a user without that permission.
The RAG pipeline architecture guide covers the ingestion and runtime stages that supply retrieved knowledge. The retrieval design, including index type, retrieval count and reranking, is a pipeline decision that feeds into context assembly.
Before retrieval can work well, the source documents must be prepared. The document preparation guide covers source selection, parsing, metadata, versioning and ingestion readiness.
Make the selection rule observable. For each retrieved item, retain the source and exact version, the permission decision, the retrieval query or filter, and the reason it was included. Also record eligible candidates that were excluded when that evidence is useful for diagnosis. This lets an evaluator distinguish a source-readiness failure from a retrieval miss, an over-aggressive context limit or an assembly error. The record supports investigation; it does not prove that the selected passage is true or sufficient.
Manage history, working state, memory and compaction
Interaction history grows with each turn. Without management, it can exceed the context budget or introduce stale information. Compaction strategies include:
- Summarisation. Replace older turns with a summary.
- Sliding window. Keep only the most recent N turns.
- Relevance filtering. Keep only turns relevant to the current task.
- External memory. Store long-term facts in a separate store and retrieve them just in time.
Working state tracks intermediate results within a task. It should be cleared when the task completes and isolated between tasks.
Memory, in the sense of persistent knowledge across sessions, is a separate concern from context. A memory store is a source that feeds into context assembly, not a context component itself.
Treat tools and MCP resources as permissioned interfaces
Tool definitions are part of the context. They tell the model what tools are available and how to call them. But a tool definition in the context is not a permission grant. The tool gateway must check the subject's permissions before executing any tool call.
The Model Context Protocol specification (revision 2026-07-28) defines how servers expose resources, prompts and tools over a negotiated protocol. The specification assigns implementers responsibility for consent, authorisation, privacy and access-control decisions. Protocol conformance is not consent, authorisation or safety.
MCP is a connection protocol, not a trust mechanism. A connected server is not automatically trusted. The harness must enforce permissions at the tool gateway regardless of the protocol used.
Manage finite context without a universal formula
Context windows are finite. There is no universal formula for how much context to use, in what order, or how to allocate budget across components. The allocation depends on the task, the model, the corpus and the quality requirements.
Controlled research has found that information placement affects performance in defined long-context experiments. Liu et al. (2024) reported that performance varied with where relevant information appeared in long inputs, and was often lower when it appeared in the middle. This result does not apply identically to every current model, task or prompt. It does not prove that long context is unusable or that RAG is always superior.
Practical guidance:
- Start with the minimum context that answers the task.
- Add components only when they improve measured behaviour.
- Monitor context utilisation and adjust the budget as the task and corpus evolve.
- Test placement effects for your specific model and task rather than assuming a universal ordering.
Provenance, permissions and untrusted content
Every piece of context should have traceable provenance: where it came from, who created or changed it, which exact version was selected and what permissions apply. That record supports review, deletion and currency decisions. Provenance does not by itself make a source trustworthy, its content correct or its use authorised.
Treat content as untrusted when the system has not established that it is eligible for this task, subject and execution context. Passing one verification step does not create universal trust. This boundary includes:
- Documents from sources that have not been approved for the task.
- Retrieved passages whose permissions have not been checked.
- User-supplied content that may contain instruction-like text.
The NCSC's secure design guidance supports threat modelling, least privilege, input checks and constrained actions. In the context layer, this means:
- Verify the provenance and permissions of every context component.
- Treat untrusted content as data, not as instructions.
- Constrain the actions the model can take based on untrusted content.
- Log the context assembly for audit and diagnosis.
Context engineering selects what the model receives, but source approval and permissions determine whether a document belongs there. Once those decisions are made, check the exact document version as a separate intake step.
.mdSiren is a document security workspace for AI. When it launches, Standard Scan will check the exact version for supported prompt-injection and document-borne risks, route it to Approved, Needs review or Quarantine, and keep the Approved exact version in your private Library. If the file changes, check the new version. This document decision does not authorise the source, validate its claims or replace context selection and evaluation.
See what Standard Scan checks.
Evaluate context behaviour with representative tasks
Measure context quality against representative tasks. Evaluation should cover:
- Relevance. Does the context contain the information needed for the task?
- Completeness. Is any required information missing?
- Currency. Is the context current, or has the source changed?
- Permission compliance. Does the context respect the subject's permissions?
- Budget compliance. Is the context within the allocated budget?
Build cases around representative user tasks rather than isolated prompt snippets. Include ordinary requests, ambiguous requests, stale-source cases, permission changes, contradictory passages, missing evidence and long interaction histories. Record the assembled context alongside the answer so that a reviewer can see whether a failure began in selection, ordering, compaction or generation. Use both expected-success and expected-deferral cases; a refusal or escalation can be the correct outcome for a bounded task.
When comparing two context policies, keep the model, instructions and test set stable where practicable, then change one selection or assembly rule at a time. Review aggregate measures, individual failures and access-control results separately. A higher average answer score should not conceal a restricted passage reaching the wrong subject, and a clean permission test does not establish factual correctness. Retain the context-policy version with each result so that later regressions can be tied to a specific change.
The RAG evaluation guide covers the full measurement method, including test sets, metrics, release gates and regression monitoring. Context evaluation is one dimension within that method.
The Azure RAG LLM evaluation guide treats groundedness, completeness, context utilisation, relevance and correctness as distinct, workload-dependent dimensions. No single metric or threshold proves accuracy or safety.
A practical context-engineering checklist
- Define the task, decision boundary and failure modes.
- Inventory every context component: instructions, tools, retrieved knowledge, history, state.
- Assign an owner, selection rule, freshness rule and permission boundary to each component.
- Set a token budget for each component and for the total context.
- Verify provenance and permissions for every context source.
- Test with representative tasks: does the context produce acceptable answers?
- Test permission compliance: does restricted content stay out of the context?
- Test compaction: does history management preserve relevant information within budget?
- Monitor context utilisation and adjust the budget as the task and corpus evolve.
- Rerun evaluation after any change to the model, tools, corpus or context policy.
Frequently asked questions
What is context engineering? It is the deliberate selection and maintenance of the information made available to a model at inference time, including instructions, tool definitions, retrieved knowledge, interaction history and working state.
How is it different from prompt engineering? Prompt engineering focuses on the instruction text. Context engineering covers all information at inference time, including the retrieved knowledge, tool definitions, history and state. Prompt engineering is a subset.
Does context engineering include RAG? RAG is a retrieval mechanism that supplies context. Context engineering includes the selection, ordering, budgeting and permission-checking of that retrieved content, as well as the other context components.
Is memory the same as context? No. Memory is a persistent store that can feed into context assembly. Context is the information actually available to the model at a given inference step.
How much context should an AI agent receive? There is no universal answer. Start with the minimum that answers the task, add components only when they improve measured behaviour, and monitor utilisation.
How do you test context quality? Use representative tasks to evaluate relevance, completeness, currency, permission compliance and budget compliance. Rerun after changes.
