Agent-to-agent evaluation measures the interactions between agents in a multi-agent system. When an orchestrator decomposes a task and delegates it, when a router picks a specialist, or when a subagent returns a result to whoever called it, each of those transfers is a place where the work can be damaged. Agent-to-agent evaluation scores the transfer itself, not just what each agent produced in isolation.
This is a narrower question than whether an agent is any good at its job. Evaluating a single agent’s task success, tool use, and trajectory is AI agent evaluation, and it applies the same way whether that agent works alone or as one node in a graph of six. Agent-to-agent evaluation adds only the part that appears once there is more than one agent: whether the instruction that crossed the boundary was sufficient, and whether what came back was usable.
It is worth measuring separately because multi-agent failures usually are not reasoning failures. They are interface failures. The delegating agent left out the constraint that mattered. The subagent returned prose where the caller expected a structured record. The caller got a good result and ignored it. Each produces a bad final answer while every individual agent looks like it behaved reasonably.
Build better agents with Arize
Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.
Prefer open source? Try Arize Phoenix for self-hosted, open source agent observability.
Key takeaways
- Agent-to-agent evaluation scores the handoffs in a multi-agent system: what one agent asked for, and whether what came back was usable.
- Delegation quality is measurable. Check whether the instruction carried the constraints the parent already knew, named a concrete deliverable, and went to the right recipient.
- A subagent that returns a confident guess instead of declaring that it failed is the most damaging output in a multi-agent system, because the caller has no way to tell.
- Attribution needs the call graph. Without parent and child spans linking agents, a multi-agent failure is one flat trace and nobody can say which hop broke.
- Every handoff is a lossy interface. Sometimes the honest read of the results is that the system should have fewer agents.
The outbound side: was the delegation any good
When one agent hands work to another, the instruction it constructs is the entire input the receiving agent gets. Judging it is a concrete, scorable task:
- Completeness. Did the parent pass along the constraints it already knew? The budget cap, the account ID, the stated deadline, the fact that this is a read-only request. Dropped constraints are the most common delegation failure, and they are invisible from the subagent’s side, which had no way to know.
- Specificity. Is the deliverable named, or is it “look into this”? Vague delegation produces a subagent that does something adjacent and defensible.
- Recipient selection. In a routed system, was this the right specialist? A billing question sent to the returns agent gets a fluent, wrong answer.
- Context hygiene. Passing too much is also a failure. Dumping the whole conversation into a subagent’s context costs tokens and gives it room to act on something irrelevant.
A surprising share of failures blamed on model capability turn out to be context and harness problems instead, and in a multi-agent system the parent agent is the one assembling that context.
The inbound side: was the result usable
Score what came back against what the caller needed:
- Contract conformance. Schema, format, units, required fields. If the caller expected a list of IDs and got a paragraph describing them, the handoff failed however good the paragraph was.
- Groundedness. Is the returned content supported by what the subagent retrieved or observed, or did it summarize its way past a gap?
- Honest failure reporting. This deserves its own metric. A subagent that could not find the record and says so lets the caller recover. One that returns a plausible guess in the same shape as a real answer poisons everything downstream, and the caller cannot tell the two apart.
- Whether the caller used it. A parent agent that requests work and then ignores the response is a common and expensive pattern, and it shows up nowhere in a per-agent quality score.
Attribution, which is the hard part
A five-agent run produced a wrong answer. Which agent is at fault?
You cannot answer that without the call graph. The handoff has to be instrumented as a relationship, with parent and child spans carrying which agent ran, what instruction it received, what it returned, and in what terminal state. Flat logs from five agents give you five stories and no way to join them, which is why multi-agent work leans harder on the harness and its tracing than single-agent work does.
With the graph in place, a workable rule is to walk the trace forward and find the first hop where the input was sufficient and the output was not. That is the responsible agent. Everything downstream is a cascade, and scoring those agents on final outcome punishes them for a bad input. It cuts the other way too: an excellent subagent given a broken instruction looks like the failure. Score inputs and outputs at each boundary separately and most of the misattribution resolves itself.
The uncomfortable finding
Run this AI agent evaluation on a real system and it frequently says the same thing: the handoffs are where the quality is going, and there are too many of them. Each boundary is a lossy translation between two probabilistic components, so adding a specialist agent adds two interfaces and two more places to drop a constraint. Teams operating large numbers of long-running agents hit the same trade-off at scale, and the answer is sometimes a flatter design with one agent and more tools rather than a deeper hierarchy with better prompts at each level. Evaluating the interactions is how you get evidence for that call instead of arguing about architecture from taste.
FAQ
What is the difference between agent-to-agent evaluation and agent evaluation?
Agent evaluation asks whether an agent does its job: task completion, tool selection, trajectory quality, final output. It applies to a single agent as much as to one in a team. Agent-to-agent evaluation is the subset that only exists in multi-agent systems, covering the quality of what crosses the boundary between two agents in each direction. If your system has one agent, you need the first and not the second. We cover both of these evaluation types in our developer guide to AI agent evaluations (which is worth a read).
How do you evaluate a handoff between two agents?
Score it in both directions from the trace. Outbound, check whether the instruction was complete, specific, and sent to the right recipient. Inbound, check whether the response matched the expected contract, was grounded in what the subagent actually observed, and reported failure honestly when it failed. Then check whether the caller used the result at all.
Which agent do you blame when a multi-agent run fails?
Walk the call graph in order and find the first agent that received sufficient input and returned insufficient output. Agents after that point are reacting to bad input, and scoring them on the final outcome will send you to fix the wrong component.
Does agent-to-agent evaluation mean one agent judging another?
That phrasing gets used, but it is a different concept and it has its own name. An evaluator built as a tool-using agent rather than a single model call is the agent-as-a-judge pattern. Agent-to-agent evaluation as used here is about production agents working together and whether their collaboration holds up, not about who is doing the grading.
