A Fortune 100 insurer spent $2.3 million and six months building a multi-agent claims system on a top frontier model. Clean orchestration, well-mapped workflows. The week after launch, it approved a $400,000 payout on a fraudulent claim.

The post-mortem didn't find a reasoning failure. It found three things:

• The agent had no memory of previous interactions with that claimant.
• The fraud-detection rules lived in a separate system it couldn't reach.
• 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 decide.

This is the 2026 failure mode. Models are good, frameworks are mature, and teams are still shipping expensive demos, because the thing that determines decision quality is neither of those. It's whatever ends up in the context window at the moment of the call.

The mental model: LLM = CPU, context window = RAM, context engineering = the OS

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

The analogy that makes this concrete for architects:

┌────────────────────────────────────────────────────┐
│ CONTEXT ENGINEERING (the operating system) │
│ decides what is loaded, when, and in what format │
│ │
│ ┌──────────────┐ ┌────────────────────┐ │
│ │ LLM (CPU) │◄──────►│ Context Window(RAM)│ │
│ │ reasons │ │ working memory for │ │
│ │ over input │ │ every decision │ │
│ └──────────────┘ └────────────────────┘ │
└────────────────────────────────────────────────────┘

When a laptop runs out of RAM, apps slow down, crash, and produce errors, even though the CPU is perfectly capable. An agent with a wrong or incomplete context window behaves the same way. Swapping in a faster CPU doesn't fix an OS that loads the wrong data.

Prompt engineering is a human writing a static string for a single turn. Context engineering is a system dynamically assembling context from multiple sources, at runtime, across multiple steps, where each step builds on the last. That difference is why prompt tweaking stalls out in production.

The seven components of agent context

When designing production agent systems, break context into seven components. Getting any one wrong can cascade.

flowchart TD
T[Trigger: user, agent, schedule, or event] --> A[Context Assembler]
SP[1. Instructions / System Prompt] --> A
LTM[2. Long-Term Memory] --> A
ST[3. State / Short-Term History] --> A
RAG[4. Retrieved Information] --> A
P[5. Prompt / Input] --> A
TL[6. Available Tools] --> A
A --> LLM[LLM reasoning]
LLM --> SO[7. Structured Output]
SO --> D1[Payment system]
SO --> D2[Audit log]
SO --> D3[Human reviewer]
SO -. updates .-> ST
SO -. updates .-> LTM

1. Instructions / system prompt

Your system prompt is a contract, not a vibe. In production it specifies role, boundaries, decision criteria, and escalation rules.

For the claims agent, that means the exact auto-approval thresholds, a mandatory fraud check before any payout above $50K, and escalation rules for edge cases. "Process claims accurately" is a demo prompt. Treat the real one as a versioned spec and review changes to it like code.

2. Long-term memory

This is where most enterprise agents quietly break. Agents need persistence across sessions: structured memory about entities, relationships, and past decisions, not just chat history.

A telecom example: a customer calls about a billing issue. With no long-term memory, the agent offers a standard $50 credit. With it, the context shows a $456K-a-year account with a history of escalations, and the right response is an executive-level retention intervention. The model is identical in both cases. The decision is not.

3. State / history (short-term memory)

In a multi-agent workflow, agents need to know what the other agents already did. Take a three-agent claims pipeline. Without state passing, agent 3 either redoes the work of agents 1 and 2 or decides without their findings. This is the amnesia problem.

State requirements also grow with autonomy. A routing agent passes classification metadata. A copilot passes draft responses. A resolution agent passes full execution context. If your state management doesn't evolve as you raise an agent's autonomy, context breaks.

4. Retrieved information (RAG)

RAG is table stakes. What matters is retrieval quality and volume discipline. Ask a financial-advisor agent "Can this client invest in private equity funds?" A bad pipeline dumps five loosely related compliance documents, around 8,000 tokens of legal text, into context, and the agent invents a policy interpretation. A good pipeline retrieves narrowly, ranks, trims, and attaches provenance.

Also treat retrieval as an attack surface. Every retrieved document is a potential injection vector. A poisoned document with hidden instructions gets processed as legitimate context (cross-domain prompt injection, XPIA).

