Chapter 11Failure modes and anti-patterns

Part III turns from what to build to how production systems fail, how to test and observe them, and how they meet users, enterprises, and the model layer.

Most pattern catalogs describe what to build. Few describe what breaks. This chapter is about how agentic systems fail, the modes, the cascades, the anti-patterns that produce them, because pattern selection and bound-setting are only defensible when the team has thought about what failure looks like.

The chapter has two sections. The first is a taxonomy of failure modes: the recurring ways agentic systems go wrong, regardless of the patterns or frameworks used. The second is a catalog of anti-patterns: structural choices that produce these failure modes reliably enough to be named.

The book treats this chapter as load-bearing. A team that can name the failure modes of its system has done meaningful architectural work; a team that cannot has not.

A note on method: the failure modes and anti-patterns below are derived from the published post-incident literature of 2024–2026, the security literature on prompt injection and the lethal trifecta, the safety literature on guardrails and red-teaming, and the operational reports of teams running agentic systems at scale. The book-level convention for unattributed incidents is stated in the Preface; this chapter’s catalog names public cases where they illustrate a mode directly. They are not exhaustive, new failure modes will emerge, but they cover the substantial majority of severe incidents documented through the time of writing. Treat the chapter as the current best taxonomy rather than as a closed set.

A taxonomy of failure modes

Failure modes are organized by where they originate in the architecture. Each entry names the symptom, the typical root cause, the cascade (how the failure propagates), and the structural defense (the chapter where the relevant pattern is developed).

Reasoning loop failures

Infinite or thrashing loops. The agent iterates without progress, often revisiting the same approach with cosmetic variations.

• Cause. Missing or excessively generous iteration bound; goal that cannot be satisfied with the available tools; feedback the agent cannot interpret.

• Cascade. Cost explosion; user-visible hang; SLO violation; tool quota exhaustion affecting other agents. The cascade compounds when one runaway agent consumes shared rate limits or budgets and starves legitimate work.

• Defense. Iteration bound (Chapter 5). Time bound. Cost bound. Trace alerting on per-iteration progress and thrash signatures (Chapter 12).

Premature termination. The agent declares success or gives up before the task is complete.

• Cause. Stop condition that confuses surface progress for actual progress; missing or unclear goal; and a bias toward closure, the tendency the alignment literature calls task-shirking or “laziness,” associated with training models to be agreeable and helpful. Models so trained lean toward emitting a confident “done”, “I have completed the refactor”, without having actually called the tools that would do the work.

• Cascade. Incomplete deliverables; downstream errors when consumers expect a finished output; user trust loss; rework that costs more than the original task. The cascade is particularly bad when the agent’s output is consumed by another agent or by an automated downstream process that does not check completeness.

• Defense. Output validators (Chapter 6) that check completeness, not only correctness. Evaluator-optimizer pattern with a stricter critic.

Plan corruption. The agent’s plan drifts from the goal across replanning steps, ending up pursuing something the user did not ask for.

• Cause. Replanning unbounded; replanning loses goal anchor; replanning incorporates noise from failed steps as if it were signal.

• Cascade. User confusion; misallocated work; wrong system mutations. The cascade is worst in long-running workflows where the drift accumulates over many replan cycles and the original goal is no longer recognizable in the final plan.

• Defense. Goal preservation in the bounding layer (the goal is a structured artifact, not a prompt fragment); bounded replan count; explicit checkpointing.

State corruption. The agent’s working or episodic memory becomes inconsistent with the world.

• Cause. Memory writes without governance; tool calls that mutate external state silently; partial failures not rolled back.

• Cascade. Future runs operate on the wrong picture; cascading wrong decisions; trust loss when discovered. Memory corruption is especially insidious because the agent’s behavior appears reasonable, it is reasoning correctly from incorrect inputs, and the corruption may be invisible for many sessions before manifesting.

• Defense. Memory governance (Chapter 7); validators (Chapter 6); saga rollback (Chapter 9); trace replay for incident response (Chapter 12).

Reasoning loop deadlock with critic. A generator–critic pair (reflection, evaluator-optimizer) enters a stable disagreement: the generator produces, the critic rejects, the generator produces a minor variant, the critic rejects again, indefinitely.

