AI agents pay in latency and context before useful work begins

Before an AI assistant can ask another agent for help, it has to introduce itself. Where is the counterpart? Which operations can it perform? Which protocol version does it understand? Is this a new session or a resumed one? None of these messages solves the user’s problem, but every one travels over a network, may be interpreted by a language model and sometimes fills a surprisingly expensive part of its working memory.[1]

Pranav Varshney benchmarked official SDK implementations of MCP, A2A and the now-frozen ACP protocol, separating cold starts, reconnects and metadata problems. Each experimental cell ran 50 times on loopback and with an emulated 50-millisecond round trip. ACP remains in the comparison because existing deployments persist after its merger into A2A.[1]

One introduction, three different conversations

An older MCP initialisation sequence required three network round trips in the tested cold-start configuration. A2A needed one. Under 50-millisecond network delay, measured handshake times were about 230 milliseconds for the legacy MCP path and 61 milliseconds for A2A. The difference is dominated by the count of messages that must go out and come back before useful work can start, rather than by extraordinary computational complexity.[1]

Crucially, the paper tracks protocol evolution. A 2026 MCP discovery-era revision reduced its initial exchange from three round trips to two in the authors’ scenario, while an explicitly pinned version could make a warm reconnect require no additional discovery round trip. A comparison that labels all MCP interactions “230 milliseconds” would therefore misrepresent the very improvement the research documents. Network conditions, transport and session reuse matter.[1]

The words on the menu can cost more than the meal

The capability catalogue creates a separate token cost. Measured descriptions used about 24–107 tokens per capability. At the high end, 200 capabilities occupy roughly 21,400 tokens—about 10.7% of a 200,000-token window, consistent with the paper’s rounded 11% example.[1]

The mechanism is easy to miss because capability discovery appears harmless: it is just descriptive text. Yet an assistant that repeatedly rereads sprawling inventories competes for context with the instructions, evidence and intermediate reasoning that actually matter. Worse, excessive advertising can make tool selection harder, because the model has to distinguish many overlapping names and descriptions. An agent platform’s information architecture becomes part of its compute economics.[1]

The architectural implication is to discover relevant capabilities in stages and reuse stable metadata when versions and permissions allow it. The benchmark identifies where overhead accumulates; the saving in a real application depends on its catalogue size, reuse pattern and task length.[1][2]

Latency and trust are entangled

Optimising a handshake is not merely deleting authentication or compatibility checks. Version negotiation and capability descriptions prevent agents from making nonsensical or unauthorised requests. A shorter connection that neglects identity, permission boundaries or changed interfaces can produce a larger downstream failure. The engineering challenge is deciding which assurances must be checked every time, which can be safely reused and which should be requested only when relevant.[1]

These controlled handshake measurements exclude most of an end-to-end task. A long model computation may dwarf connection latency, whereas a workflow built from many short-lived interactions can expose it repeatedly.[1]

Builders therefore have two budgets to watch before reasoning begins: network exchanges and the descriptions placed into model context. Reducing one does not automatically reduce the other.[1]

Report an error or suggest a correction