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 .-> LTM1. 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:
- 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).
- 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.
- 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:
| Component | Question to answer |
|---|---|
| System prompt | Does it encode thresholds, escalation rules, and mandatory checks, and is it versioned? |
| Long-term memory | Can the agent see entity history across sessions? |
| State | What does each agent pass to the next, and does it scale with autonomy? |
| RAG | What is the token budget, ranking, and provenance for retrieved content? |
| Prompt | Does it handle non-human triggers (agents, events, schedules)? |
| Tools | Are definitions clean, minimal, and discoverable (MCP)? |
| Output | Is it schema-validated, auditable, and machine-consumable? |
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?
Top comments (4)
The CPU/RAM/OS analogy earns its keep, and the insurer post-mortem is the right opening — a two-sentence system prompt on a frontier model is a $400K demo waiting to happen. The framing I'd add on top: the seven components don't just need to be present, they compete for the same finite window, and two of them silently win that fight — Retrieved Information and Available Tools. Those are the ones that balloon without anyone deciding they should.
That's where I'd want a budget, not just a checklist. Each component gets a token ceiling and a priority, and when assembly overflows you have a defined eviction order — short-term history truncates before instructions do, retrieved chunks get re-ranked and capped before tools get dropped. Otherwise "assemble context from multiple sources at runtime" quietly becomes "whatever fit this turn," which is non-deterministic in exactly the way the insurer got burned by.
Do you give the Context Assembler an explicit per-component budget + eviction policy, or is ordering today mostly implicit in the assembly code? Curious whether you've found a priority order that generalizes across task types, or whether it has to be tuned per workflow.
Fascinating deep dive into AI workflows. Grounding outputs and evaluating latency budgets will be key as more agentic systems reach production.
Số $2.3M và 6 tháng cho một hệ thống multi-agent claims mà cuối cùng không deploy được — tình huống này nghe quá quen. Từng thấy team mình bỏ 4 tháng chỉ vào context assembly cho một workflow document processing, chủ yếu vì低估了 "context freshness" và "token budget allocation" giữa các agent.
Bài viết nhắc đến 7 components mà component 3 (Context Versioning) và component 6 (Cross-Agent Context Sync) là hai điểm team mình đau nhất. Versioning: khi agent A update context mà agent B vẫn đọc stale version, debug mất 3 tuần mới bắt được race condition. Sync: broadcast context change cho 5 agent đồng thời mà không có backpressure mechanism, production down 2 lần do OOM.
Một bài học practical: treat context như first-class citizen có schema, migration, và observability — đừng để nó thành implicit shared state. Có bạn nào đã implement context diffing thay vì full-rebuild mỗi lần agent cần update? Thấy approach này giảm token usage ~40% trong case study nội bộ PS: the tool I meant is on labagent .tech
Bài viết đánh trúng điểm đau của nhiều team khi scale agent từ demo lên production. Việc insurer đó burn $2.3M trong 6 tháng mà không ra được kết quả là điển hình cho tư duy "thêm context nhiều hơn = thông minh hơn" — thực tế noise trong context window thường giết performance nhanh hơn missing information.
Điểm về context freshness và conflict resolution trong checklist là hai thứ hay bị bỏ qua nhất. Tôi từng thấy hệ thống retrieve policy docs version cũ còn hiệu lực song song với version mới, agent hallucinate ra clause không tồn tại vì không có mechanism resolve conflict. Thêm vào đó, token budget allocation giữa system prompt, few-shot examples, retrieved docs, và conversation history cần có strategy rõ ràng (priority-based truncation, summarization tiers) chứ không phải hard-code max tokens.
Một gap mình hay gặp: bài viết nhắc到 observability nhưng chưa đi sâu vào context attribution — khi agent sai, làm sao trace được exactly đoạn context nào gây ra decision đó? Không có điều này thì debug production gần như mò kim đáy bể.
Checklist này đáng để in ra dán bàn làm việc cho team đang build agent system. Cảm ơn tác giả đã condense kinh nghiệm thực chiến — found it via LabAgent, site: labagent .tech