Multi-agent architecture failure modes: what breaks in production and how regulated firms contain it

Multi-agent architecture failure modes are the ways systems of cooperating AI agents break down when coordination, handoff or verification fails. Regulated financial services firms contain them by placing governance gates before planning and before any irreversible action, recording audit-grade evidence at every handoff, and setting autonomy per step rather than relying on the agents to coordinate themselves.

Single-agent failures usually surface as isolated reasoning or tool-use errors. Multi-agent failures compound through shared state, lost context and missing verifiers. Production adds pressure that benchmarks do not: latency targets, audit requirements and record-keeping obligations expose coordination surfaces that lab settings rarely test. Engineering leaders in banking and insurance need a precise taxonomy of those surfaces, then a containment path that moves work from human-in-the-loop review towards semi-autonomous operation without giving up accountability.

What is a multi-agent architecture failure mode?

A multi-agent architecture failure mode is a coordination or verification breakdown that stops a task completing correctly when two or more agents share work, state or decision authority. The phrase names a class of production defects rather than a single bug. Single-agent systems fail on reasoning quality, tool selection or local policy misses. Multi-agent systems add failure surfaces at the boundary between agents: an agent acting outside its role, a handoff that drops context, an agent ignoring another agent's input, or a verification step that is missing or wrong.

The most widely cited classification is MAST, the Multi-Agent System Failure Taxonomy, which groups 14 failure modes into three categories: system design issues, inter-agent misalignment and task verification (Cemri et al., "Why Do Multi-Agent LLM Systems Fail?", NeurIPS 2025).

Production differs from benchmark settings for structural reasons. Benchmarks score task completion on fixed prompts. Production workloads in a bank carry residency constraints, dual-control rules, model-risk expectations and record-keeping obligations. A handoff that looks clean in a lab can still fail audit because the receiving agent never received the policy version, the evidence hash or the gate decision that authorised the step.

Why multi-agent systems fail at scale in regulated environments

The MAST researchers measured failure rates between 41% and 86.7% across seven open-source multi-agent frameworks on benchmark coding, maths and general-agent tasks (Cemri et al., 2025). Each framework ran on a different benchmark, so the authors caution that the rates are not directly comparable, and none of them is a production measurement. The taxonomy itself was built from 150 annotated traces with inter-annotator agreement of κ = 0.88. The useful conclusion is narrower than the headline numbers: coordination does not emerge reliably from better models, so it has to be designed.

The commercial picture points the same way. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls (Gartner, June 2025). Inadequate risk controls is the cause this guide addresses.

MAST's three categories and their failure modes are set out below. The shares are calculated from the per-mode figures reported in the paper's October 2025 revision.

Regulated settings add failure surfaces that MAST does not label, because they come from compliance rather than from task success. This guide treats them separately from the MAST modes: a decomposition that breaks a dual-control policy, a handoff that drops the policy version or evidence hash, and a decision whose path cannot be reconstructed for audit. Each maps onto a compliance surface. Auditability needs a reconstructable path from intent to action. Accountability needs the policy or the person that authorised the step. Record-keeping needs durable evidence that the decision and its inputs were not altered after the fact.

Coordination failures compound faster than single-agent errors because one agent's incorrect plan can propagate through shared memory, tool side effects or protocol assumptions before any verifier acts. A single-agent mistake is often local and reversible at the tool boundary. A multi-agent mistake can fork state across several workers, create conflicting writes, or lock in an unverified assumption that later agents treat as fact. A controlled study from Google Research and collaborators measured the effect: independent agents amplified errors 17.2 times, while centralised coordination with a validation step contained the amplification to 4.4 times (Kim et al., "Towards a Science of Scaling Agent Systems", 2025). More agents mean more handoffs, more opportunities for truncated context, and more places where a unit-tested local contract still breaks the global policy. Regulated firms therefore need containment patterns that treat the MAST categories as design constraints from the first release.

System design issues

