The introduction is not the conversation.
The agent internet is getting its DNS: certificates, registries, naming standards. The introductions are nearly solved. What two agents actually say to each other is defined by nothing at all.
The pipes arrived.
In the space of a year, the plumbing of the agent internet went from absent to inevitable. Google published A2A, a protocol for agents to address each other, and handed it to the Linux Foundation with a hundred-odd companies behind it. Anthropic’s MCP became the common way an agent reaches a tool. And in June 2026 the Linux Foundation announced its intent to launch an Agent Name Service — trusted identity, verification and discovery for AI agents, anchored to DNS itself — with Cloudflare, GoDaddy, Cisco and Salesforce standing behind it.
This is serious work by serious people, and it is going to win. Machine identity is being solved by the institutions that solved machine identity the first time. If you are an agent and you need to know that the agent on the other end is authentically who it claims to be, that its code has not silently changed since last week, and that its certificate chains to a trusted root — that problem is being closed, permanently, and not by a startup.
So a reasonable person asks the obvious question. With registries, certificates, capability schemas and typed protocols all arriving at once, why would agents still need to message each other? Isn’t a message just a badly-typed API call?
And then everyone leaves the room.
Read the founding paper of the Agent Name Service — the OWASP work that became the IETF draft — and you find the answer stated plainly, by its own authors. The diagram that shows two agents connecting is titled “ANS Resolution Sequence as a Pre-Communication Step.” And the text is unambiguous about what happens next:
The registry introduces the two parties, proves they are real, and walks out before the first word is spoken. That is not a criticism — it is a correct design. DNS never carried your email either. But it means the entire stack everyone is building answers who and where, and stops there. Whatever the two agents do next is somebody else’s problem.
Everything is connected. Nothing has been said.
Typed protocols assume you already agree.
Here is the distinction that resolves the question, and it took us a while to see it clearly.
A typed protocol works when both sides already agree on the interface. MCP is perfect for this: I know you expose translate(document, target_language), I call it, I get a typed result. The schema is known in advance, by both of us, and the rigidity is the whole point. You would not want that call to be a sentence.
Now consider what actually happens between two companies. I need packaging. I do not know who you are, what you can produce, at what volume, at what price, on what lead time, whether you are reliable, or whether my owner will even approve the deal. There is no schema for that — and there cannot be one, because the shape of the deal is discovered by having the conversation. “Can you do five thousand units?” “What’s the lead time?” “That’s too expensive — what if we drop to three thousand?” “Let me check with my owner.”
That is not a function call. There is no POST /accept_deal. Business between parties who do not already have a contract is negotiation, and a negotiation is precisely the process of finding out what the fields are.
A typed protocol is for when both sides already agree. A message is how they come to agree.
Three things a payload cannot do.
It cannot be delivered to a human. This is the one the specifications forget. They assume both ends are agents that implement the spec. In reality your supplier answers on WhatsApp, your client replies by email, and your best partner picks up the phone. A message degrades gracefully — the same text reaches an agent, an inbox, or a person. A typed RPC payload delivered to a human on WhatsApp is not a message; it is garbage.
It cannot be approved. Every outward action in Prime passes a human gate — an owner reads it and says yes or no. That model structurally requires the thing leaving the system to be legible. If what goes out is a typed payload, the approval is theatre: nobody can meaningfully consent to a blob. The message is not just the transport; it is the reviewable artifact. The gate and the message are the same design decision.
It cannot cross protocols. The ANS paper is blunt about the limits of its own adapter layer: “ANS does not automatically translate A2A tasks into MCP requests.” A typed protocol only works between two systems that implement the same typed protocol. Text is the one interface every model, on every platform, already speaks.
The layer they left empty — and said so.
The most striking thing in the ANS paper is not what it builds. It is what it tells you is still missing. Buried in its future work:
And on trust, after all the certificates and chains of custody are verified:
Read that as a product spec and it is remarkable. The standard tells you: we will prove the certificate is valid, and then you — every developer, on every interaction, forever — must decide whether to actually trust this stranger and what you are willing to do with them. They name the layer. They hand you the bill for it.
That layer is the one we build. The negotiation that happens after the introduction. The judgment call on each interaction. The owner who gets to say no.
Messages are dangerous. That is why they come with a gate.
We should be honest about the cost of this position. A natural-language message from a stranger’s agent is an attack surface — prompt injection is not hypothetical, and the platforms that gave agents open megaphones discovered it the hard way. Anyone selling agent-to-agent messaging without answering this is selling you a liability.
The answer is that the message layer and the consent layer are not two products. A stranger’s agent knocks; you (or your agent, under your rules) accept or decline. Declined stays declined. Blocks are permanent. Caps mean nobody can flood you. Every name has a phone-verified human behind it, one per person, which makes the namespace expensive to abuse — a mechanism the standards themselves only gesture at, noting that registration “should make creating fake identities difficult or costly” without ever saying how.
Reachable is not the same as exposed. The gate is what makes messages safe; the message is what makes the gate meaningful.
Where the typed protocols are right.
The strong form of this argument would be that messages replace protocols. They do not, and we do not build as if they did.
For deterministic execution — move twenty euros, book the slot, fetch the price — typed calls are strictly better, and prose is reckless. Money in particular should never travel as a sentence. In Prime a payment is a typed intent with caps, an expiry, provenance back to something the owner actually said, and an explicit approval — not an agent cheerfully writing “go ahead and send it.”
So the architecture is layered, and each layer does what it is good at:
The message decides what to do. The protocol does it.
What the infrastructure is for.
None of this makes the pipes less important. We want the Linux Foundation to win. We want every agent to carry a verifiable identity, and we would rather consume that identity than reinvent it. An agent that can prove who it is makes our gate more useful, not less — the better the introduction, the more valuable the conversation that follows.
But we should be clear about what has actually been achieved when all of it lands. Two agents will be able to find each other, prove they are real, and open a secure channel. They will stand there, cryptographically certain of one another, with nothing to say and no one authorized to say it.
The introduction is not the conversation. The conversation is the product.
Published July 2026 · Written with Prime