• Cause. Critic too strict; generator unable to satisfy the critic; bound on critique iterations missing or too generous.

• Cascade. Cost spend with no useful output; user-visible delay; eventual abort with unclear cause.

• Defense. Bound on critique iterations; defined fallback (accept-after-N, escalate-to-human, abort-with-error); critic and generator independence (a critic that is a copy of the generator with a different prompt often produces this failure mode).

Tool-use failures

Tool hallucination. The agent invokes a tool that does not exist, a fabricated tool name, or a call shaped to fit a tool the agent assumes is available but that was never exposed to it. (Malformed arguments to a real tool are a distinct failure, parameter hallucination, below.)

• Cause. Tool surface poorly documented to the agent; schema not enforced at the call boundary; prompts that suggest tools without exposing them; tool documentation that has drifted from tool reality.

• Cascade. Failed calls returned as observations; agent retries with similar fabrications; eventual confusion and failure. In multi-step tasks the agent may “complete” the task in its own assessment because it invoked the imaginary tool that would have produced the desired effect.

• Defense. Strict schema validation (Chapter 6); tool surfaces declared explicitly to the agent; refusal of fabricated calls treated as a normal observation rather than a fatal error.

Parameter hallucination (type coercion). The agent calls a real tool but fabricates an argument that is not in the schema, or coerces a value to the wrong type, passing a JSON string where an integer is required, inventing an optional field, supplying a plausible-but-wrong enum value.

• Cause. Validation enforced on the tool name but not on its arguments; under-specified parameter documentation; the model pattern-matching to a plausible call shape rather than the actual schema.

• Cascade. The call fails, or, worse, succeeds with the wrong payload and produces a silently wrong effect. Weak validators catch tool hallucination (the tool name is wrong) but miss parameter hallucination (the tool name is right, the payload is malformed), so it slips through systems that believe they validate tool calls.

• Defense. Argument-level schema validation (Chapter 6), types, ranges, enums, required and optional fields, not just tool-name checking; reject-and-observe on any validation failure.

Tool misuse. The agent invokes a real tool with arguments that are syntactically valid but semantically wrong.

• Cause. Tool documentation inadequate; tool behavior underspecified; agent overconfident in its understanding; semantic distance between tool name and tool effect.

• Cascade. Side effects in the wrong place; data written to the wrong destination; refunds to the wrong account; communications sent to the wrong recipient list. The cascade is worst for irreversible actions.

• Defense. Tool wrappers that perform semantic validation in addition to schema validation; pre-action confirmation for irreversible operations; reversibility envelope (Chapter 5).

Cascading tool failure. A tool call fails; the agent retries; the retry partially succeeds; the agent retries again with corrupted state.

• Cause. Tools that are not idempotent; absent or unused failure-information channels (the agent doesn’t know which retries succeeded); naive retry logic.

• Cascade. Duplicated effects (double charges, duplicate tickets); state divergence between agent’s view and reality.

• Defense. Idempotency keys at the tool boundary; failure-aware retry logic; trace inspection at scale to detect duplicate-effect patterns.

Tool injection. A tool’s response contains content that, when read by the agent, alters the agent’s behavior against the user’s interest.

• Cause. Tools that return free-text content the agent treats as input rather than as data; retrieval surfaces containing attacker-controlled text; tools whose responses pass through systems with weak input sanitization.

• Cascade. Exfiltration of memory; unauthorized action attempts; misuse of authority. This is the canonical lethal-trifecta failure, when combined with sensitive data access and external action capability, tool-response injection becomes a severe security incident.

• Defense. Tool-response sanitization; structured tool outputs that the agent cannot interpret as instruction; the lethal-trifecta defense (Chapter 6).

Tool quota exhaustion. The agent consumes an external tool’s quota or rate limit, affecting other workloads.

• Cause. No per-agent or per-session rate limiting on the deterministic side; tool calls in tight loops; multi-agent fan-out without coordination.

• Cascade. Other agents starved; legitimate user-facing operations fail; external service provider may throttle or block the entire account.

