TL;DR
Multi-agent monitoring is tracking how a team of AI agents performs together: whether the overall task succeeds, which agent contributed what, and whether the handoffs between them worked. Multi-agent systems mostly fail in the gaps between agents, through unclear roles, lost context and nobody checking the final result. Monitor them with one trace per task across every agent, a logged record of each handoff, metrics per agent role, and security signals for instructions passed between agents. It builds on single-agent practice, covered in our complete guide to AI agent observability.
Why multi-agent systems are harder to monitor
In a single-agent system, one model plans and acts. In a multi-agent system, a planner might split the task, a researcher gathers data, a writer drafts, and a reviewer approves. That brings three new problems for monitoring:
• The story splits. Each agent may run in its own process or service. Without shared trace context, one task becomes several disconnected traces.
• Blame is unclear. When the final output is wrong, the mistake could sit in any agent or in a handoff between two of them. Finding which agent caused a failure, and when, is hard enough to be its own research topic.
• Errors travel. A small mistake from one agent becomes the next agent’s trusted input. By the end, the original error is buried under several layers of confident work.
How multi-agent systems fail
Researchers at UC Berkeley studied this directly. They annotated more than 1,600 execution traces from seven popular multi-agent frameworks and found 14 distinct failure modes in three categories: specification issues, inter-agent misalignment and task verification (Cemri et al., NeurIPS 2025; alphaXiv summary). They also found that many failures come from system design, not just model limits (arXiv).
That gives a practical map for monitoring:
| Failure category | What goes wrong | What to monitor |
| Specification and design | Agents with unclear roles, ignored task constraints, repeated steps | Role violations, repeated work across agents, steps per agent per task |
| Inter-agent misalignment | Lost context, withheld information, agents talking past each other, conversation resets | Handoff content vs. the original task, clarification requests, context dropped between agents |
| Task verification | Ending too early, never ending, or no real check of the result | Termination reason, loops between agents, whether the verifier agent actually checked anything |
What to monitor
Track three levels: the whole system, each agent role, and each handoff. For the single-agent metrics underneath, see AI agent monitoring: what to track in production.
| Level | Metrics | Example alert |
| System | End-to-end task success, total cost and latency per task, number of agents involved per task | Task success drops 5+ points after a change to any agent |
| Agent role | Success, error rate, cost and steps per role (planner, researcher, writer, reviewer) | One role’s cost per task doubles while others stay flat |
| Handoff | Handoffs per task, rejected or re-sent handoffs, loops between agents, context size passed | Two agents hand the same task back and forth 3+ times |
| Verification | Share of tasks where the reviewer agent changed or rejected the output | Reviewer approval rate jumps to near 100%, a sign it may have stopped checking |
| Security | Instructions passed between agents that fall outside the sender’s role, new tools requested, permission changes | An agent asks another to run an action outside its role |
The verification row deserves attention. A reviewer agent that approves everything looks healthy on a dashboard but provides no protection. Sample its decisions and score them against a human review.
Log the handoff itself
For every handoff, record what the sending agent asked for, what context and permissions it passed, and what the receiving agent understood the task to be. Many multi-agent failures are miscommunications: the task that arrived isn’t the task that was sent. Comparing the two is often the fastest way to find the root cause.
How to trace across agents
1. One trace per task. Create a root span when the task starts, and pass its trace context to every agent, sub-agent, tool and MCP server it touches. OpenTelemetry’s trace context propagation handles this across services.
2. A span per agent turn. Each agent’s work becomes a child span with the agent’s name, role and version, so you can filter and compare by role.
3. A span per handoff. Record sender, receiver, the task text, the context passed and the permissions granted.
4. Model the hierarchy. A clean data model, such as agent, then conversation, then turn, then model call, then tool call, makes multi-agent traces readable (CoreWeave).
5. Tag outcomes per agent. Mark each agent span with its own result, so you can attribute a failed task to the agent that caused it, not just the last one to act.
When something fails, read the trace from the root and find the first handoff where the task changed shape. That’s usually where the problem started. LLM tracing for agents covers how to read a trace span by span.
Security: when one agent compromises the rest
Multi-agent systems create a new attack path. If one agent reads a poisoned email, web page or tool output, it can pass the attacker’s instruction to the next agent as an ordinary task, and that agent acts on it with its own permissions. The agent that does the damage may never have touched the malicious input.
Monitor for it:
• Role violations. Alert when an agent asks another to do something outside the requester’s role.
• Permission creep. Watch for agents requesting new tools, broader data access or permission changes mid-task.
• Unusual destinations. Flag first-time domains, email addresses or accounts in any agent’s tool calls.
• Tainted inputs. Track which agent first read untrusted content, and treat everything downstream of it as higher risk.
Tool connections widen this further, because MCP servers can carry hidden instructions in their tool descriptions and outputs; see MCP security for AI agents. And because monitoring only sees attacks after they happen, test agent-to-agent paths before launch; our comparison of AI red teaming tools for autonomous agents covers which tools test multi-agent attack surfaces.
The bottom line
Multi-agent systems rarely fail inside a single agent. They fail in the handoffs: unclear roles, lost context, a reviewer that stopped reviewing, or one compromised agent instructing the rest. Keep the whole task in one trace, log every handoff, measure each role separately, and watch what agents ask each other to do.
Find what’s broken in your agents before your users do. BotGauge red-teams multi-agent systems, including the paths between agents.Try Botgauge for Free or book a 30-minute demo.