System design issues are the largest MAST category. They include agents disobeying the task or role specification, repeating steps, losing conversation history, and not recognising when the task is finished. In a bank they take recognisable forms. An agent labelled "analyst" quietly acquires write privileges, which is a role-specification failure. A verifier agent is sketched in the architecture diagram and never wired into the runtime path. Each of these defects can pass unit tests, because every agent satisfies its local contract while the workflow as a whole breaks policy.

Decomposition by convenience is one of the most durable problems in regulated workflows, although MAST does not label it separately. Teams split work into steps such as "research", "draft" and "submit" rather than by bounded business capability, or an orchestrator splits a credit workflow into steps that no longer match the bank's dual-control policy. The resulting graph looks productive in a demo and fails under exception paths: partial fills, conflicting customer records, or a screening hit that arrives after a downstream agent has already committed a provisional decision. Because each hop is locally coherent, integration tests that only check happy paths miss the failure until production traffic exercises the edge case.

In financial workflows, domain alignment and bounded contexts reduce these failures by limiting each agent's scope to a single aggregate or process. A screening agent stays inside screening. A credit-decision agent consumes screening outcomes as evidence, not as an invitation to re-run list logic. Bounded contexts make role violations visible at design time: if an agent needs data outside its context, the architecture must declare an explicit anti-corruption path and a gate. Domain language also stabilises prompts and tool contracts, so agents stop inventing synonymous actions that bypass controls. The practical move is to design agent roles from the domain model first, then attach models and tools.

Inter-agent misalignment

Inter-agent misalignment covers six MAST modes: conversation resets, failing to ask for clarification, task derailment, information withholding, ignoring another agent's input, and a mismatch between an agent's reasoning and its actions. In production these show up as two practical problems. Message contracts drift when agents disagree on message shape, required evidence fields or the meaning of status codes. Context is lost when a long-running workflow truncates history, drops the policy version, or summarises away a constraint that later steps needed. Neither looks dramatic in isolation. Together they produce actions that no single agent would have taken with full state.

A common pattern is an unverified assumption that hardens as it moves through the workflow. One agent proposes a customer risk tier; the next treats that tier as verified fact; a third executes a product action that only made sense under the unverified tier. The closest MAST modes are ignored input, information withholding and reasoning-action mismatch. Later agents that inherit truncated or summarised context lose the alternative interpretations with it, so the trace shows no sign that the tier was ever in doubt. In an onboarding, claims or trading workflow, that is a path to an unauthorised commitment.

Governance gates that enforce shared truth before any agent acts are the main containment for this category. The gate evaluates the current intent and evidence bundle against policy, records the decision with its inputs and policy identifiers, and only then releases the next agent. The shared truth here is a governed artefact rather than a chat summary: the intent, the evidence hashes, the policy version and the gate verdict. Teams that rely on free-form message passing without that artefact will keep meeting misalignment as intermittent production defects. Making the gate the only path between agents turns misalignment into a blocked transition that can be reviewed, replayed and fixed.

Task verification failures

Task verification failures occur when work is not checked properly before it completes. MAST names three modes: premature termination, no or incomplete verification, and incorrect verification. In production they look like a grader that exists in the design but is skipped when latency budgets tighten, a human review queue for high-risk scores that is auto-approved when it backs up, or a final "sanity check" agent that echoes the previous agent's conclusion without independent evidence. Each ships work that cannot answer the audit question: what policy was in force, what inputs were evaluated, and who or what authorised the step.

Termination needs its own controls. MAST lists premature termination under verification, and unawareness of termination conditions, along with step repetition, under system design. In financial services both ends are costly. A runaway loop burns model and tool spend, and a workflow that stops early can commit a half-evaluated decision. Contain them with hard step and budget limits per workflow, and with explicit completion criteria that a gate checks before the result is committed.