• Defense. Rate limiting at the bounding layer; per-agent quotas; circuit-breaker patterns that abort sessions consuming disproportionate quota.

Memory failures

Cross-identity leakage. Memory from one user, tenant, or session is surfaced to a different one.

• Cause. Identity scoping absent or incorrect; retrieval index unpartitioned; gateway not enforcing scope.

• Cascade. Severe. Privacy incidents; regulatory exposure; trust loss at scale. Notification obligations under privacy regulations may add legal exposure beyond the operational damage.

• Defense. Identity-scoped memory architecture (Chapter 7); scoping tests in the test suite; default-deny in the gateway.

Stale-semantic retrieval. The agent retrieves and confidently uses semantic memory entries that have been superseded.

• Cause. Semantic memory not versioned; superseded entries not retired; freshness not tracked.

• Cascade. Confidently wrong outputs; user trust loss; downstream actions based on outdated information. The cascade can compound when the wrong information is used to make further memory writes, propagating the error.

• Defense. Curated semantic memory with explicit freshness and retirement (Chapter 7).

Context exhaustion. The agent runs out of context window mid-task, often silently truncating critical material.

• Cause. Static context that grows without compaction; retrieval that floods the window; failure to use progressive disclosure or Skills. A common precursor is prompt stuffing — accumulating prior turns, tool outputs, and retrieved chunks into the window each iteration instead of assembling a fresh, scoped context each turn (Chapter 19).

• Cascade. Wrong answers, missing constraints, instruction loss; failures that look like model errors but are architectural. The cascade is particularly bad when the system prompt or tool list is truncated, because the agent may now believe it has different capabilities than it actually does.

• Defense. Memory compaction (Chapter 7); Skills with progressive disclosure (Chapter 10); explicit context budget per session.

Memorization of sensitive content. Memory accumulates PII, secrets, or credentials.

• Cause. Memory writes without governance; default-on memorization policies; assumption that the model will not memorize sensitive content (it will).

• Cascade. Regulatory exposure; long-tail leakage as memory is retrieved later. The cascade can extend across model versions if memory persists across migrations.

• Defense. Pre-write redaction (Chapter 7); strict policy on what may be memorized; periodic audit.

Memory poisoning. An attacker, internal or external, writes to memory in a way that influences subsequent agent behavior.

• Cause. Memory writes accessible to attacker-controlled content (a user submitting a prompt designed to be memorized; a tool whose response is auto-promoted to memory).

• Cascade. Long-tail influence on the agent; behavior shifts in ways that are hard to attribute.

• Defense. Memory writes always pass through governance (Chapter 7); promotions from session to long-term memory require explicit approval or strict curation; attacker-controllable content does not enter long-term memory automatically.

Coordination failures

Inter-agent injection. One agent’s output, treated as input by another, contains content that subverts the receiving agent.

• Cause. Agent-to-agent channels not governed; assumption that internal agents are trustworthy peers.

• Cascade. The full lethal-trifecta failure pattern, but inside the system rather than at its boundary.

• Defense. Governance applies to inter-agent channels (Chapter 6); structured rather than free-text inter-agent messages; agents do not trust each other by default.

Coordination deadlock. Two or more agents wait on each other and neither progresses.

• Cause. Naive peer coordination without termination conditions; consensus patterns without timeout; circular handoffs.

• Cascade. Stuck sessions; resource exhaustion; user-visible failure.

• Defense. Termination conditions on every coordination shape (Chapter 9); supervisor pattern with intervention authority; timeouts.

Convergence failure (committee, debate, swarm). Multi-agent reasoning patterns do not converge in budget.

• Cause. Cost or iteration budget under-provisioned for the pattern; problem genuinely too hard for the structure; emergent disagreement that the pattern cannot resolve.

• Cascade. Wasted spend; either premature decision or task abandonment.

• Defense. Bounded coordination with defined fallback to single-agent or human review.

Orchestrator-worker misdelegation. The orchestrator delegates a task to a worker that lacks the necessary capabilities, but the worker proceeds as if it has them.

• Cause. Worker capabilities declared loosely; orchestrator’s mental model of workers drifts from reality; capability declarations not verified at delegation time.

