What changes when agents coordinate
A single agent fails in ways you can test directly: bad output, wrong tool call, hallucinated fact. When you run multiple agents in parallel, a new class of failure appears that has nothing to do with any individual agent's quality. Two agents read the same record at slightly different times and reach different conclusions. One agent commits a write while another is mid-read. A decision made in one subagent becomes stale by the time a downstream agent acts on it.
These are coordination failures, and they do not show up in per-agent evaluation. Multi-agent LLM systems fail at rates between 41% and 86.7% in production, with a taxonomy of 14 distinct failure modes identified across more than 1,600 execution traces at NeurIPS 2025. Most of those failure modes are structural, not model-quality issues.
The difficulty is operational scale. 38% of organizations have already deployed more than 100 agents, and the number keeps rising. At that scale, the gap between what any single agent does and what the system as a whole does grows wide enough to hide serious failures.
Three coordination failure modes to instrument for
Stale decisions
When agents operate on context that was current at read time but has since changed, their decisions can conflict with the system's actual state. This is especially sharp in coding agents, orchestrators, and anything touching shared data. Meetless, which ships a runtime context system for parallel coding agents, addresses this directly by giving agents a way to verify decisions against current state before committing them. Without that kind of verification layer, a stale decision propagates silently.
The instrumentation requirement here is timestamps on every context read. When you record when each agent read which data, you can reconstruct whether two agents were operating from compatible snapshots. An activity schema validation approach lets you define what "compatible" means for a given workflow and flag deviations automatically.
Information conflicts
Two agents working from different sources, or from the same source at different times, can produce outputs that contradict each other. Neither agent has failed on its own terms. The conflict only becomes visible when you compare their outputs side by side.
Detecting this requires cross-agent output comparison as a first-class evaluation step, not something you do after an incident. You need to capture what each agent decided, not just what it returned, and then run a compatibility check across agents that touched the same domain in the same session.
Race conditions
Race conditions occur when the order of agent operations matters but is not enforced. Agent A reads a value, agent B updates it, agent A writes a decision based on the old value. The result is wrong in a way that a replay of any single agent's trace looks correct.
Catching race conditions in evaluation means recording operation order with enough granularity to reconstruct the interleave. Span timing in OpenTelemetry-compatible traces gives you the raw material; the analysis layer has to look across spans rather than within them.
What evaluation needs to cover
Per-agent evaluation, the kind most teams already run, answers the question: did this agent behave correctly given its inputs? Multi-agent evaluation adds a second question: did the agents, taken together, reach a consistent and valid outcome?
That second question requires at least three things your current setup probably does not have.
First, a shared context record that all agents read from and write to, with versions. Without versions, you cannot detect staleness. This is what Meetless built natively for coding agents, and it is the pattern the multi-agent orchestrator category needs generally.
Second, cross-session span analysis. Individual agent evaluation in production already depends on spans. Multi-agent evaluation extends that by joining spans across agents that share a session ID or a task ID. Prefactor records spans at this granularity and can score agent outputs against schemas defined for each agent role, which makes compatibility checking tractable without writing custom analysis code for every workflow.
Third, behavioral schemas for each agent role in the system. If agent A is a planner and agent B is an executor, you can define what a valid handoff looks like and validate every handoff against that definition. Behavior span validation before deployment reduces the rate at which schema violations reach production.
Why scale makes this harder, not just larger
The Deloitte research published in August 2026 found that only 15% of US organizations have achieved scaled multi-agent orchestration. One reason is that the evaluation and governance infrastructure needed to run multi-agent systems safely is genuinely different from single-agent infrastructure, not just bigger.
Wells Fargo's deployment of multi-agent tooling to more than 180,000 desktops illustrates the governance surface that opens up at scale. When the number of agent interactions reaches that level, manual review of failures is not feasible. The evaluation layer has to catch coordination failures automatically and surface them with enough context to act on.
Organizations that have made the leap to scaled orchestration consistently report needing audit trails that span sessions, not just individual agent runs. Audit trails built for multi-agent workflows need to record which agents acted, in what order, on what context version, and what they produced, so that a failure can be traced back to its structural cause rather than attributed generically to "the AI."
Practical instrumentation steps
You do not need to rebuild your stack to start. The changes that matter most are additive.
Add session IDs that span all agents in a coordinated task. Without a shared ID, cross-agent analysis has no join key.
Record context version on every agent read, not just the content. If two agents read version 14 of a document and one reads version 15, that discrepancy is detectable, but only if you logged the version.
Define at least a minimal activity schema for each agent role. Even a schema that covers only the most critical actions, the ones that write to shared state or hand off to another agent, gives you a baseline for detecting behavioral drift before it causes downstream failures.
Run compatibility checks as a post-session evaluation step. For each session where multiple agents touched the same data, compare their outputs for logical consistency. Scoring these checks over time gives you a coordination reliability metric that is separate from per-agent quality scores.
Step-level evaluation at the individual action level, rather than only at task completion, catches the point where a coordination failure begins rather than where it lands.
Where to start
If you are running more than two agents in parallel on shared tasks, the instrumentation gaps described here are already active, even if no failure has surfaced yet. Add session-scoped span collection, version your shared context, and define schemas for your highest-risk agent roles first.
Start evaluating your agents with Prefactor's span recording and schema validation, and read the docs for setup guides on multi-agent session instrumentation.