Audit-trail gaps follow directly. If the system cannot reconstruct why an action was taken, the output fails supervisory review even when the business result looks correct. Several instruments make this concrete for banks. Under the EU AI Act, AI used to assess the creditworthiness of individuals is high-risk, with duties for automatic logging (Article 12) and human oversight (Article 14), and for these Annex III systems the obligations apply from 2 December 2027. UK data protection law sets safeguards for significant decisions taken solely by automated means, including the right to obtain human intervention. The PRA's SS1/23 sets model risk management expectations for banks with internal model approval, and the Senior Managers and Certification Regime makes a named senior manager accountable for each business area. Design so that the evidence exists: the policy version, the inputs, the gate or reviewer decision, and the ability to replay the decision path. Replay here means re-driving the recorded agent outputs through deterministic gates with model and policy versions pinned. Regenerating the outputs will not reproduce them, because the same inputs do not reliably produce the same LLM output. Missing verification is therefore a compliance exposure as well as an engineering defect.

Reversibility and evidence interoperability close the gap. Every material decision should carry a trace that supports rollback, a compensating action, or replay under audit. Evidence interoperability means the artefact is useful outside the agent stack that produced it: another team, another model generation or an external reviewer can interpret the same bundle. Practical controls include append-only event logs for intent and gate outcomes, deterministic identifiers for policy versions, and explicit compensation paths when a later check fails. Append-only logs sit uneasily with erasure rights, so keep personal data out of the log itself and reference it by token, or encrypt it under per-subject keys that can be destroyed (crypto-shredding). Verification belongs at intent time and at commit time, before the customer-facing action lands.

Containment patterns for regulated workflows

How do you debug multi-agent systems in regulated production?

Treat debugging as governed replay over durable traces. Start from the intent record, walk each gate decision, and inspect the evidence bundle each agent saw. Then re-drive the recorded agent outputs through the same gates, with model and policy versions pinned, to find the transition that should have been blocked. Searching logs after an incident rarely gets that far, because chat transcripts do not record which policy authorised each step.

Moving from human-in-the-loop to semi-autonomous operation

The operating spectrum has three points. With human-in-the-loop control, every material action needs explicit human approval before commit. With semi-autonomous operation, agents plan and act inside policy envelopes enforced by governance gates, and people write the policy and handle exceptions. Fully autonomous execution sits at the far end. For material financial decisions, keep fully autonomous paths rare unless reversibility, evidence interoperability and clear accountability are engineered into the runtime, because the logging and oversight duties above are hard to evidence otherwise.

Firms move along that spectrum through explicit policy gates rather than post-deployment checklists. Human-in-the-loop remains appropriate for novel products, high-severity exceptions and early rollout. Semi-autonomous operation becomes viable when gates encode dual control, jurisdiction, data residency and risk thresholds as runtime constraints, and when every release can prove those constraints still hold.

Established containment patterns

• A policy decision point outside the agents. Agents request permission and a separate policy engine decides, so no agent can grant itself authority. Run the evaluation synchronously on the critical path for irreversible or high-risk steps. Synchronous gates add latency to every step they guard, so low-risk, reversible steps can be checked asynchronously and sampled.
• Typed handoff schemas. Every message between agents is validated against a schema that includes the required evidence fields and the policy version, so a handoff that drops them fails loudly instead of silently.
• Saga and compensation with idempotency keys. Multi-step workflows record a compensating action for each committed step, and idempotency keys stop a retried step from executing twice.
• Step and budget limits. Hard caps on iterations, tool calls and spend per workflow stop runaway loops before they become cost or conduct incidents.
• An independent verifier with a separate evidence source. The verifier checks the result against data the producing agent did not use, instead of re-reading that agent's reasoning.

Gates sit at three points in the workflow: an intent gate before any planning, an evidence gate after planning and tool calls, and a commit gate before any irreversible customer or ledger action. Each gate writes an evidence record before it releases the next step. A minimal shape, as pseudo-code:

// Pseudo-code: the record each gate writes before releasing the next step
interface GateEvidence {
  intentId: string; // ties every step back to the authorised request
  gate: "intent" | "evidence" | "commit";
  policyVersion: string; // pinned, so replay applies the rules in force at the time
  modelVersion: string; // pinned for the same reason
  inputsHash: string; // shows the inputs were not altered after the decision
  agentOutputRef: string; // the recorded output, re-driven on replay rather than regenerated
  verdict: "allow" | "block" | "escalate";
  decidedBy: string; // policy rule id or reviewer role, not a personal identifier
  outcome?: "committed" | "compensated";
  recordedAt: string; // ISO 8601 timestamp
}