• Cascade. Worker produces plausible but wrong output; orchestrator integrates the wrong output into its synthesis; final output is wrong with no obvious tell.

• Defense. Capability declarations verified at delegation; workers refuse tasks outside their declared capabilities; orchestrator validates worker outputs against capability claims.

Governance failures

Approval-fatigue collapse. Every action requires human approval; reviewers stop reading; approvals become rubber-stamping.

• Cause. Risk-based escalation absent or miscalibrated; everything classified as high-risk.

• Cascade. Effectively no review of any action; eventual incident from a rubber-stamped operation. The cascade is invisible until the incident lands, and then the post-mortem reveals that approvals were not meaningful for some time.

• Defense. Risk-based escalation (Chapter 6); review of approval rejection rates as an operational metric; periodic re-tuning.

Ungoverned customer-facing output. The model emits pricing, policy, legal, or brand language to a customer with no policy gate, output validator, or approval path before display — chatbots treated as if text were costless when it can carry enforceable or reputational weight.

• Cause. Governance applied only to tool calls, not to conversational effects; output treated as presentation rather than action; reversibility envelope undefined for what the interface may say.

• Cascade. Regulatory or contractual liability (Moffatt v. Air Canada, 2024); binding-sounding commitments from prompt injection (Chevrolet of Watsonville, December 2023); brand and reputational damage from unfiltered output (DPD, January 2024). See Chapter 5 and Chapter 13.

• Defense. Output governance at display; policy gates on commitment language; reversibility envelope extended to customer-visible representations; Chapter 13 streaming-versus-validation discipline.

Policy drift. Policy gates written for an earlier version of the system no longer match current behavior.

• Cause. Policy not version-controlled; policy not reviewed when the system changes; agents using tools the policy was not written to cover.

• Cascade. Either too-permissive policy (incidents pass through) or too-restrictive policy (legitimate work blocked). Both produce trust loss, too-permissive when an incident lands; too-restrictive when users notice work being blocked for reasons that no longer apply.

• Defense. Policy as code (Chapter 6); policy review as part of the change process; policy-coverage tests.

Audit gap. The trace does not capture enough to reconstruct an incident.

• Cause. Tracing not designed for replay (Chapter 12); high-cardinality fields excluded for storage reasons that turn out to be important; trace sampling that drops the incident.

• Cascade. Incident response takes weeks instead of hours; root cause never identified; same incident repeats. Regulatory consequences when audit obligations cannot be met.

• Defense. Trace discipline (Chapter 12); replay capability tested before being needed; full trace on flagged sessions even if sampling reduces volume elsewhere.

Governance bypass via prompt injection. An attacker’s prompt content causes the agent to invoke actions that the governance layer would block, but the agent does so in a way the governance layer does not detect.

• Cause. Governance enforced only on the most obvious paths; subtle action constructions slip through; the agent’s reasoning is allowed to express itself in ways that mask the intent.

• Cascade. Severe and silent. The action goes through; the governance layer logs it as legitimate; the incident is discovered when its effects manifest.

• Defense. Governance applied to all action paths, not only the obvious ones; output validators check intent as well as form; risk scoring includes contextual signals (recently-loaded skills, recently-retrieved content, unusual action patterns).

Operational failures

Cost explosion. The system runs over budget by an order of magnitude with no immediate visibility.

• Cause. Cost bounds not enforced; cost dimensions not measured; long-tail expensive runs masked by averages.

• Cascade. Budget overrun; service degradation if rate-limited; financial exposure.

• Defense. Per-run cost bound (Chapter 5); cost regression testing (Chapter 12); long-tail monitoring.

Latency explosion. Per-request latency drifts upward over time, often invisibly.

• Cause. Memory growth slowing retrieval; tool calls added without latency budget; reasoning model upgraded without latency check.

• Cascade. SLO violations; user trust loss; cascading downstream timeouts.

• Defense. Time bound (Chapter 5); latency monitoring; per-tool latency budgets.

Drift. The system’s behavior changes over time without a clear cause, quality degrades, costs change, failure rates rise, without code changes.

