Two protocols out of Google, both branded "agent," both announced within months of each other. So the question keeps coming up: Google agent-to-agent protocol vs agent client protocol — which one wins? The honest answer is that they're not competing at all. The Agent2Agent protocol (A2A) and the Agent Client Protocol (ACP) solve different cuts of the same problem, they're explicitly designed to coexist, and both quietly depend on a layer underneath that almost nobody designing agent systems talks about: the transport.
Here's the one-sentence version before we dig in. A2A is about discovery and inter-agent collaboration — how one agent finds out what another agent can do, and how it hands that agent a task. ACP is about the client–agent boundary — how a client authenticates to an agent, opens a session, and drives its tool-call loop. Different cuts, same stack. Let's look at each, then at the layer they both assume.
Agent-to-Agent Protocol vs Agent Client Protocol: Same Company, Two Different Jobs
If you've only skimmed the announcements, both look like "a protocol for agents." The difference only shows up when you look at what each one standardizes on the wire.
A2A: the discovery card and the task
A2A is Google's open protocol for agent-to-agent collaboration. Its centerpiece is the Agent Card: a JSON document every A2A server exposes at a well-known path like /.well-known/agent-card.json. The card is the agent's service description — name, what it does, its skills, its authentication requirements. It exists so another agent can answer "who can do this, and how do I talk to them?" without a human in the loop.
{
"name": "Invoice Agent",
"description": "Extracts fields from uploaded invoices",
"url": "https://agent.example.com/a2a",
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": false
},
"authentication": {
"schemes": ["bearer"]
},
"skills": [
{
"id": "parse-invoice",
"name": "Parse invoice",
"description": "Takes a PDF, returns structured fields",
"tags": ["finance", "documents"]
}
]
}
Fetching a card is just an HTTP GET:
curl https://agent.example.com/.well-known/agent-card.json
Once a caller has the card, A2A defines the task lifecycle over JSON-RPC 2.0: task/send to start work, task/get to poll, task/cancel to stop, message/send for streaming updates. Tasks can run for seconds or days, and the protocol explicitly supports long-running work with streaming and push notifications. That's a real strength: A2A is built for agents that do work asynchronously, not just answer questions.
ACP: the client session and the auth
ACP standardizes the other boundary. It's the protocol between a client — an editor, a CLI, an app, or another agent acting as a client — and a single agent. Where A2A is about discovery and handoff, ACP is about the mechanics of a working session:
-
authenticate— prove who you are, if the agent requires it -
session/new— open a session -
session/load— resume an existing session -
session/cancel— interrupt processing
That message flow is the whole point. ACP gives you a standard way to attach a client to an agent, keep state across turns, and stream results back — which is why you see it in tools like Gemini CLI and the AI SDK ecosystem. It's the "LSP moment" argument applied to coding agents: one protocol so any client can drive any agent, instead of every editor reimplementing the integration.
Where the two protocols meet
The key realization is that A2A and ACP aren't redundant — they compose.
| A2A (Agent2Agent) | ACP (Agent Client Protocol) | |
|---|---|---|
| Boundary | agent ↔ agent | client ↔ agent |
| Discovery | Agent Card, well-known endpoint | n/a (client is pointed at the agent) |
| Core state | task lifecycle | session lifecycle |
| Auth | declared in the card | negotiated per session |
| Typical caller | another agent | editor, CLI, app, or agent-as-client |
A human using an IDE is an ACP client. An autonomous agent that needs a task done by a specialist is an A2A caller. Nothing stops the same process from being both — and nothing stops an A2A agent from acting as an ACP client when it talks to another system. They're layers of the same stack, not competitors for the same slot.
The layer both of them assume: transport
Here's the part that gets skipped in most "A2A vs ACP" write-ups. Both protocols are application-layer. Both assume a reachable endpoint: a stable URL, an open path for requests, a server that can receive a connection. A2A's spec says servers MUST expose a card; ACP's flow assumes the client can actually reach the agent to authenticate.
That assumption is exactly what breaks in real agent deployments. Agents run on laptops, in CI runners, on edge boxes behind carrier-grade NAT, on cloud VMs with rotating IPs. There is no inbound path. The protocol is fine — the transport is missing. You can't fetch a card from an agent that has no reachable address.
This is the gap an overlay network fills: it gives every agent a permanent virtual address that survives restarts and IP changes, encrypted tunnels that traverse NAT without opening a single port, and an explicit trust model so "reachable" and "trusted" stay decoupled. Protocols like A2A and ACP can run over that substrate exactly as they run over the public internet — the agent card is served from a stable overlay address, ACP sessions ride the same encrypted tunnel, and neither protocol has to care that the underlying IP rotated at 3 a.m.
That's the design of Pilot Protocol's docs on agent networking: an open-source overlay for AI agents — permanent addresses, NAT traversal, encrypted UDP tunnels — with 243k+ agents already on the network. It doesn't replace A2A or ACP; it carries them. Think of it as the difference between having a phone number (the protocol) and having a working phone line to anywhere in the world (the overlay).
Running A2A and ACP over an overlay, in practice
Concretely, the loop looks like this. Install the daemon on each agent host:
curl -fsSL https://pilotprotocol.network/install.sh | sh
Agents get an address, discover each other, and establish trust with a handshake:
pilotctl handshake invoice-agent "task handoff for invoice parsing"
pilotctl send-message invoice-agent --data '{"card": true}'
From there, the A2A card is served from the overlay address, and an ACP session between a client and an agent runs over the same tunnel — no port forwarding, no public IP, no webhook relay to babysit. The protocol layer stays exactly as specified; only the transport underneath changed.
Bottom line
Stop asking which Google protocol wins — they don't compete. A2A owns discovery and inter-agent tasks; ACP owns the client session and auth. Both are application-layer, and both assume a transport that most agent deployments don't actually have. If your agents can't reach each other, the protocol isn't your problem — the transport is. Fix that layer first.
Get started: curl -fsSL https://pilotprotocol.network/install.sh | sh, then read the docs at pilotprotocol.network/docs.
Top comments (0)