Why Multi-Agent Orchestration Failures Go Undetected

The MAST failure taxonomy, built from 1,642 annotated execution traces across seven multi-agent frameworks and validated at NeurIPS 2025, found those systems failing on 41% to 86.7% of benchmark tasks. System design issues and inter-agent misalignment together account for roughly 79% of the annotated failures. Neither category maps to model accuracy.

A deploy goes out on a Monday evening. By Tuesday afternoon, the first support ticket arrives: a multi-agent workflow returned incomplete output on three consecutive requests. Every span in the orchestration trace shows HTTP 200. Every individual model call produced coherent text. The natural first check is the LLM, but three of the four common failure classes occur in the coordination layer between agents: a sub-agent that stopped its tool sequence mid-task, agents reading different versions of shared state, or an error introduced at hop 2 that compounded through subsequent hops before appearing at the output.

Why standard LLM monitoring doesn’t catch orchestration failures

Standard observability records what each span returned: whether the call completed, how long it took, and how many tokens it consumed. It has no record of whether the sub-agent did what the next step depends on.

Multi-agent orchestration failures are coordination problems. The orchestrator calls each sub-agent. Each sub-agent returns a response. The infrastructure metrics for every one of those calls can read as normal while the work the sub-agent was expected to do remains incomplete.

Orchestrators typically define success as: the sub-agent call returned without an error. Whether the sub-agent completed its intended tool sequence, or produced the output the next step depends on, is a separate question that standard monitoring doesn’t record.

How multi-agent orchestration failures compound across agent hops

Error compounding across hops

Research from a 2026 study of multi-agent pipeline behavior found that state consistency drops from 100% in direct execution to 23.5% at 10-hop depth. An error introduced at hop 2 doesn’t get caught or corrected by later agents: it passes forward as ground truth. When the same model is used for both planning and verification, the verification step inherits the planner’s blind spots rather than checking independently.

The MAST taxonomy classifies this pattern under inter-agent misalignment, 36.94% of the annotated failures.

Silent partial completions

A sub-agent finishes its model call, but not its tool sequence. The expected writes, lookups, or downstream calls that the orchestrator’s next step depends on haven’t happened. The orchestrator sees a non-error exit and logs success.

The MAST taxonomy classifies this under system design issues, which account for 41.77% of the annotated failures. The sub-agent lacked a precise enough contract for what finished work looks like to recognize it had stopped early.

Stale shared state

Multiple agents reading and writing shared resources at different times create consistency gaps. Agent A reads a resource at T1. Agent C modifies it. Agent B reads the same resource at T2 and operates on a superseded version. The Redis engineering analysis of multi-agent LLM system failures identifies this as the pattern behind mismatches between an agent’s stated reasoning and its actual actions. It’s hard to distinguish from a model reasoning error without a session-level view of what each agent read and when.

Context rot at depth

The lost-in-the-middle effect, documented across multiple model families, shows language model attention degrades on content at middle positions in long context windows. In a multi-agent system, this compounds across hops: Agent A’s output, shaped partly by degraded context, becomes Agent B’s input with no signal that any degradation occurred.

Extending context windows doesn’t resolve this: positional degradation scales with window size, not against it.

How to catch orchestration failures that span monitoring cannot see

These failure classes are visible at the session level but not at the span level. The signals needed to detect them operate differently from infrastructure monitoring.

Not every sub-agent will be instrumented on day one, and that is fine. When a trace goes dark partway through the hop graph, the gap is itself a finding: it names the next sub-agent to instrument, and the next degradation traces one hop further.

Tool-call sequence signals define the expected pattern of tool calls for a sub-agent step and fire when that pattern is incomplete, regardless of what HTTP status the surrounding span reports. This catches silent partial completions without requiring the sub-agent to raise an exception.

Graders running across the Session→Turn→Trace model, the execution graph from user session down to individual model calls, can check whether what Agent B received from Agent A was consistent with what Agent A was supposed to produce. A single-span grader has no view of this. A session-level grader does.

Eval coverage in a multi-agent system works differently than in a single-agent one. The signal is not a grader on the final output: it is a pattern defined on a sub-agent’s expected tool call sequence. When an orchestration refactor changes how the pipeline routes work between sub-agents, that pattern either holds or it breaks. If a signal that was firing on one in fifty sessions now fires on one in five, the rate shift surfaces within the current deploy window rather than after a support queue has accumulated.

The rate shift is the alarm, not the answer. The hop graph is also the chain the answer lives in. Tessary traces a failing session signal back through it, sub-agent by sub-agent, to the input that fed the failure, whether that input came from your deploy, from an upstream agent whose output shifted, or from a tool that started returning different data. A commit SHA attached to every verdict covers the first case; walking the chain covers the other two, which never appear in a diff.

That is how the Monday-deploy scenario at the top resolves. The deploy was the natural suspect, but it never touched the orchestrator. An upstream sub-agent’s output format had shifted, and tracing back from the failing signal found it, instead of a week spent re-reading a diff that was never the cause.

---

Route your orchestration traces through Tessary to catch these failure classes as they emerge, and when one starts firing, trace it back through the hop graph to the change that caused it. Langfuse and Braintrust hold the traces and track the scores; Tessary reads the same data and says which change moved the score. Send OTLP directly or pull from a connected Langfuse or Braintrust source, with no schema changes and no credit card.

Find what broke your agent