The Seven Components of Agent Context Engineering: A Production-Ready Context Assembly Checklist

A Fortune 100 insurance company spent $2.3 million and six months building a multi-agent claims processing system on top of a leading frontier model. The orchestration was clean, the workflows were well-mapped. In the first week after launch, it approved a $400,000 fraudulent claim.

The post-mortem found no reasoning failures — just three problems: the agent had no memory of the claimant's interaction history; the fraud detection rules lived in a separate system it couldn't access; and its system prompt was two sentences long — "You are a helpful insurance claims assistant. Process claims accurately and efficiently." The model was smart enough. It just wasn't given what it needed to make a good decision.

This is the defining failure pattern of the current moment. The models are good. The frameworks are mature. Teams are still shipping expensive demos. Because what determines decision quality isn't the model or the framework — it's what actually ends up inside the context window at the moment of inference.

The Mental Model: LLM as CPU, Context Window as RAM, Context Engineering as OS

Andrej Karpathy described context engineering as "the delicate art and science of filling the context window with just the right information to serve the next step."

For architects, there's an analogy that makes this concrete: the LLM is the CPU, responsible for reasoning over its inputs; the context window is RAM, the working memory for every decision; context engineering is the operating system, determining what gets loaded, when, and in what format.

When a laptop runs out of RAM, applications slow down, crash, and throw errors — even if the CPU is perfectly capable. Agents with wrong or incomplete context behave exactly the same way. Swapping in a faster CPU won't fix an operating system that's loading the wrong data.

This also explains the fundamental difference between prompt engineering and context engineering. Prompt engineering is a human hand-writing a static string for a single conversation. Context engineering is a system that dynamically assembles context at runtime from multiple sources, across multiple steps, with each step building on the last. That's the gap that makes pure prompt-tuning fall short in production.

The concept of Context Engineering was formally articulated by Andrej Karpathy around 2025, to distinguish it from the earlier practice of "Prompt Engineering." Prompt engineering was born in single-turn dialogue scenarios, where the core task was manually tuning a fixed piece of text for better model output. Context engineering targets multi-step, multi-agent automated pipelines — systems where no human is reviewing the prompt before each call, and context must be dynamically assembled by code at runtime. The gap between the two is analogous, in software terms, to the difference between "manually typing commands in a terminal" and "writing a complete scheduling system." This explains why many agents that work beautifully in internal demos start failing in production: demos are typically backed by carefully hand-prepared context, while production environments have no such human safety net.

The Seven Components of Agent Context

When designing production-grade agent systems, context can be decomposed into seven components. A failure in any one of them can trigger a cascade. A trigger (user, agent, scheduled task, or event) initiates the work; a context assembler integrates all seven input types; the LLM reasons over them; structured output is produced; and state and long-term memory are updated in return.

1. Instructions / System Prompt

The system prompt is a contract, not a vibe. In production, it needs to specify roles, boundaries, decision criteria, and escalation rules. For a claims agent, that means precise auto-approval thresholds, mandatory fraud checks before any payout over $50,000, and explicit escalation rules for edge cases. "Process claims accurately" is a demo prompt. A real system prompt should be version-controlled like a spec document, with every change reviewed as carefully as a code change.

2. Long-Term Memory

This is where most enterprise agents quietly break down. Agents need persistent memory across sessions: structured memory about entities, relationships, and historical decisions — not just chat history. A telecom example illustrates this well: a customer calls about a billing issue. Without long-term memory, the agent issues a standard $50 credit. With long-term memory, the context reveals this is a $456,000-per-year account with a history of escalated complaints — the correct response is an executive-level retention intervention. The model is identical in both cases. The decision is completely different.

3. State / Short-Term History

In multi-agent workflows, agents need to know what other agents have already done. In a three-agent claims pipeline, without state passing, the third agent either redoes the work of the first two, or makes a decision without knowing their conclusions — the "amnesia problem."

State requirements also grow with autonomy. A routing agent passes classification metadata. A co-pilot agent passes draft responses. A resolution agent passes full execution context. If state management doesn't evolve as agent autonomy increases, context breaks down.

4. Retrieved Information (RAG)

RAG is just the entry ticket. What matters is the quality and discipline of retrieval. Ask a financial advisor agent "Can this client invest in a private equity fund?" A bad pipeline dumps five loosely related compliance documents — roughly 8,000 tokens of legal text — into the context, and the agent hallucinates a policy interpretation. A good pipeline retrieves narrowly, reranks, trims, and includes source attribution.

You also need to treat retrieval as an attack surface. Every retrieved document is a potential injection vector. A poisoned document containing hidden instructions gets processed as legitimate context — this is Cross-domain Prompt Injection (XPIA). Wrapping retrieved text in clearly delimited, labeled blocks and explicitly telling the model that content inside those blocks is data, not instructions, eliminates most of that attack surface.

