AI Agent Design Patterns: Choose by Failure Containment

AI agent design patterns should be chosen by the failure boundary you can operate. Start with a direct model call or one agent with tools. Add sequential stages, parallel branches, specialist handoffs, or a review loop only when a measured workload requirement justifies the new topology—and only when you can record the evidence that topology needs. That answer is less glamorous than drawing a fleet of collaborating agents. It is also easier to debug, cheaper to run, and harder to mistake for a healthy system when part of the work has disappeared. The central rule is simple: Every new execution edge creates evidence debt. Do not add the edge until you can name its false green state and the receipt that disproves it. This article applies that rule to six common choices: a direct model call, a single agent, a sequential pipeline, parallel fan out, specialist handoff, and a bounded review loop. It includes a deterministic selector replayed against six workloads. Start below “agent” unless the task earns autonomy An architecture diagram should begin with the least powerful mechanism that can satisfy the task contract. A one step classification or translation usually needs neither tools nor an agent loop. The health question is simply whether the output meets a defined assertion. A single agent becomes useful when the task is open ended enough to require several decisions or tool calls. An order support agent, for example, can interpret a request, retrieve an order, and compose an answer. It still has one owner and one place to verify the outcome. This is consistent with current official guidance. Google Cloud’s agent pattern guide says to define task complexity, latency, cost, and human involvement requirements before selecting a pattern. It recommends starting with one agent during early development and notes that multi agent designs add evaluation, security, reliability, and cost concerns. The Azure Architecture Center similarly recommends the lowest complexity that reliably meets the requirements; it calls out coordination overhead, latency, and additional failure modes in multi agent systems. Use this first decision boundary: Workload property Reasonable default Completion proof One constrained transformation, no tools Direct model call Output passes the task assertion Several decisions inside one domain Single agent with tools Required tool effects and final outcome are verified Fixed stages with strict dependencies Sequential pipeline Every stage consumed the expected predecessor version Independent subtasks whose latency matters Parallel fan out Every required branch is accounted for before aggregation Dynamic routing across distinct domains or authorities Specialist handoff A receiver accepted ownership and can resume from a durable cursor Revision must continue until a measurable condition holds Bounded loop Progress changed, the verifier passed, and the iteration budget held The table is a default, not an automatic design. A direct call can still be unsafe if its output triggers an irreversible action. A single agent can still be too broad if it has dozens of tools with incompatible permissions. The pattern follows the workload and authority boundary. The important restraint is to avoid treating decomposition as free reliability. Splitting one task among more components may improve specialization, latency, or security isolation. It also creates more partial states. The operator must be able to tell which state the run occupies without reading a persuasive final message. Make each topology pay its evidence debt AWS Prescriptive Guidance describes agent patterns as reusable, composable building blocks. Reuse is valuable, but composition changes what “done” means. A component reporting success is only activity evidence. The useful question is whether the whole topology produced the intended result. Sequential: prove the chain, not the last stage A sequential pattern is appropriate when stage order is part of correctness: extract, validate, approve, then publish. The false green case appears when a later stage runs after an earlier stage failed, used stale output, or produced an incompatible version. Give every stage a receipt containing at least: the run ID and stage ID; the predecessor receipt or input hash; the output hash or durable effect ID; terminal state and completion time; the assertion that permits the next stage. The next stage should reject a missing or mismatched predecessor rather than guess. A final “publish completed” event cannot repair an absent validation receipt. Parallel: freeze membership before counting completion Parallel fan out is justified when independent branches reduce latency or gather distinct evidence. Its characteristic failure is a collector returning a polished answer while a required branch is absent, duplicated, late, or based on stale input. Freeze a branch manifest before dispatch. Mark branches required or optional. Then define a quorum over the frozen manifest, not over whichever responses happened to arrive. The collector needs branch identity, input version, terminal status, effect identity, and freshness. “Three responses received” is not enough if four were required. Handoff: transfer ownership, not merely context A specialist handoff is useful when the next agent needs a different domain, tool set, or permission boundary. It fails silently when the sender reports “transferred” but the receiver never accepted the work—or accepted it without the state required to continue. A durable handoff needs two sides: 1. the sender records the intended receiver, work ID, context version, and remaining outcome; 2. the receiver records acceptance, its own ownership epoch, and a resume cursor. Until acceptance exists, the work is waiting with the sender. After acceptance, only the receiver may commit the next effect. This prevents an ambiguous gap and reduces duplicate work after retries. Loop: budget progress, not just iterations A generator–critic or repair–verify loop is appropriate when quality improves through repeated evaluation. It is not appropriate merely because the first result might be weak. The loop must have a measurable progress signal, a verifier, and a stop condition. Record: iteration number and maximum; deadline and cost remaining; input and output fingerprints; a domain specific progress delta; verifier result; reason to continue, stop, or escalate. A loop that repeats different wording without changing tests, constraints, or the expected artifact is active but not progressing. Stop it before it consumes the final budget needed to preserve evidence, roll back, or ask a person. Replay a selection rule before adopting the diagram I converted the preceding boundaries into a small deterministic selector. It deliberately prefers simpler patterns. The precedence is explicit so a workload that needs an iterative verifier does not accidentally fall into the sequential category merely because its steps have an order. The complete artifact uses pattern cases.json , select agent pattern.mjs , and an expected report. Run it with: The six case replay produced exact expected parity: Workload Selected pattern Required receipt Classify one message Direct model call Input/output assertion Look up an order and answer Single agent Run manifest, tool effect receipts, outcome assertion Extract, review, publish Sequential Stage receipt chain, input version, stop on failure status Research four independent sources Parallel fan out Frozen branch manifest, required quorum, aggregate assertion Route support to a specialist Specialist handoff Ownership receipt, resume cursor, final assertion Revise code until tests pass Bounded loop Iteration budget, progress delta, verifier verdict All six recommendations matched, and all six emitted a distinct evidence obligation. That second result matters more than selector accuracy. A pattern name without its receipt contract is a design preference, not an operational decision. Three observations came out of the replay. First, topology ambiguity maps to evidence ambiguity. Sequential stages create partial completion ambiguity; parallel branches create membership ambiguity; handoffs create ownership ambiguity; loops create termination ambiguity. Second, the same final outcome assertion remains necessary in every pattern. A complete branch manifest proves branch accounting, not that the assembled report answered the customer’s question. A handoff receipt proves ownership, not delivery. A passing critic verdict proves only the criteria the critic actually evaluated. Third, migration triggers are more reliable than pattern enthusiasm. Move away from one agent when evidence shows tool overload, a strict security boundary, independent latency, or a recurring failure that the simpler topology cannot contain. “Multi agent is more scalable” is not a measurable trigger. Treat the pattern as an operational contract Before implementation, write a one page contract for the chosen pattern: Intended outcome: What observable artifact or effect must exist? Authority: Which component may make each reversible or irreversible change? Membership: Which stages, branches, or specialists belong to this run? Progress: What changes when useful work advances? Waiting: Which dependency or human decision legitimately pauses work? Failure: What evidence separates a transient error from a stuck run? Completion: Which deterministic checks clear the work? Budget: What caps time, retries, tokens, and side effects? Then inject the topology’s characteristic failure before launch. Remove a sequential stage receipt. Drop one required parallel branch. Delay handoff acceptance. Return an unchanged artifact from a review iteration. The system should become blocked, waiting, or uncertain—not green. There is a practical limitation here. The selector cannot establish that your workload description is correct. It does not measure model quality, provider availability, or the actual reliability of a framework. A receipt schema also cannot prove its implementation emits truthful events. Validate the chosen pattern with production shaped fixtures, failure injection, and destination level outcome checks. The safest review question is therefore not “Which AI agent design pattern is best?” It is: Which is the least complex pattern that satisfies this workload, and can we prove its new partial states without inspecting private content? If the answer is a direct call or one agent, keep it. If the answer is a more complex topology, make its receipts part of the design rather than a later monitoring project. Sidewisp is intended to add a health layer around existing agent runtimes, with attention to reachability, useful progress, context, tools, outcomes, and cost. Sidewisp is currently in private preview. Its public website and interactive demonstration are live, but production agent health collection and runtime adapters are not shipped in the current website repository. If this evidence first approach matches how you want to operate agents, you can join the private preview waitlist.