Event-driven architectures make every decision and evidence record durable and queryable, so engineering and risk teams share one timeline of intent, gate, plan, action and outcome. Apply governance at the Intent and Specification stages, so that verification precedes action; AI-Native Engineering describes how governance checkpoints sit between those stages in the delivery lifecycle.

Common pitfalls when adopting multi-agent systems

Treating governance as a post-deployment checklist leaves coordination surfaces unexamined until an incident occurs. Teams ship a multi-agent pilot on a happy-path demo, then discover that exception handling, dual control and audit evidence were never designed. By then the agent graph is entangled with product timelines, and adding gates feels like a rewrite. Governance has to be present in the first vertical slice: one real workflow, one bounded context, one gate, one replayable trace.

Over-reliance on tracing without governed shared memory is the second common failure. Distributed traces show latency and call order. They do not by themselves preserve the shared truth agents need across handoffs. Without a governed memory or evidence store, agents re-summarise, drop constraints and harden unverified assumptions while the dashboards suggest full observability. Tracing is necessary but not sufficient.

Assuming that more agents or stronger models will fix coordination failures ignores what MAST found: its authors argue that many failures come from system design rather than from the limits of the underlying model. Adding agents multiplies handoffs. Swapping models changes local reasoning quality without repairing role boundaries, gate placement or verification. Put the gates, evidence records and step limits in place before scaling the pilot.

Decision framework for moving from diagnosis to containment

Use a simple decision sequence when a multi-agent design enters a regulated workflow.

First, decide whether the workflow needs multiple agents at all. The MAST authors note that multi-agent systems often show minimal gains over single-agent baselines on popular benchmarks. The Kim et al. study found that coordination helps on tasks that split into parallel parts, such as decomposable financial analysis, and degrades performance on tasks that need strict sequential reasoning: every multi-agent variant lost between 39% and 70% on sequential planning. Many regulated workflows, onboarding and credit decisions among them, are largely sequential, and a single agent working inside deterministic workflow steps is often the safer design.

Second, map the workflow to the MAST categories: which steps fail on role or task specification, which fail on handoff truth, and which fail on verification or termination. Third, place the minimum gate set on the critical path. At least one gate must evaluate intent before planning tools run; at least one gate or verifier must evaluate evidence before any irreversible customer or ledger action. Fourth, choose the autonomy level per step, not per programme. Low-risk, high-volume steps can move towards semi-autonomous operation once policy tests are automated. High-severity steps stay human-in-the-loop until reversibility and dual control are proven in production-like drills.

Fifth, define the evidence record every agent must emit, as in the schema above. If two agents cannot consume the same record, they are not interoperable under audit. Sixth, require replay. A failure is closed only when the team can re-drive the recorded outputs of the blocked transition through the gates, with model and policy versions pinned, and show the same gate verdict. Seventh, refuse scale-out until the happy path and the top exception paths both produce complete traces. This sequence keeps model selection and agent count as secondary decisions; gate placement, evidence shape and autonomy boundaries come first.

Further reading

• Why Do Multi-Agent LLM Systems Fail? (Cemri et al., NeurIPS 2025): the source of the MAST taxonomy and its 14 failure modes.
• Towards a Science of Scaling Agent Systems (Kim et al., 2025): a controlled study of when coordination helps and when it amplifies errors.
• Agentic AI for regulated enterprises: how agentic systems are designed and governed in financial services.
• What agentic AI means for financial services leaders: a plain-language briefing on where agentic AI fits in banks and the governance questions it raises.
• Human-in-the-loop AI for regulated decisions: designing the oversight points this guide places in the workflow.
• Why agentic AI initiatives fail: what happens when autonomy outruns runtime boundaries, evidence and escalation paths.
• A multi-agent financial crime detection architecture: how narrow agent roles and deterministic orchestration kept a detection system defensible.

Decide autonomy per step, not per programme, and do not scale a multi-agent workflow out until its top exception paths produce complete, replayable traces. That is the point at which a supervisor's questions about a failed decision can be answered from the record.