What Is Agent-To-Agent Evaluation?

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.

Start free

Build better agents with Arize

Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.

Get started View AX docs

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.

Subagent

A subagent is an agent that a parent agent starts to handle one bounded part of a task. It has its own context window and instructions.

Subagents are also called sub-agents or specialized agents. They often get a restricted tool set. The parent passes a task brief, the subagent works independently, and only its result returns to the parent. This keeps intermediate detail out of the parent’s context.

For example, a coding agent delegates “find every caller of parseInvoice” to a search subagent. The subagent reads 30 files in its own context and returns a 12-line list of callers. The parent’s context gains the list, not the 30 files.

Trace both agents. The parent trace should link to the subagent run so you can attribute cost and failures to the right agent. The Google ADK walkthrough on tracing multi-agent systems shows this in practice, and AI observability covers the broader picture.

A subagent only knows what its brief contains. Vague briefs produce confident but irrelevant results, and the parent cannot see reasoning it never received. To reduce this risk:

• Write narrow briefs: State the task, the scope, and what a finished result looks like.
• Require evidence: Ask the subagent to return the facts that support its answer.
• Verify before acting: Have the parent check the result before using it.

For setup details in a specific framework, see the framework’s own documentation, such as Claude Code sub-agents. Related coordination patterns are covered in agent orchestration and tool calling.

Agent handoff

An agent handoff is the transfer of an in-progress task from one agent to another, which then takes responsibility for the next steps.

Handoffs usually happen because the receiving agent has a capability, tool, or permission the first agent lacks. They also happen when a supervisor routes the task to an expert agent. A handoff differs from delegation in general. A supervisor assigning fresh work is delegation, but it is not necessarily a mid-task handoff.

A handoff is more than a message. Three things must survive the transfer, and you should check each one separately:

• Intent: The goal, the constraints, and the definition of “done” must arrive unchanged. A receiving agent that works from a paraphrased goal can complete the wrong task fluently. Compare the received goal with the original, not only with the sending agent’s summary.
• Context: The facts, evidence, and intermediate results gathered so far must arrive. With too little, the receiver repeats steps or asks the user again. With too much unfiltered history, it inherits stale or contradictory material. Inspect what was actually passed in the trace rather than assuming the full history traveled.
• Permission: The authority to act must stay correctly scoped. Credentials and approval scope belong to an identity and a task, not to whichever agent is speaking. Check which identity the receiving agent acts under and whether it matches the access control for agents policy for the task.

Permission checks matter most where a handoff crosses a boundary in a multi-agent system. A handoff must never quietly widen what the combined system is allowed to do.

How to evaluate a handoff

Evaluate each handoff at the point of transfer, not only at the final outcome. In an agent run evaluation, mark each handoff and score intent, context, and permission before you score the overall result.

For example, a run can succeed despite a broken handoff because the receiver recovered. Another run can fail because the goal drifted during a handoff. Only handoff-level checks tell you which case you are looking at.

For concrete examples, see Claude’s sub-agent documentation for delegating work to focused agents. Arize’s Google ADK tracing and evaluation walkthrough shows a traced handoff in a real framework.