RAG (Retrieval-Augmented Generation) is an architectural pattern where relevant documents are dynamically retrieved from an external knowledge base before an LLM call, and those documents are sent to the model alongside the user's query. It addresses two inherent LLM limitations: knowledge cutoffs (training data has an expiration date) and private knowledge blind spots (enterprise internal documents aren't in the training set). A typical RAG pipeline has three stages: document vectorization (converting text into embeddings for similarity search), similarity retrieval (finding the most relevant document chunks for the current query), and context injection (inserting retrieved results into the prompt). XPIA (Cross-domain Prompt Injection Attack) is a class of security threat that RAG introduces: an attacker embeds hidden instructions inside a document that will later be retrieved. When that document is injected as context, the malicious instructions may be treated by the model as legitimate directives, bypassing system prompt constraints.

5. Prompt / Input

This is the trigger that initiates the work. In enterprise systems, the "user" is often another agent, a scheduled job, or an event from an external system — not a person typing. Design input contracts for those callers, not just for chat scenarios.

6. Available Tools

Tools define what the agent can do, not just what it knows. Tool definitions in the context window tell the model what actions exist, what parameters they require, and what outputs to expect. This is the significance of MCP: it makes tools consistently discoverable and callable across different services. An agent that knows it has access to a fraud detection API, a claims database, and a document validation service can plan around them. Tool definitions should be clean and deterministic — sloppy tool descriptions are context noise in their own right.

MCP (Model Context Protocol) is an open standard released by Anthropic in late 2024, designed to standardize how LLMs connect to external tools and data sources. Before MCP, every tool vendor and every agent framework had its own tool-calling format, making tool definitions non-portable across platforms and forcing enterprises to write multiple adapter layers for the same tool in multi-vendor environments. MCP uses a client-server architecture: tool providers expose an MCP Server that declares what tools they offer and their parameter schemas; agents discover and invoke those tools through an MCP Client, with the protocol layer abstracting away underlying differences. This turns "tool discoverability" from a bespoke per-vendor implementation into an interoperable standard, and gives tool definition versioning and security auditing a unified entry point.

7. Structured Output

Downstream systems shouldn't have to parse natural language prose. When a claims agent finishes, it should output structured JSON containing the decision, claim ID, risk score, reasoning chain, and audit information. That output can be fed directly into payment systems, notification services, and audit logs without human interpretation. The reasoning array provides an auditable decision trail; the audit block tells the compliance team exactly which model and which tools produced that decision. Pair this with low temperature, strict schema, and validation gates — you're not chasing identical text outputs, you're engineering deterministic outcomes from non-deterministic components.

Walking a Decision Through the Full Stack

At every step, the decision is entirely determined by what's in the window. At the trigger stage, a customer submits a claim; the orchestrator loads the system prompt, the claimant's history from long-term memory, the claim documents via RAG, and a tool list (fraud check, payment system, escalation queue). During reasoning, the claims agent calls the fraud tool to get a risk score and adds it to working context, retrieves similar historical claims, and checks policy limits. At the decision stage: approve (structured output to payment), flag for review (hand off with a full context summary), or deny (structured output with reasoning).

Miss the fraud score, you get a bad decision. Lose state between steps, you get duplicate or contradictory actions. Retrieve the wrong document, you get a hallucinated policy clause.

Why Context Is the Root Cause Behind Your Other Problems

The most powerful argument here is this: reliability, security, cost, and platform fragmentation all trace back to context.

Reliability. Non-determinism forces you to lock down inputs (versioned prompts, system messages, retrieval sources), constrain outputs (schema), and keep tool definitions stable — every one of these is a context decision. Loose context means unstable behavior.

Security. The "lethal triad" is: access to private data, exposure to untrusted tokens, and a data exfiltration channel. Forged invoice attacks work because unsanitized untrusted content enters the window. That's a context pipeline problem, not a model problem.

Cost. A project that projected 10x ROI and delivered 2x didn't miscalculate the business case — it failed to account for context costs. Bloated context drives up token spend per call. Bad retrieval burns tokens on irrelevant documents. Missing memory forces repeated reasoning.

Platform fragmentation. In one case study, six pilots across four vendors each had their own identity model, data contract, retrieval pattern, and memory store — not a single agent could assemble a unified organizational context. The problem wasn't the tools; it was that context couldn't flow. Context is the control plane of an agent system. Either engineer it deliberately, or pay for it later.

Pre-Launch Checklist

Before putting an agent into production, answer these questions for each of the seven components: Does the system prompt encode thresholds, escalation rules, and mandatory checks — with version control? Can long-term memory let the agent see entity history across sessions? State — what does each agent pass to the next, and does it scale with autonomy? RAG — what's the token budget, reranking logic, and source attribution for retrieved content? Prompt — does it handle non-human triggers (agents, events, scheduled jobs)? Tools — are definitions clean, minimal, and discoverable (MCP)? Output — is it schema-validated, auditable, and machine-consumable?

If you audited your production agents today, which of the seven components would you find missing or treated as an afterthought? Can you catch it before the first costly decision does?