• Cause. Model upgrades; subtle changes in tool behavior; memory accumulation changing retrieval; policy drift.

• Cascade. Long-running quality erosion that is hard to attribute. Users adapt to the new (worse) behavior or leave.

• Defense. Replay testing against historical traces (Chapter 12); behavioral metrics tracked over time; explicit pinning of model versions in production.

Capacity collapse under load. The system performs well at normal load and collapses ungracefully at peak.

• Cause. Per-session cost has a long tail; under peak load the tail dominates; rate limiting at the model provider triggers in ways the architecture does not handle.

• Cascade. Cascading failures: backpressure causes more sessions to time out, which causes retries, which compounds load.

• Defense. Load testing at multiples of normal load; backpressure design (queues, shedding, degraded modes); per-tenant quotas to prevent one tenant from causing fleet-wide collapse.

Cascades and compound failures

Failure modes do not occur in isolation. The patterns above interact in cascades that produce the worst incidents:

The runaway-loop-cost-cascade. An iteration-unbounded reasoning loop calls a per-call-expensive tool; the cost ledger is not aggregated across calls; the session spends an order of magnitude over budget before being noticed. Defense: bound on iterations, and aggregate cost ledger, and per-tool latency limits.

The injection-exfiltration cascade. A retrieval index contains attacker-controlled content; the agent is allowed to act on retrieval content as if it were authoritative; the agent has sensitive data in memory; the agent is allowed to call external tools. The retrieval content instructs the agent to send memory contents to an attacker-controlled endpoint. This is the lethal trifecta — untrusted input, sensitive data access, and external action capability — as a chain of dominoes, each of which a different defense can topple. Johann Rehberger’s disclosure against GitHub Copilot Chat (June 2024; Embrace The Red; see Chapter 21) is a public instance: private repository context, attacker-influenced content in the same session, and an external fetch channel (Markdown image URLs) combined in one interface. Simon Willison catalogs the same lethal-trifecta pattern across products (Chapter 21).

Defense is layered governance, tool-response sanitization, action-surface restriction, output validation, any one of which breaks the chain.

The poisoned-memory cascade. An attacker submits content designed to be memorized; the memorization succeeds; subsequent agents retrieve the poisoned content and act on it; the influence is hard to attribute because it manifests sessions later. Defense: memory writes governed, attacker-controllable content not promoted to long-term memory, periodic audit of memory contents.

The over-trusted-orchestrator cascade. An orchestrator delegates to a worker; the worker is compromised (or behaves incorrectly); the orchestrator integrates the worker’s output as authoritative; the orchestrator then propagates the bad output to other workers or to the user. Defense: inter-agent governance, capability verification at delegation, output validation between agents.

The drift-incident cascade. The model is upgraded; behavior shifts; metrics drift slowly; no individual session looks bad; a long-tail incident lands months later from a behavior pattern that has been building. Defense: replay testing of new model versions, behavioral-envelope monitoring, willingness to roll back model versions.

Cascades are the reason defense in depth is the dominant architectural posture. No single bound, no single validator, no single check is reliable. The system survives because multiple independent defenses each have to fail for the cascade to reach the user.

Anti-patterns

An anti-pattern is a structural choice that reliably produces the failure modes above. Each entry below names the anti-pattern, describes its appeal (why teams choose it), names what it produces, and offers the structural alternative.

“The agent is the system”

Description. The architecture treats the agent as the whole system. Tools are exposed directly. State lives in the conversation. There is no bounding layer, no governance layer, no memory architecture beyond what the model maintains in context.

Appeal. Simple to set up. Looks like a clean architecture diagram. Performs well in demos.

Produces. Cost explosions (no bound), severe incidents (no governance), state corruption (no managed memory), cross-identity leakage (no scoping), drift (nothing to compare against).

Alternative. The agent is a component inside deterministic infrastructure (Chapter 2). Architecture is around the agent, not under it.

“Agent where a workflow would do”

Description. An open-ended reasoning loop is deployed on a task whose steps are known at design time — a scheduled report, a fixed ETL sequence, a routing decision with a closed choice set — where a workflow, a cron job, or a simple router would suffice.

