What Is the Agent2Agent (A2A) Protocol?

What Is the Agent2Agent Protocol?

The Agent2Agent (A2A) Protocol is an open standard from Google for enabling autonomous AI agents to discover, negotiate with, and delegate tasks to each other across organizational and vendor boundaries. Where MCP standardizes how an agent reaches tools, A2A standardizes how agents reach other agents — defining capability cards (what an agent can do), task lifecycle (create, run, observe, complete), structured message-passing, and authentication. By 2026 A2A is the emerging interoperability layer for cross-vendor, cross-org multi-agent workflows.

Why It Matters in Production LLM and Agent Systems

Multi-agent systems are no longer research toys. In 2026 a single business workflow may span an OpenAI Agent for planning, a Claude-based research agent for evidence gathering, an internal Llama-3-powered SQL agent, and a third-party CRM agent owned by another company. Without a shared protocol, every pair of agents needs a custom integration, every handoff is a bespoke API contract, and every authentication boundary is a security surface to harden manually.

A2A solves the connector problem the same way HTTP solved web interop. The first production consequences are immediate. A platform team that exposes its support agent over A2A can be invoked by any A2A-compliant orchestrator without writing client code. A security team gains a single boundary — every cross-agent message goes through the A2A endpoint, where it can be logged, authorized, and audited. A product lead can compose workflows that mix internal and third-party agents without legal having to negotiate per-pair integration contracts.

The new failure modes are real. A delegated agent silently underperforms — its TaskCompletion is 0.6 but the calling agent has no visibility into the score. Capability descriptions drift away from actual behavior, and the orchestrator picks a “good on paper” sub-agent that fails on the live workload. Authentication tokens leak across an A2A boundary. Cost attribution becomes a tracing problem: which agent paid for which token? In 2026 enterprise stacks where a request might cross five A2A hops, end-to-end observability stops being optional.

How FutureAGI Handles A2A

FutureAGI’s approach is to instrument A2A at the protocol layer so every cross-agent handoff is a queryable OTel span — not a black box. The traceAI-a2a integration (Python and TypeScript) wraps the A2A SDK: capability lookups, task creation, message exchanges, and lifecycle transitions all emit spans with agent.trajectory.step, the calling and called agent ids, and the task id, so the calling agent’s trace and the called agent’s trace can be stitched together by trace_id.

That stitching is the unlock. A team running a multi-agent workflow where Agent A delegates a sub-task to Agent B can now answer “did Agent B finish the sub-task correctly?” from inside Agent A’s trace view. TaskCompletion runs against the sub-task’s transcript; TrajectoryScore aggregates across the whole cross-agent trajectory; ReasoningQuality scores the planner agent’s choice to delegate at all.

Concretely: an enterprise team builds an order-fulfillment workflow where a planner agent delegates inventory queries to an internal warehouse agent and shipping queries to a third-party logistics agent over A2A. Each cross-agent call lands as a traceAI-a2a span. The team builds a dashboard showing per-counterparty TaskCompletion, p99 latency, and cost attribution. When the third-party logistics agent’s TaskCompletion drops from 0.91 to 0.74 after a vendor model upgrade, FutureAGI flags it before the regression reaches end users, and the planner can be reconfigured via the Agent Command Center to fall back to a backup logistics agent. Unlike Google’s reference A2A SDK alone, this gives evaluators on the cross-agent boundary, not just protocol compliance.

How to Measure or Detect It

A2A is observed at the cross-agent boundary; key signals:

• TaskCompletion per delegated sub-task: the called agent’s job-success score, surfaced inside the caller’s trace.
• TrajectoryScore: aggregates step-level scores across the whole cross-agent trajectory.
• agent.trajectory.step (OTel attribute): tags each A2A handoff so you can slice dashboards by hop count.
• A2A round-trip latency: per (caller, called) pair, distinct from in-process tool latency.
• Capability-mismatch rate: percent of A2A tasks where the called agent’s capability card claimed support but the task failed — leading indicator of capability drift.
• Cross-agent cost attribution: tokens × $ summed per called agent, surfaced in the trace’s cost breakdown.

Minimal Python:

from fi.evals import TaskCompletion, TrajectoryScore

tc = TaskCompletion()
ts = TrajectoryScore()

print(tc.evaluate(input=delegated_subtask, trajectory=called_agent_trace).score)
print(ts.evaluate(trajectory=full_cross_agent_trace).score)

Common Mistakes

• Treating A2A as a transport. It is a protocol with capability negotiation, lifecycle, and auth — designing it as raw RPC misses the point and breaks orchestrator compatibility.
• No per-counterparty SLA tracking. When a downstream A2A agent degrades, you need per-counterparty TaskCompletion to catch it, not aggregate metrics.
• Skipping eval on the called-agent side. End-to-end success hides which hop failed; instrument both sides via traceAI.
• Confusing A2A with MCP. A2A is agent-to-agent; MCP is tool-to-agent. Mixing them up distorts your architecture.
• No fallback for third-party A2A agents. A vendor outage takes down your workflow unless the gateway can route the delegation to a backup; configure model and agent fallback in the Command Center.