AnthropicClaude Certified Architect – Professional2026-105.2 Identify risks, limitations, and failure modes of LLM systems
Trace failures across the agent workflow
Completed by the knowledge check
Learning objective
Identify agentic and operational failure modes: compounding errors, runaway loops, unintended side effects, dependency outages, drift, stale retrieval, and cascading multi-agent failures.
Core idea
For the architect operating an agent workflow, the unit of risk is the chain of decisions and effects. Correct termination, qualified partial results, and fresh observations are assumed here; the Professional task is identifying how a local defect spreads, which workloads share its cause, and where containment must occur.
Anthropic’s effective-agents guidance warns that autonomy increases costs and creates potential for compounding errors. Its multi-agent research account describes stateful execution, expensive restarts, and coordination failures. Treat these as reasons to examine the whole workflow rather than accepting a model-call success rate as the reliability of the service.
How it works
Follow an error into the next decision
Compounding errors occur when a mistake becomes an input to subsequent work. An agent associates a shipment with the wrong order, then uses that association to calculate a refund and draft a customer message. Later steps can be internally consistent while amplifying the original defect. Identify the first state transition where an unverified claim becomes an accepted operational fact.
This is different from a harmless wording error in a draft. The risk increases when the agent can update state, when later checks trust the updated state, and when recovery cannot reconstruct the original value. Your failure analysis should name both the first incorrect observation and each downstream consumer. See 4.4.5 for diagnosing the broken transition from tool and agent transcripts.
Unintended side effects concern what tools actually change. A model can select a valid tool with valid arguments yet act on the wrong business object. A timeout after a write creates another exposure: the caller may not know whether the change occurred. Restarting the entire agent can repeat an operation that already succeeded. Anthropic’s research account explicitly describes why stateful agents need recovery from their position rather than indiscriminate restarts.
For each write path, the operational risk record should name the external effect, how its actual outcome is established, and which later tasks depend on it. These are application-specific business records, not additional fields supplied by Claude. Keep this failure identification distinct from the treatment plan in 5.2.5.
Identify work that continues without useful progress
Runaway loops include repeated unsuccessful actions, repeated correction cycles, and excessive delegation. Anthropic describes agents spawning excessive subagents and searching indefinitely for nonexistent sources. A loop can consume resources while producing plausible progress messages and no accepted outcome.
Agent SDK limits end a run with error_max_turns or error_max_budget_usd. Inspect whether parent retries or fresh jobs recreate the same unproductive work outside those per-run limits. The cap can also be overshot; see 5.2.5 for budget mechanics and treatment ownership.
Distinguish availability, freshness, and drift
Dependency outages affect the model service, retrieval store, tool service, identity system, or another required component. The critical question is which conclusions become unavailable when that dependency fails. A successful search of a different source does not repair a required source outage, and a completed empty search differs from a search that never ran.
Anthropic’s research system combines model adaptation with deterministic retry logic and checkpoints. At architecture review, identify the dependency shared by supposedly independent paths. Sending more specialists to the same unavailable source increases load without creating an independent recovery route. See 4.2.3 for choosing the evaluation layer that exercises such dependencies.
Stale retrieval returns a successful result describing an invalidated version of the world. It may preserve a withdrawn promotion, obsolete inventory, or an access decision that has changed. Retrieval success is not a freshness measurement. Record the source revision or effective time needed by each consequential claim and identify which ingestion or refresh process can leave that claim behind. See 3.5.4 for index lifecycle design; this lesson concerns the resulting operational exposure.
Drift changes the conditions under which the system was evaluated. Inputs, document mix, tool behavior, policies, or the deployed model can change. Model retirement can also interrupt service; see 2.1.4 for model lifecycle and migration decisions. Distinguish this distribution or dependency change from variation between repeated runs under fixed conditions. NIST AI RMF MANAGE 3 calls for monitoring third-party resources and pretrained models; MANAGE 4.1 includes post-deployment monitoring and change management. Those activities produce the change record against which your team assesses the risk.
Look for shared causes across agents
Cascading multi-agent failures spread through delegation, shared sources, or shared state. Several agreeing specialists do not provide independent confirmation when all inherited the same wrong order identifier or cached policy. A coordinator that discards a failure qualification can turn a contained gap into a false complete conclusion.
Map which specialist outputs depend on each shared input and which outputs feed a write. Anthropic’s research account emphasizes clear delegated task boundaries and describes coordination complexity. Use that dependency view to distinguish an independent branch that can finish from a dependent branch that must remain unresolved. More agents can add coverage, but can also replicate the same defect and enlarge its consequences. The dependency view separates a dependent branch that must remain unresolved from an independent branch that can finish.
Key distinctions and trade-offs
The following questions separate failures that often look alike in a dashboard:
| Question | Failure mode it exposes |
|---|---|
| Did an incorrect result become an assumed fact? | Compounding error |
| Did a valid call change the wrong state? | Unintended side effect |
| Did work continue without accepted progress? | Runaway loop |
| Could the required service be reached? | Dependency outage |
| Was the returned information still applicable? | Stale retrieval |
| Did production conditions depart from evaluation conditions? | Drift |
| Did one defect reach other agents or branches? | Cascade |
Stopping all work after one independent failure wastes usable results. Continuing every branch after a shared prerequisite fails creates unsupported outcomes. The dependency structure decides between those options.
Architecture / decision scenario
A retailer gives an order-recovery agent a 90-second service target. During a promotion change, its search index still returns yesterday’s offer. A stock service times out, three specialists query that same service, and the coordinator repeatedly reassigns their work. One specialist uses a mistaken order association; a refund tool commits before its response is lost. These are illustrative conditions.
The proposed quick fix is ten more specialists and a full restart whenever the deadline expires. The architect identifies stale retrieval, drift from the promotion change, a shared dependency outage, runaway work, compounding order error, uncertain side effects, and a potential cascade into refund and messaging branches.
The operations owner pauses dependent writes until the actual refund outcome and order association are established. Independent customer-history analysis can finish with a visible stock-data gap. The team records SDK exhaustion separately from success and assesses repeated jobs at the workflow level. This preserves useful work while preventing a local uncertainty from becoming a repeated financial action.
Common exam traps
- Assuming independently named agents have independent sources of failure.
- Treating a successful retrieval as proof of freshness.
- Restarting stateful work without establishing prior write outcomes.
- Treating a per-run limit as a bound on a scheduler that relaunches failed runs.
- Calling every quality change nondeterminism when production inputs have shifted.
- Increasing parallelism against a shared unavailable dependency.
What to remember
Trace the error through shared inputs, decisions, state changes, and downstream consumers. Separate availability from freshness and fixed-condition variation from drift. A contained failure remains visible and limited; an unexamined dependency turns it into a cascade.
Knowledge check
An order-recovery agent calls issue_refund, and the call times out after the payment service may already have committed the refund. The scheduler’s default response to a timeout is to restart the whole agent run. What should happen first?
A research coordinator assigns four specialists to assess a supplier before a deadline. Three need the same sanctions-list service, which is down; the fourth analyzes payment history from a separate store. A teammate proposes launching six more sanctions specialists. What should the coordinator do?
An Agent SDK job runs with maxTurns: 30. Monitoring shows runs ending with error_max_turns, none with an accepted outcome, and the job scheduler relaunching each one as a fresh job. The lookup service is healthy and consistently returns no matching record, but each run repeats that lookup without progress; one ticket has consumed 40 runs. What does the architect identify?
A retailer’s pricing agent retrieves promotion terms from a search index. Every retrieval succeeds, yet customers are offered a promotion that was withdrawn yesterday. What should the operational risk record add for each consequential claim?
References
- Anthropic, Building effective agents
- Anthropic, How we built our multi-agent research system
- Anthropic, Agent loop
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- Anthropic, Model deprecations