# Sketch: sanitize and isolate retrieved content before assembly
def assemble_retrieved(docs, max_tokens=2000):
safe =
[] for d in rank(docs): # relevance-ranked
text = strip_instructions(d.text) # drop imperative/injected directives
safe.append(f"<doc id='{d.id}' source='{d.source}' trust='{d.trust}'>\n{text}\n</doc>")
return truncate("\n".join(safe), max_tokens)

Wrapping retrieved text in clearly delimited, labeled blocks and telling the model that content inside them is data, never instructions removes much of the attack surface.

5. Prompt / input

The trigger that starts the work. In enterprise systems the "user" is often another agent, a scheduled job, or an event from an external system, not a human typing. Design the input contract for those callers, not just for chat.

6. Available tools

Tools define what the agent can do, not just what it knows. Tool definitions in the context window tell the model which actions exist, which parameters they need, and what outputs to expect. This is where MCP matters: it makes tools discoverable and invokable consistently across services. An agent that knows it has a fraud-detection API, a claims database, and a document-verification service can plan around them. Keep definitions clean and deterministic, since sloppy tool descriptions are context noise.

7. Structured output

Downstream systems shouldn't parse prose. When the claims agent finishes, it should emit something like:

{
"decision": "flag_for_review",
"claim_id": "CLM-88213",
"risk_score": 0.87,
"reasoning": [
"Fraud API returned risk 0.87 (threshold 0.60)",
"Claimant has 3 prior claims in 14 months",
"Payout exceeds $50K: mandatory human review"
],
"audit": { "model": "<model-id>", "tools_used": ["fraud_check", "claims_db"] }
}

This output feeds the payment system, notification service, and audit log without human interpretation. The reasoning array gives you an auditable trail. The audit block tells compliance exactly which model and tools produced the decision. Combine it with low temperature, strict schemas, and validation gates. You aren't chasing identical text, you're designing for deterministic outcomes from non-deterministic components.

Walking one decision through the stack

At each step, the decision depends entirely on what's in the window:

1. Trigger. A customer files a claim. The orchestrator loads the system prompt, the claimant's history from long-term memory, the claim document via RAG, and the tool list (fraud check, payout system, escalation queue).
2. Reasoning. The claims agent calls the fraud tool, gets a risk score, and adds it to working context. It retrieves similar past claims and checks policy limits.
3. Decision. Approve (structured output to payments), flag (handoff with a full context summary), or deny (structured output with reasoning). Miss the fraud score, and you get a bad decision. Lose state between steps, and you get repeated or contradictory actions. Retrieve the wrong documents, and you get a hallucinated policy.

Why context is the root cause behind your other problems

The strongest claim in the source material is that reliability, security, cost, and platform fragmentation all trace back to context.

• Reliability. Non-determinism forces you to lock inputs (version prompts, system messages, retrieval sources), constrain outputs (schemas), and keep tool definitions stable. Every one of those is a context decision. Loose context means unstable behavior.
• Security. The "lethal trifecta" is access to private data, exposure to untrusted tokens, and an exfiltration path. A fake-invoice attack works because untrusted content entered the window unsanitized. That's a context-pipeline problem, not a model problem.
• Cost. A projected 10x ROI that landed at 2x wasn't a math error. It was a context cost miss. Bloated context inflates tokens per call, poor retrieval burns tokens on irrelevant documents, and missing memory forces repeated reasoning.
• Platform fragmentation. In the example, six pilots across four vendors had separate identity models, data contracts, retrieval patterns, and memory stores. No agent could assemble unified organizational context. The tooling wasn't the problem. Context couldn't flow. Context is the control plane of an agentic system. Engineer it deliberately or pay for it later.

A pre-ship checklist

Before an agent goes to production, answer these for each of the seven components:

Key Takeaways

• The model is rarely the failure point. A smart model with incomplete, stale, or unreachable context makes confident bad decisions.
• Treat context as an assembled artifact with seven components: system prompt, long-term memory, state, retrieved information, prompt, tools, and structured output.
• Long-term memory and state passing are where enterprise multi-agent systems most often break, so audit them first.
• Retrieval is both a quality lever and an attack surface. Sanitize, delimit, and budget what you inject.
• Reliability, security, cost, and platform fragmentation share one root cause. Fixing context fixes several problems at once. ## Closing question

If you audited your production agents today, which of the seven components would you find missing or hand-waved, and would you have caught it before the first costly decision?#ai #llm #agents #architecture #software #coding #development #engineering #inclusive #community
The Seven Components of Agent Context: A Production Checklist for Context Assembly