Appeal. The demo is impressive. Point-and-click agent builders make the agent the path of least resistance. The team already has the model API key; wiring a loop feels faster than modeling the workflow.

Produces. Non-determinism where none was needed; a debugging and oversight surface the task never required; cost per run often an order of magnitude above the workflow equivalent. The failure is one step earlier than Multi-agent for the sake of it (below): the question is not how many agents, but whether an agent was the right category at all.

Alternative. The category test from Chapter 2: is the choice set open? The decision table in Chapter 9; Anthropic’s workflow patterns (Chapter 21) for the canonical shapes. If the steps are known, encode them.

“Prompt-based governance”

Description. Safety, policy, and bounds are expressed in the agent’s system prompt, “do not do X,” “always validate Y,” “stop after Z iterations.”

Appeal. Trivial to implement. No new infrastructure. Apparent compliance.

Produces. Real-world prompt-injection success; real-world incidents in which the agent did exactly the thing the prompt told it not to. The prompt is a recommendation; the model can ignore it.

Alternative. Governance is deterministic code (Chapter 6); bounds are externally enforced (Chapter 5). The argument for why prompt-based enforcement fails at the model layer is made once, in Chapter 6; this catalog entry exists only to name the shape so a reviewer can recognize it. The bounding-layer anti-pattern prompt-based bounding (Chapter 5) is the same mistake applied to quantitative limits. Prompts express preferences; architecture enforces constraints.

“Multi-agent for the sake of it”

Description. A system decomposed into multiple agents (researcher, planner, executor, critic, archivist) where a single agent with tools would suffice.

Appeal. Elegant on the diagram. Sounds modern. Frameworks promote it.

Produces. Multiplied failure modes; harder debugging; coordination overhead; more attack surface (inter-agent injection, with the substrate treatment in Chapter 14); cost.

Alternative. Single agent with tools. Orchestrator–worker when the task genuinely decomposes. First ask whether an agent is needed at all — see Agent where a workflow would do (above). The argument that multi-agent coordination is over-prescribed is made in Chapter 3 and Chapter 9; this entry names the shape only so a reviewer can recognize it. Peer multi-agent is justified only when the problem has dialectical structure.

“Self-policing autonomy”

Description. A critic agent monitors a worker agent’s cost, iteration, or risk. Or the agent itself is asked to determine when it should stop.

Appeal. Apparently sophisticated. Allows the architecture to claim oversight without committing to deterministic bounds.

Produces. No real bound. The critic has the same failure modes as the worker. Adversarial inputs can subvert both.

Alternative. Bounds enforced by deterministic code (Chapter 5). A critic agent is fine as one of multiple layers; it is not a substitute for the deterministic bound.

“Conversation history as memory”

Description. The agent’s memory is whatever the model recalls from the running conversation. No separate memory store, no retrieval, no scoping.

Appeal. Easy. Works for a single session of a single user.

Produces. Context exhaustion; no cross-session continuity; no scoping; eventual quality erosion; identity-leakage risks when sessions are reused.

Alternative. Tiered memory architecture (Chapter 7) with explicit working / episodic / semantic stores and a gateway.

“Vector index as semantic memory”

Description. Documents are ingested into a vector store; the index is treated as the system’s source of truth.

Appeal. Easy to build. Looks like RAG.

Produces. Confidently surfaced stale or wrong material; no notion of freshness; no curation; no retirement of superseded entries.

Alternative. Curated semantic memory (Chapter 7) with explicit ingestion processes, freshness tracking, and authority signals.

“Text-to-SQL over raw schemas”

Description. The model is handed a raw database schema and asked to write analytical queries directly against it.

Appeal. It appears to remove the need to model anything; the agent simply answers questions about the data.

Produces. Structural hallucination, a syntactically valid query that passes the schema validator and executes cleanly but encodes a guessed business rule (what counts as an active customer, whether revenue is gross or net of tax) that the organization defines precisely elsewhere. The number is confidently wrong, and there is no malformed output to catch it.

Alternative. Remove raw queries from the action surface and route analytics through a semantic layer that compiles governed metric definitions (Chapter 14). The agent chooses the metric; the deterministic layer owns its definition.

