Chapter 11 · The Failure Catalog, and Build vs. Buy for Engineers

Agent programs rarely fail in general. They fail in specific, repeatable ways. Here are twelve, each with the signal that shows up first and the fix, followed by the build-vs-buy question as engineers actually face it.

11.1 The catalog

Read each row as: if you see the signal, apply the antidote before it becomes an outage. The chapter in parentheses is where the antidote is built.

Failure mode	What it looks like	Early signal	Antidote
1. The infinite investigation	The agent keeps probing, concludes nothing, and runs up cost	Steps and cost per investigation trending up; time to first finding slipping	Step, token, and time budgets; a loop detector; escalate with partial findings when the budget runs out (Ch. 1)
2. Context flood	Quality drops as raw tool output fills the context window	Tokens per step growing; accuracy falling on long incidents	Cap tool result size; compact with pointers back to evidence; re-rank retrieval (Ch. 2, 3)
3. Confidently wrong	A fluent, well-cited conclusion with the wrong mechanism	Claims that don’t trace to evidence; rejections tagged “wrong diagnosis”	Every claim links to its evidence; layered eval scoring; humans grade a sample (Ch. 7)
4. Validation theater	Marked “fixed” because the alert cleared, but the defect is still there	Repeat incidents; a gap between diagnosis and mitigation scores in evals	Verify against system state, not the alert; soak windows; score mitigation separately (Ch. 1, 7)
5. Alert storm becomes cost storm	One incident wave wakes the investigator hundreds of times	Spike in events promoted to investigation; spend jumps at that seam	Correlate and dampen storms before investigation; cap investigations per time window (Ch. 4)
6. Injection incident	The agent follows instructions it found in logs, tickets, or tool output	Injection-pattern detections; new outbound destinations; unusual tool sequences	The full Ch. 5 defense stack; regular red-team runs; track where each memory came from
7. Approval fatigue	People approve without reading; the gate becomes theater	Over 95% approvals with near-zero time spent reviewing. Over 95% with real review time and a long wait is the Chapter 6 signal to graduate the class instead	Graduate that action class, or make the approval request easier to judge; measure the gate (Ch. 6)
8. Memory poisoning	One bad conclusion steers future incidents	Contradiction flags; the same wrong diagnosis recurring for one class	Record provenance; let old memories decay; keep a human-curated tier; review on a schedule (Ch. 2, 9)
9. Tool sprawl	Dozens of thin tools, wrong tool picks, brittle prompts	Rising tool-choice errors; context cost per step climbing	Merge into fewer tools shaped around intent (Ch. 3)
10. Invisible change	Behavior shifts and nothing in the diff explains it	Drift metrics move with no release	Version everything as an artifact; pin versions; gate deploys (Ch. 9)
11. Model-swap regression	A model upgrade quietly breaks a class you had already graduated	Per-class test-set diff; step counts drifting after the swap	Migration playbook; canary lanes; run old and new side by side (Ch. 9)
12. The frozen pilot	Advice-only forever; no evidence to graduate; the renewal dies	Autonomy flat for quarters; no measured MTTR change	Signed graduation criteria; start in a low-risk domain; Appendix A gates

Two lessons from the table.

Every one of these shows up on a dashboard before it shows up in an outage, but only if you built the evaluation and observability from Chapter 7 and Chapter 8. Skipping them doesn’t avoid these failures. You just meet them without instruments.
Use the catalog as an interview script. Ask any vendor which of these twelve they have hit in production and what they shipped in response. In a category this young, real incident history is the credential that counts.

11.2 Build vs. buy, the engineering edition

A capable team can build an operations agent. A weekend with a frontier model, a ReAct loop (reason, act, observe, repeat), and kubectl produces a demo that impresses leadership. The real question is whether you should own the harness around it. Here is what this book specified beyond the demo:

Subsystem	What it includes	Chapter
Agent loop	The loop itself, step and cost budgets, independent verification	1
Context	Discovery, budgets, memory, provenance	2
Tools and skills	Risk metadata, contract tests	3
Orchestration	Typed handoffs, two-engine cost control	4
Injection defense	Sandboxing, egress control, tokenization	5
Policy and execution safety	Policy as code, approvals, a replayable audit record	6
Evaluation	A test set from your incidents, judges, regression gates	7
Observability	Tracing decisions, not just requests	8
Day-2 operations	Versioning, model migrations, memory hygiene	9

The demo is the smallest and most fun part of that list. The rest is heavy lifting that doesn’t differentiate most companies, and it’s exactly where the twelve failure modes live. Use this decision rule:

Build if agent operations is your product, or your constraints are so unusual that no platform’s trust model fits. Staff it as a product team with a roadmap, not a side project.
Buy if your edge lies elsewhere. Spend your engineering on what no vendor can ship for you: your test set, your context curation, your policy design, and your operating discipline.

Either way, hold the same bar. Appendix B scores a vendor and scopes an internal build with the same items, and Appendix A tests whichever path you pick against your own incidents.

In practice: where CloudThinker gives you the controlsIf you evaluate CloudThinker against this catalog, here is the control for each mode, or how to cover it where there isn’t one.

Failure mode	Where to look
1. Infinite investigation	No per-investigation step, token, or time budget you can set. Credit limits (Scale plan and up) cap monthly spend per workspace, and Stop in the chat halts a running reply.
2. Context flood	The Context window meter in the prompt box shows what fills a conversation’s context. A long conversation summarizes its earlier messages instead of growing until it hits the model limit. There’s no result-size cap you set.
3. Confidently wrong	Grade incidents under Was Resolve’s diagnosis right?, and pick Wrong root cause when it was. Resolve → Insights → Accuracy & trust tracks Root-cause accuracy (Resolve Insights).
4 and 12. Proving results	A recorded fix stays Unverified until a follow-up check marks it Verified or Failed (Incident memory). Resolve → Insights → Accuracy & trust shows Root-cause accuracy from your team’s verdicts. The Activity page and Audit Logs (Scale, Scale Plus, and Enterprise plans) show that runs happened, not that fixes worked.
5. Cost storm	Credit limits (Scale plan and up) cap monthly spend per workspace, with throttle or notify-only enforcement.
6. Injection incident	Not one setting. Every write an injected instruction triggers still goes through Rules and the Approval mode, and Guardrails shows agents placeholders instead of sensitive identifiers. See Chapter 5 for the full defense stack.
7. Approval fatigue	Approve and draft rule on an approval card turns a repeated approval into a Rule you review once. Approvals → Activity counts approvals and declines per Rule, but doesn’t show approval latency or review time, so measure those yourself.
8. Memory poisoning	Workspace Admins can open, edit, or delete any memory item. Dreaming run summaries name what each nightly run changed.
9. Tool sprawl	Not a product control. Give each custom agent only the connections it needs (Custom agents).
10 and 11. Invisible change and model swaps	No advance-notice period is published for model changes within a tier. Follow the changelog and its RSS feed, and rerun your golden set after releases. With BYOK, the organization Owner picks the exact model on your own key.

Key takeawayFailures are specific, measurable, and mostly self-inflicted at the harness layer. Whether you build or buy, you own the test set, the policy, the context, and the discipline. Ask anyone who wants to own the rest for real incident history, not slides. For CloudThinker, the changelog lists the fixes shipped in each release.

Next steps

Read Chapter 12 to see how these pillars become standing missions that earn autonomy in order. If you’re evaluating a platform now, take Appendix A into your proof of concept.

Learn

Workshops

Scenarios

Chapter 11 · The Failure Catalog, and Build vs. Buy for Engineers

11.1 The catalog

11.2 Build vs. buy, the engineering edition

Next steps

​11.1 The catalog

​11.2 Build vs. buy, the engineering edition

​Next steps

11.1 The catalog

11.2 Build vs. buy, the engineering edition

Next steps