Measuring the Setup Cost of Agent-to-Agent Communication

Run the numbers at an emulated 50 ms round-trip time and the gap is stark: a legacy MCP handshake takes three round trips and 230 ms, versus one round trip and 61.0 ms for A2A ¹. For teams building a multi-agent system, that gap may matter when agents exchange small messages or reconnect often. But the headline number is not a protocol ranking you can apply blindly. It's a measurement from one benchmark, under one set of conditions.

The study defines a handshake as the steps before the first useful message: locating a counterpart, learning what it can do, and establishing a session ¹. That boundary is useful precisely because it's narrow. It turns “protocol overhead”, a phrase vague enough to argue about for an hour, into something you can instrument in your own deployment.

What counts as agent handshake setup cost

A handshake can involve multiple exchanges, metadata describing what a counterpart can do, and establishing a session ¹. The study tracks four dimensions: request round trips, per-phase latency, wire bytes, and token cost ¹.

Each answers a different question:

• Round trips: how many network exchanges setup requires.
• Per-phase latency: where in the handshake time goes.
• Wire bytes: how much data crosses the wire.
• Token cost: how many tokens an LLM uses to read a counterpart's capability metadata ¹.

Splitting these matters because network delay and metadata-processing cost are different things to measure. A protocol might need only one round trip but still ship a large capability description. As an example to test in your own system, a warm, reused session might avoid a network exchange while the agent still has to process capability metadata. Measuring the dimensions separately helps diagnose which cost is affecting your system ¹.

How the benchmark is structured

The study compares MCP's 2025 initialize and 2026 discover eras, A2A, and ACP, using each protocol's official SDK ¹. It tests four scenarios per protocol: cold start, warm repeat, capability mismatch, and degraded metadata. Each scenario-environment cell has 50 runs, across loopback and an emulated 50 ms RTT ¹.

That design avoids a trap: a cold start is not the same workload as a repeat connection, and a capability mismatch is not the same condition as a successful match. Blend conditions into one average and you can lose information a platform team needs.

The abstract excerpt does not specify SDK versions, hardware, implementation details, or statistical uncertainty ¹. It also does not list the full per-phase latency, wire-byte, and token-cost results for every protocol-scenario-environment combination ¹. Treat the reported figures as a starting point for your own measurement, not a substitute for testing under your actual conditions.

Agent protocol handshake latency: what the numbers show

The paper identifies round-trip count as the main driver of handshake cost ¹. The clearest illustration: at 50 ms emulated RTT, legacy MCP's three round trips take 230 ms; A2A's single round trip takes 61.0 ms ¹.

MCP's revisions provide another comparison. The 2026 discover-era handshake takes two round trips rather than three, and era pinning allows a warm reconnect to take zero round trips ¹. Setup cost, in other words, can depend on how a protocol is used as well as which protocol you pick.

Resist turning this into a league table. The abstract excerpt gives selected comparisons, not full results for every protocol and workload ¹. It doesn't report loopback comparisons across each scenario or identify which handshake phase consumes the most latency in each case ¹.

Analysis: Round-trip count may matter most when setup repeats over a path with meaningful latency. In a long-lived session, the cold handshake may be small relative to total traffic; in a system doing frequent short exchanges, repeated setup may matter more. These are hypotheses to test against your traffic pattern, not conclusions established by the headline figures.

When agent discovery metadata eats your context budget

Setup has a second cost separate from network delay: context. When an LLM reads a counterpart's capability metadata, those tokens are used before the agent reads its task. The study reports 24–107 tokens per capability; for a counterpart with 200 capabilities, it estimates 11% of a 200,000-token context window is used before the agent reads its task ¹.

That makes agent discovery and session setup an architecture question as well as a networking one. A catalog can arrive quickly and still use context. The abstract excerpt doesn't detail how each protocol represents or processes metadata, so treat the token figures as a reason to inspect your own metadata shape, not as a precise forecast for your implementation ¹.

Analysis: If your system repeatedly exposes large capability catalogs, check whether agents need the whole catalog every time. Filtering to the task at hand, disclosing metadata in stages, or caching it across turns are possible approaches to test. Filtering can hide a capability you need; staged disclosure adds decision logic; caching can become stale. The study makes metadata cost worth measuring, but does not establish which approach works best for a particular system. For a related context-budget problem, see our look at skill library retrieval for LLM agents.

Building a comparison matrix for your workload

A fair comparison tests conditions that may change setup cost rather than relying on one blended average. The following is a practical test matrix inspired by the study's scenario and environment design ¹:

Dimension	Conditions to compare	What it reveals
Session state	Cold start vs. warm repeat	Whether recurring interactions can reuse setup
Capability result	Match vs. mismatch	How setup differs when discovery succeeds or encounters a mismatch
Metadata	Normal vs. degraded	Sensitivity to degraded metadata
Network	Local baseline vs. representative RTT	How much network delay changes the result

Analysis: For short exchanges, weigh setup time against the useful work it supports. Smaller payloads and more frequent reconnects may make setup cost more consequential. For long-lived sessions, measure warm reconnects separately; the paper's zero-round-trip figure applies to warm reconnects with MCP era pinning ¹. For broad capability catalogs, track context consumption alongside latency and bytes.

The useful question isn't “which protocol is fastest.” It's which setup path costs least for your interaction pattern, network, and metadata conditions. A protocol with a better cold-start result may be a poor fit if your system mostly reuses warm sessions, or if metadata creates a constraint that latency does not capture.

What to measure next

Instrument the path to the first useful message, not just the request you care about. At minimum, capture round-trip count, per-phase latency, wire bytes, and tokens consumed during discovery and setup, the four dimensions the study tracks ¹. Break results out by cold start, warm repeat, capability mismatch, and degraded metadata rather than averaging them together ¹.

Test both a local baseline and a controlled network condition. The benchmark's loopback and emulated 50 ms RTT provide two reference points to reproduce or adapt ¹. Then rerun the comparison with your own SDK versions, metadata shape, network path, and connection frequency. The abstract excerpt does not report results for those deployment-specific conditions ¹.

The authors say they are releasing the benchmark harness, raw data, and analysis ¹. Those materials may be useful before you write your own benchmark from scratch.

Analysis: Use your measurements to decide what's worth fixing: a protocol change, a cache, capability filtering, or longer-lived sessions. Test each option against the same workload and report latency and context cost together. A fix that trims round trips won't necessarily address metadata overhead; a cache that helps warm paths won't necessarily affect cold starts. Setup cost is also only one line in the bill, and elastic GPU capacity won't lower agent costs by itself, so keep it next to your other cost measurements.

What's settled, and what isn't

Two findings are supported by the reported results. Round-trip count can dominate handshake latency under the tested emulated RTT: the legacy MCP versus A2A comparison makes that concrete ¹. Capability metadata can also use a meaningful share of context when a counterpart has a large capability inventory; the paper's example estimates 11% for 200 capabilities and a 200,000-token context window ¹.

What's not established by the abstract excerpt: full per-phase latency, wire-byte, and token-cost results across every protocol, scenario, and environment, or how these differences translate into deployment economics for particular message sizes and connection frequencies ¹.

Treat handshake cost as measurable, not assumed. Reproduce the comparison against your own workload, and don't let one headline number stand in for a protocol decision. Before choosing a protocol or building a cache layer, run cold-start, warm-repeat, mismatch, and degraded-metadata tests against your own traffic, then see which measurements change.