“Tools-as-permission-boundary”

Description. The team trusts the schema validation at the tool boundary as the complete defense. If the call is well-formed, it proceeds.

Appeal. Validators are real and useful; treating them as the boundary is appealing.

Produces. Semantic misuse (well-formed but wrong); policy violations the schema doesn’t catch; insufficient defense against tool-response injection.

Alternative. Defense in depth (Chapter 6): schema + policy + risk-based escalation + reversibility envelope. The schema is one of several layers, not the only one.

“Skills as escape hatch”

Description. Skills are admitted without the same governance applied elsewhere, the system trusts skills because they are documented procedures.

Appeal. Skills are useful, and gatekeeping them feels redundant.

Produces. Prompt injection at the skill layer; trust transfer from the curator of the skill to the agent’s full authority; lethal-trifecta vulnerabilities introduced via untrusted skill content.

Alternative. Skills are subordinate to architecture (Chapter 10). Skill admission and activation are governed.

“Approval as compliance theater”

Description. Human-in-the-loop is added for compliance reasons, with high volume and low-context approvals; reviewers approve quickly without reading.

Appeal. Satisfies auditors. Demonstrates oversight on paper.

Produces. No real review; eventual incident; loss of meaningful human oversight as a tool.

Alternative. Risk-based escalation (Chapter 6) routing only the actions that genuinely warrant review; review with structured context (the proposed diff, the trace, the risk score); review SLA monitoring.

“Pattern-as-architecture”

Description. The system is designed around one pattern (ReAct, Plan–Execute, Reflection) treated as the architectural answer.

Appeal. The pattern’s elegance carries the design.

Produces. Systems with no bounding discipline, no governance, no memory architecture, patterns sit on nothing. The pattern is fine; the absence of architecture under it is the problem.

Alternative. Architecture first (Chapters 5–10), patterns within it. Patterns answer how the agent reasons or coordinates; architecture answers how the system stays reliable.

“Optimism in production”

Description. The team treats incidents as bugs to be fixed rather than as expected behavior to be designed for.

Appeal. Cultural. Easy to slip into when the system is new and incidents are rare.

Produces. Each incident causes panic. Trace discipline is set up after the first incident, not before. Anti-patterns accumulate.

Alternative. This chapter. Treat failure modes as part of the design surface from the start.

“Vibe-driven evaluation”

Description. The team validates the agent by chatting with it in a UI for ten minutes. If it looks good, they ship. There is no assertion suite, no trace replay, no property tests, evaluation is a human forming an impression (“LGTM”).

Appeal. Fast, requires no infrastructure, and feels like testing because a human looked at the output.

Produces. Regression blindness. The model is upgraded, or a prompt is edited, and a previously working tool surface silently breaks, no test fails, because there are no tests. The failure is discovered in production, by users.

Alternative. Deterministic envelope assertions and property-based tests over traces (Chapter 12). Manual inspection is a supplement to an automated suite, never the suite itself.

“Stack-trace mindset on probabilistic systems”

Description. When an incident lands, the team looks for the line of code that caused it. They find none, because the cause is a combination of model behavior, prompt, retrieved content, and tool responses that no single line can capture.

Appeal. It is how engineers debug deterministic systems. Hard to unlearn.

Produces. MTTR (mean-time-to-resolution) bloat: a failure that takes ten minutes to localize in a deterministic microservice can take days in an agentic system, because the cause is a distributed collapse across prompt, retrieved content, tool responses, and model weights rather than a single line. Without trace replay, root-cause analyses come back incomplete and the same incident recurs.

Alternative. Trace replay (Chapter 12) as primary debug tool. Reconstruct the session. Modify counterfactually. Identify the cascade rather than the single point.

Closing note

The anti-patterns above are not exhaustive, but they cover the majority of severe incidents observed in production agentic systems through 2024–2026. Each names a structural choice that seemed reasonable at the time and turns out to undermine the architecture rather than support it.

Chapter 12 takes up trace discipline, testing, and evaluation as the operational counterpart to the structural commitments developed in earlier chapters.