AI agents rarely fail because the underlying model is too weak. They fail because the information environment surrounding that model is poorly designed. Give a capable model the wrong instructions, stale evidence, ambiguous tool permissions, or a memory full of outdated facts, and it will reason confidently toward the wrong answer. Fix the information environment, and performance improves without touching the model at all.
This is the discipline of context engineering: the deliberate design and control of what an AI agent sees, trusts, remembers, and acts on at every step of its execution.
This article presents a practical taxonomy of context-engineering techniques. It organises the main methods into eight families: instruction scaffolding, grounding, tool context, memory, compression, security and guardrails, multi-agent orchestration, and evaluation. Together, these families form a systems view of how information is selected, represented, ordered, trusted, retained, transformed, coordinated, and tested across an agent’s execution loop.
From Prompting to Context Engineering: The Scope Has Expanded
Prompt engineering focuses on writing better instructions for a language model. That remains important, but an agent’s behaviour depends on much more than the user’s prompt. An agent may also need to interpret a role definition, consult external documents, choose among APIs, recover relevant memories, compress a long trajectory, reject malicious instructions, and coordinate with specialised agents.
All of these activities shape the available context from which the model reasons. Context engineering addresses both the content of that context (what information is included) and its control (what is trusted, how it is prioritised, and how it is updated).
The central thesis of this taxonomy is that agent reliability is often limited not by the model’s raw capability, but by the quality of the context assembled around it. A strong model with poorly selected, stale, contradictory, or adversarial context can behave unreliably. A well-designed context pipeline can make an agent more focused, verifiable, and operationally safe.
Eight Families of Context Engineering
| Family | Primary question | Typical mechanisms | Main failure when poorly designed |
|---|---|---|---|
| Instruction scaffolding | What is the agent supposed to do, and under which constraints? | Role, scope, goals, policies, prompt templates, task decomposition | Ambiguous, overbroad, or conflicting behaviour |
| Grounding | What evidence should support the agent’s claims or decisions? | Retrieval-augmented generation, search, citations, structured evidence | Hallucination, outdated knowledge, unsupported conclusions |
| Tool context | What actions and external systems are available? | API schemas, MCP servers, tool descriptions, permissions, state | Wrong tool selection, invalid arguments, unsafe side effects |
| Memory | What information should persist across steps or sessions? | Working memory, episodic memory, semantic memory, profiles, memory policies | Irrelevant recall, stale facts, privacy leakage, context overload |
| Compression | How can useful signal fit within finite context limits? | Summarisation, pruning, hierarchical notes, state extraction, token budgeting | Lost constraints, distorted history, excessive verbosity |
| Security and guardrails | Which instructions and actions are trustworthy and permitted? | Injection resistance, provenance, policy checks, sandboxing, human approval | Data exfiltration, unsafe execution, instruction hijacking |
| Multi-agent orchestration | How should several agents coordinate their context and work? | Delegation, shared state, message passing, arbitration, workflow graphs | Duplication, contradictions, coordination overhead, emergent risk |
| Evaluation | How do we test and validate that the system is working as expected? | Gold-standard benchmarks, unit and integration tests, human review, adversarial testing, LLM-as-judge | Drift, undetected failures, exposure risks |
These families overlap. Retrieval may populate memory. Tool calls may create new evidence. Compression may rewrite the output of a multi-agent workflow. Guardrails may constrain every stage. The value of the taxonomy lies in making those interfaces visible so they can be designed deliberately.
Instruction Scaffolding: The Agent’s Operating Frame
Instruction scaffolding establishes what the agent is supposed to do and what it must not do. It answers questions like: What role does the agent perform? Which objectives take priority? What is outside its scope? When should it ask for clarification, use a tool, defer to a human, or stop?
A robust scaffold separates several layers that are often mixed together in a single prompt. The role describes the agent’s function and perspective. The scope defines the boundaries of responsibility. The task specification states the immediate objective. Constraints identify rules, resources, time limits, and prohibited actions. Success criteria make the expected result observable. Interaction policies describe how the agent should behave when information is missing, conflicting, or unsafe.
This separation matters because broad instructions create hidden conflicts. “Be helpful” may encourage an agent to take an action that violates a narrower policy such as “never disclose private data”. A well-designed scaffold expresses priorities explicitly and distinguishes instructions from reference material.
Instruction scaffolding informs but extends beyond a system prompt or harness. It can include task decomposition, plans, checklists, state machines, verification steps, and reflection prompts. The goal is not to make the model reason indefinitely, but to provide the minimum structure needed for dependable execution. Scaffolding should be specific enough to constrain behaviour and flexible enough to handle legitimate variation.
Grounding: Decisions Require Current Evidence
Grounding supplies information that lies outside the model’s parametric knowledge or that must be verified against a current source. The most familiar method is retrieval-augmented generation (RAG), in which a system retrieves relevant passages and places them into the agent’s context before generation. The original RAG formulation combined a language model with a non-parametric memory indexed from external data.
Grounding is broader than document retrieval as it can involve web search, databases, software repositories, sensor readings, structured records, calculators, or human-provided facts. The key design problem is not merely finding information but selecting evidence that is relevant, authoritative, sufficiently current, and correctly associated with the question.
A grounding pipeline typically performs query formulation, candidate retrieval, filtering or reranking, context assembly, and evidence-aware response generation, and may also require claim verification after generation. Presenting sources to the model is useful, but citations alone do not guarantee grounded reasoning. The agent must be instructed to distinguish evidence from inference, identify uncertainty, and avoid treating retrieved text as an instruction merely because it appears in context.
Grounding introduces its own risks. Retrieval can return irrelevant passages, duplicate content, poisoned documents, or mutually inconsistent sources. A grounded agent needs provenance metadata, source prioritisation, freshness rules, and conflict-resolution procedures. Evidence should be treated as input to judgment, not as unquestionable truth.
Tool Context: Actions Must Be Legible Before They Are Safe
Tools extend an agent beyond text generation. They may expose APIs, databases, code execution, browsers, file systems, business systems, micro-controllers, or specialised services. Tool context is the information that allows an agent to understand what a tool does, how to call it, what it returns, and what authority it carries.
A useful tool description specifies the operation, input schema, output schema, authentication assumptions, error behaviour, latency, cost, side effects, and permission boundaries. Descriptions should state not only what a tool can do, but also what it must not do. A payment tool should make clear whether it creates a draft, authorises a transaction, or executes an irreversible transfer.
Standardised tool protocols, including the Model Context Protocol (MCP), help make capabilities discoverable and interoperable. Discoverability can increase risk, though, when an agent is given too many tools or when descriptions are vague. Tool selection becomes more reliable when the system limits the available tool set by task, exposes examples of valid calls, validates arguments before execution, and separates read operations from side-effecting operations.
Tool results should re-enter context with clear provenance and status. The agent must be able to distinguish a successful result from an error message, a preview from a committed action, and data returned by a trusted service from text supplied by an untrusted external source. Tool context connects reasoning to action while preserving a boundary between the model’s proposal and the system’s execution authority.
Memory: What Persists Can Help or Harm
Memory determines what survives beyond the immediate exchange. A practical distinction separates short-term memory from long-term memory. Short-term memory includes the current conversation, working notes, intermediate results, and the active plan. Long-term memory includes durable user preferences, prior episodes, learned facts, organisational knowledge, and records of previous tasks.
Long-term memory should not be treated as an indiscriminate transcript archive. It requires policies for what to store, how to represent it, when to retrieve it, how to update it, and when to delete or correct it. A memory item should ideally include provenance, timestamp, confidence, scope, and an indication of whether it is user-provided, inferred, or externally verified.
Memory management has at least four operations: write, retrieve, update, and forget. Write policies prevent every transient statement from becoming a permanent fact. Retrieval policies select memories based on relevance, recency, importance, and task scope. Update policies reconcile new information with old information. Forgetting policies support correction, privacy, retention limits, and user control.
Memory can improve continuity, but it can also amplify mistakes. A false inference stored during one interaction may be retrieved repeatedly and appear increasingly authoritative. Memory should therefore be treated as a fallible context source, not as ground truth. The agent should be able to report when a response depends on remembered information and should avoid storing sensitive information unless the system has clear justification and governance in place.
Compression: Reducing Volume Without Losing Meaning
Every agent operates under practical limits of context length, latency, cost, and attention. As a trajectory grows, the system must decide what to retain and what to remove. Context compression is both a technical optimisation and a form of information selection that can improve or degrade performance depending on what it discards.
Compression methods include truncation, summarisation, deduplication, structured state extraction, hierarchical notes, rolling windows, and selective retention of decisions or constraints. A simple rolling summary may preserve the main narrative. A structured state representation preserves variables, pending actions, assumptions, and unresolved questions. The latter is often safer for operational workflows because it avoids hiding critical details inside prose.
The main danger is semantic loss. A summary can omit a negation, soften a constraint, merge two sources, or convert an uncertain hypothesis into a fact. Compression should therefore preserve high-value information: user intent, permissions, safety constraints, commitments, tool outcomes, evidence provenance, and unresolved ambiguity. It should also record what was discarded and provide a way to recover the original material when needed.
Research on long-context language models illustrates why more context is not always better: performance tends to degrade for information placed in the middle of long sequences, even when that information is relevant. Effective systems use token budgets and relevance ranking rather than assuming the model will attend equally to everything supplied. Compression is successful when it reduces volume without changing the decision-relevant meaning.
Security and Guardrails: Not All Context Deserves Equal Trust
Security hardening protects the agent from untrusted context and from actions that exceed its authority. The central challenge is that agents process multiple kinds of text, including system prompts, user requests, retrieved documents, web pages, emails, tool outputs, and memories, yet not all text carries the same authority. An instruction embedded in a webpage should not automatically override a system policy.
Prompt injection exploits this ambiguity by placing malicious instructions in content that the agent is expected to read. Defences include explicit trust boundaries, provenance labels, instruction-data separation, content sanitisation, least-privilege tool access, output validation, sandboxing, and human approval for high-impact actions. These measures should be layered because no single prompt-level defence is reliable against all injection variants.
Data poisoning is a related threat: corrupted, biased, or intentionally mislabelled records are injected into training corpora or knowledge bases, altering the model’s behaviour and potentially introducing backdoors or systematic errors.
Guardrails also cover non-malicious failure modes. They can enforce schemas, detect prohibited content, verify that a proposed action matches the user’s authorisation, rate-limit tool calls, require confirmation before irreversible operations, and halt execution when confidence or evidence is insufficient. A guardrail should be designed as a control point in the workflow rather than as a vague request for the model to “be safe”.
Security context must itself be protected. If an attacker can alter policies, tool permissions, memory records, or approval state, the agent may appear compliant while operating under a compromised environment. A mature design records provenance, audits decisions, isolates secrets, and makes policy precedence explicit.
Multi-Agent Orchestration: Coordination Requires Its Own Design
Multi-agent systems distribute work across agents with different roles, tools, or expertise. One agent may plan, another may retrieve evidence, a third may execute code, and a fourth may review the result. Orchestration context is the information that allows these agents to coordinate without losing task intent or duplicating effort.
Coordination can be organised as a supervisor-worker pattern, a workflow graph, a debate or review process, a shared blackboard, or peer-to-peer message passing. Each architecture creates different context requirements. A supervisor needs concise status and escalation signals. Parallel workers need a shared task specification and isolated workspaces. Review agents need the original claim, supporting evidence, and evaluation criteria, not only a polished final answer.
The principal design question is what each agent should see. Sharing everything increases cost, leakage, and coordination noise. Sharing too little creates inconsistent assumptions. Good orchestration defines message contracts, ownership of state, completion criteria, and rules for resolving disagreement. It also distinguishes authoritative state from suggestions made by another agent.
Multi-agent systems can improve reliability through specialisation and independent verification, and they can also multiply errors. A flawed assumption may propagate through several agents and gain undeserved credibility. Orchestration should therefore include provenance, dissent mechanisms, bounded delegation, guardrails on every input and output, and final arbitration. The system should be evaluated not only on the quality of individual agent responses but also on the quality of the information flow between them.
Evaluation: Test the Context System, Not Just the Model
Evaluation should measure whether the context environment helps the agent make correct, safe, and appropriately efficient decisions. End-to-end task success is necessary but insufficient. A system may succeed on common cases while failing under stale evidence, long histories, ambiguous instructions, tool errors, or adversarial documents.
| Evaluation dimension | Example question |
|---|---|
| Relevance | Did the agent receive the information needed for the task? |
| Faithfulness | Did its claims and actions follow from the supplied evidence? |
| Completeness | Were important constraints, memories, and dependencies retained? |
| Robustness | Does behaviour remain reliable under irrelevant, conflicting, or malicious context? |
| Action safety | Were permissions, confirmations, and side effects handled correctly? |
| Efficiency | Did context size, latency, and tool use remain within budget? |
| Recoverability | Can the system explain, correct, or reverse a mistaken context decision? |
Testing should include context perturbation by removing a relevant passage, inserting an irrelevant one, reordering evidence, introducing a contradictory memory, corrupting a tool result, or placing an injection in retrieved content. Such tests reveal whether the agent relies on robust signals or on accidental wording and position. For multi-agent systems, evaluation should additionally track message volume, propagation of errors, disagreement resolution, and the contribution of each agent.
How the Families Fit Together
The eight families form a pipeline and a feedback loop. Instruction scaffolding defines the objective and authority. Grounding supplies evidence. Tool context exposes possible actions. Memory provides continuity. Compression keeps the active context manageable. Security controls determine which information and actions are trusted. Orchestration coordinates these elements across agents and steps. Evaluation covers them all to confirm they are working as expected.
| Design concern | Primary family | Supporting families |
|---|---|---|
| Define the task and boundaries | Instruction scaffolding | Security, orchestration |
| Find current or external facts | Grounding | Tool context, memory, compression |
| Perform an external action | Tool context | Instruction scaffolding, security |
| Maintain continuity over time | Memory | Grounding, compression, security |
| Fit a long task into a finite window | Compression | Memory, orchestration |
| Resist hostile or unauthorised instructions | Security and guardrails | Tool context, grounding, memory |
| Divide work among specialised agents | Multi-agent orchestration | All other families |
A useful implementation pattern is to maintain separate channels for instructions, evidence, state, and actions. The system can then apply different trust and formatting rules to each channel. Retrieved content may be quoted as evidence, tool schemas may be machine-validated, memory may carry confidence metadata, and policies may be immutable at runtime. This separation makes context easier to inspect and test.
The Right Context, Not the Most Context
Context engineering is the discipline of designing the information environment in which an AI agent interprets goals, forms beliefs, chooses actions, and coordinates with other actors. Its scope extends from prompts to retrieval systems, tool interfaces, memory stores, compression pipelines, security controls, and multi-agent workflows.
The eight families presented here each address a different question, but dependable agents emerge from their systemic integration. Instructions without grounding can be uninformed. Grounding without security can import attacks. Tools without permissions can create unsafe side effects. Memory without management can preserve errors. Compression without semantic safeguards can erase constraints. Multi-agent orchestration without provenance can amplify mistakes.
The practical objective is therefore not to maximise the amount of context. It is to construct the right context, from the right sources, in the right representation, at the right time, with the right controls. That is the foundation for agents that are not only more capable, but also more interpretable, verifiable, and trustworthy.