"Agent-to-agent" is currently doing the work of three different ideas, and the conflation is starting to be a problem. If you’re shipping anything in the agent stack this year, the cleanest single thing you can do is decide which one you mean and stop using the phrase the other ways.
The mix-up isn’t malicious. The term has surface meaning — "agents talking to each other" — that fits any picture with two boxes and an arrow between them. So you’ll see "agent-to-agent" attached to three structurally different things, and it pays to keep them apart.
Three things called "agent-to-agent" — only one is a wire protocol
The first is two assistants in a notebook. A research script spins up two LLM instances, gives them roles ("planner" and "critic"), and lets them exchange messages in a loop. There’s no network. They share Python globals. The conversation is just a list of dicts on the same machine. People genuinely call this "agent-to-agent" — and as a research framing it’s fine — but there’s no protocol, no transport, no addressing. Two functions calling each other in turn. Useful, common, not what the protocol crowd means.
The second is an LLM with tools. The model decides to call a function (search, browse, "send email"), the function runs, the result comes back, the model continues. Most products that describe themselves as "agentic" are doing this. Some call it "agent-to-agent" because the tool happens to be backed by another LLM service somewhere. But the wire is just RPC — the same RPC you’d use without any model in the picture. The tool doesn’t know it’s being called by an agent. There’s no agent-shaped conversation between the two parties.
The third is the actual thing: a protocol where two independently-running programs, each with their own state and authentication, address each other directly and exchange tasks they can act on. Not "the LLM calls a function." Not "two LLMs share Python locals." A wire format. An identity. A handshake. Asynchronous task transitions where each side keeps its own ledger. This is the part most people don’t have yet, even when the marketing page uses the phrase.
What the wire actually carries
Strip the term out and look at what an agent-to-agent protocol actually has to specify — and the list is what distinguishes it from RPC.
Identity. Each agent needs an address that doesn’t change when its hosting provider does. Not a hostname (you’ll change hosting), not an API key (you’ll rotate it), not an email (it isn’t parseable). A decentralized identifier is where most current designs converge. We use agent:retransfer.one/u/<uuid> for the recipient field in a transfer; that’s an identifier the sender knows belongs to one party regardless of where they happen to be served from this week.
Capability advertisement. Before a sender does anything expensive, it should be able to read — in one cheap GET — what the receiver can actually do. Whether it streams, whether it does push notifications, whether it keeps state-transition history. We publish this at /.well-known/agent-card.json because that’s where the A2A spec puts it; the values inside (streaming: false, pushNotifications: true, stateTransitionHistory: false) tell the caller which integration shapes are open before they spend a request finding out the hard way.
A signed wire. If two agents from different providers are exchanging actionable tasks, the receiver needs to know the sender is who they claim to be — without a trusted intermediary. HMAC over a canonical string keyed by a shared secret is the minimum bar. The signature has to bind enough context (timestamp, delivery id, body) that yesterday’s request can’t be replayed as today’s, and that a signature lifted off one call can’t be pasted onto another.
An async story. Real agent flows aren’t synchronous request-response. A task gets accepted, runs for minutes, fails, retries, eventually lands. The protocol has to model that — state callbacks, push notifications, polling — pick one, but the question can’t be ignored.
That’s the bar. If a system has all four, it’s doing agent-to-agent. If it only has the first or just the last, it’s something else under a confusing name.
"Agentic" and "agent-to-agent" aren’t the same axis
The cleanest way to keep these straight: "agentic" is about who’s holding the steering wheel, and "agent-to-agent" is about how two cars find each other on the road. They’re orthogonal.
A perfectly agentic system — a model with full tool access, planning loops, self-correction — can be entirely in-process. No wire, no second party, no protocol. Everything inside one runtime, behind one auth scope. Very agentic. Not agent-to-agent in any technical sense.
The reverse also exists. Two scripts with no models anywhere can speak an agent-to-agent protocol if both publish AgentCards, sign their requests, and exchange tasks asynchronously. Not very agentic — they’re deterministic programs — but the wire is exactly the wire the spec describes.
This matters because the engineering work is different. Making a system agentic is mostly a model-and-prompt question. Making a system agent-to-agent is a transport question — identity, signing, async semantics, capability discovery. They live in different parts of the codebase, and conflating them means you keep solving the wrong problem at the wrong altitude.
"Agentic" is who’s driving. "Agent-to-agent" is how two cars find each other on the road. Don’t confuse the axes.
What this means for the next year
Most products will get agentic before they get agent-to-agent, and that’s reasonable. Agentic is a UX choice you can make inside your own walls. Agent-to-agent requires a public-facing wire format and an identity that other providers can consume — a much more committing shape to take.
The category to watch is the quiet middle: products that go agent-to-agent without leaning hard on being agentic. A signed wire and a stable, DID-shaped identity is useful even when both ends are deterministic. That’s where transfer, payments, identity verification, and most operational tooling will land. The flashy demos will keep being agentic-in-process. The plumbing that makes those demos composable across providers will be agent-to-agent, often with no LLM anywhere on the receiving side.
The thing not to do is keep using the same phrase for all three.