The Agent Communication Problem We’re Not Talking About

Why agent-to-agent messaging will run on email and SMS for the next decade — and why we should design for that instead of pretending otherwise

The narrative everyone’s building for vs. the reality most agents will actually live in. Clean A2A endpoints exist, but the long tail of counterparties — suppliers, clinics, contractors, brokers, insurers — will reach agents only through messaging channels for years

Every protocol working group right now is building toward the same future: every organization exposes a clean A2A-compatible HTTPS endpoint, agents discover each other through registries, and machine-to-machine traffic flows over structured RPC. It’s a beautiful future. It’s also not the one we’re going to live in for the next ten years.

Here’s the inconvenient truth: most agent-to-agent communication is going to happen over messaging channels — email, SMS, WhatsApp, eventually richer ones — because that’s where the counterparties already are. And messaging channels, as currently designed, are catastrophically wrong for agent traffic.

This is the gap I want to talk about — as a design problem the community needs to think about together.

The fallback problem nobody plans for

Consider a realistic scenario in 2027. A mid-market manufacturer deploys an AI agent to handle supplier coordination. The agent needs to confirm delivery dates with 200 suppliers — many of whom are 15-person regional businesses running on QuickBooks and email. None of them have an A2A endpoint. None of them will, ever, because the cost of building and maintaining one exceeds the value of automating their inbound communication.

What happens? The manufacturer’s agent sends… an email. To *orders@supplierco.com*. The supplier’s agent (if they have one) parses the email with a language model, extracts the structured intent, drafts a reply, and sends it back. Both sides are doing brittle, expensive, non-deterministic work to extract structure from a substrate that was designed for humans typing prose.

This isn’t a hypothetical. This is happening today, badly. And it’ll happen at vastly larger scale as agents proliferate.

The pattern repeats anywhere the counterparty distribution has a long tail of less-technical organizations — which is most of the economy. Healthcare prior auth, construction subcontractor coordination, legal discovery, procurement, international trade, insurance claims. We can wish this away by saying “everyone will have APIs eventually.” We’ve been saying that since EDI in the 1980s. Email is still the universal API for business communication forty years later. Agents won’t change that overnight; they’ll inherit it.

There are also reasons messaging will persist that protocol designers tend to underweight. In regulated industries — healthcare, finance, legal — email is the audit trail. It’s retained, discoverable, and regulator-familiar in ways APIs often aren’t. And in plenty of business workflows, friction is leverage: the slow side of an insurance claim or a procurement dispute often wants the ambiguity and human review, because it gives them room to maneuver. Messaging accommodates this naturally. APIs don’t. These aren’t bugs to be eliminated; they’re features of how business actually works.

Not all messaging is created equal

Before going further, a distinction worth making. “Messaging” covers a gradient of substrates with very different properties:

Not all messaging is created equal. Human inboxes are the hostile end of the spectrum but reach the most counterparties. Webhooks and APIs are agent-friendly but reach almost no one. A real protocol has to span all three.

Human inboxes (Gmail, Outlook, consumer SMS) — the hostile end. These are designed for human reading, monetized through attention, and policed by spam filters that treat automation as adversarial by default. Most of the long tail of business counterparties is reachable only here.

Business messaging APIs (WhatsApp Business, Twilio, Slack APIs, RCS) — the constrained-but-permissive middle. Already structured to some degree, already authenticated at the channel level, already designed for programmatic use. Easier substrate to build on, but reaches a narrower set of counterparties.

Webhooks and native APIs — the agent-friendly end. Already structured, already authenticated, but only available where the counterparty has built integration. The whole problem is that this layer doesn’t reach the long tail.

A real protocol has to work across all three, because the choice of channel isn’t ours to make — it’s whatever the recipient supports. Some of the design work is hardest at the human-inbox end, where every other constraint in this post hits at once.

Why human messaging breaks agent semantics

Email and SMS were designed for humans communicating in prose. The mismatch with agent traffic shows up in concrete ways:

No structured payload. Agents need to exchange typed data — purchase orders, scheduling proposals, status updates. Today they encode this as natural language and parse it back out. This is lossy, expensive, and non-deterministic. Two LLMs negotiating delivery dates over email burn tokens reconstructing structure that should have been first-class.

Weak identity. DKIM and SPF prove that a domain authorized a message. They prove nothing about which agent sent it, what it’s authorized to do, or whether you should trust it. When my agent receives a message claiming to be from “the procurement agent at AcmeCorp,” I have no cryptographic basis for that claim beyond “it came from acmecorp.com somehow.”

No request/response correlation. HTTP has correlation IDs and stateless semantics. Email has reply chains, which work for humans and break for machines. If my agent sends 50 parallel queries and gets 50 replies, matching them up is guesswork.

No delivery semantics. Did my message arrive? Was it processed? Did the receiving agent reject it because of a capability mismatch, a policy violation, or a transient error? Email’s bounce semantics are designed for “human typed wrong address,” not “agent rejected request because rate limit exceeded.”

No capability negotiation. When two HTTPS APIs talk, they can negotiate auth, content types, versions. When two agents talk over email, there’s no handshake. Each side is guessing about the other’s capabilities.

Hostile gatekeepers. This is the existential one, and it deserves its own framing. The agent economy is going to be built on top of infrastructure run by a small number of mailbox providers — Google, Microsoft, Apple — whose entire business model treats automation as a threat to be filtered out. Spam filters, sender reputation systems, deliverability scoring: all of it is designed to make programmatic messaging hard. They are not going to relax these defenses just because someone’s agents want to talk to each other. Any protocol that ignores this constraint will be killed in production by infrastructure it doesn’t control. Adoption isn’t just a technical problem; it’s a coordination problem with the providers who decide whether agent traffic gets delivered at all.

Each of these is solvable. None of them are solved.

What a real agent messaging protocol needs

If we accept that messaging substrates will carry agent traffic, the design question becomes: what does messaging need to grow up into? Not a clean-sheet replacement, but a layer that turns existing substrates into reliable agent transports without breaking them for humans.

Six pieces of plumbing, all of which have analogs in well-designed protocols we already have:

Verifiable agent identity. Every message needs to prove not just which company sent it, but which specific agent — and that agent’s authority to act. Today, an email from *procurement@acmecorp.com* could be a human, an automated system, or any of fifty different agents the company runs; the receiver has no way to tell. A real protocol gives each agent its own signed identity that travels with every message and is independently verifiable, separate from the domain it sent from. The cryptographic primitives for this already exist — they’re the same ideas that power modern API authentication.

Structured payloads. Today, when two agents communicate over email, both sides burn compute writing prose and parsing it back into structure. The sending agent generates “Hi, can you confirm delivery of order #4471 by Friday?” The receiving agent runs a language model to extract {order_id: 4471, action: confirm_delivery, deadline: “Friday”}. This is absurd — we’re paying LLMs to encode and decode information that should have been structured to begin with. A real protocol carries typed data alongside the human-readable version, so machines read structure and humans (or older systems) still see something sensible. The technology to do this inside email already exists; nobody’s standardized it for agent use.

The current state vs. what messaging-based agent traffic should look like. Today, both sides burn compute on prose round-trips. A real protocol carries signed identity, structured payload, and a human-readable fallback in the same envelope — typed and verifiable for agents, still readable for humans and legacy systems.

Capability tokens. Scoped, signed authorizations that travel with messages. “This agent is authorized to query inventory but not to place orders, expires in 60 seconds, max spend $10.” The cryptographic plumbing is well-understood. The harder problem is the policy framework that decides which tokens are valid for which counterparties — this is where federation gets interesting.

Request/response semantics. Native correlation IDs. Idempotency keys. Explicit accept/reject semantics layered on top of the transport. Standardized error codes for things like “capability mismatch,” “rate limit,” “policy violation.” Most of this is borrowable from existing API and messaging protocols; it just needs to be specified for the agent-over-messaging case.

Delivery and processing receipts. Distinguish between “message accepted by transport,” “message received by recipient,” “message processed by recipient agent,” and “message rejected with reason.” Email already has read receipts (universally ignored) and bounces (semantically overloaded). We need clean, structured equivalents.

Channel-agnostic transport. The protocol should work over email, SMS, WhatsApp Business API, webhooks — whichever channel the recipient supports. Discovery declares channel preferences; senders pick. Agent A sending to Agent B doesn’t care whether the bytes traveled over SMTP or HTTPS, only that the semantics arrived intact.

None of these are research problems. They’re engineering and standardization problems. The pieces exist; nobody’s assembled them coherently for the messaging-as-agent-transport use case.

What this is not

Worth being explicit, because the easy critiques are predictable.

This is not an argument against APIs, against A2A, or against clean HTTPS-native protocols. Those are the right tools for the right problems, and where counterparties have them, agents should use them. This is an argument that in the messy middle of the economy — where most of the actual counterparties live — messaging is the transport we already have. Pretending otherwise just pushes the complexity into LLM prompts and brittle ad-hoc parsers, which is what’s happening today.

Nor is this an argument that messaging is better than native protocols. It’s worse on most axes. The point is only that it’s what’s there, and refusing to design for it doesn’t make it go away.

The harder questions

Designing the wire protocol is the easy part. The harder questions are the ones that determine whether this gets adopted:

Who issues agent identities, and who attests to them? A spam-resistant agent network needs trust roots. Are they federated, like the certificate authorities that secure the web? Decentralized? Anchored to existing organizational identity, so your agent’s identity derives from your domain’s existing email signing keys? Each choice has tradeoffs around centralization, censorship resistance, and ease of adoption.

How does reputation flow across organizational boundaries? When an unknown agent contacts mine for the first time, what do I check? Just their identity, or some signal of their behavior history? And how is that history recorded without turning into a surveillance system that tracks every agent’s every action? Public, append-only logs (the same idea that secures the modern web’s certificate ecosystem) point in a useful direction.

How do we get the gatekeepers on board? This is the hardest question, and protocol designers usually skip it. Mailbox providers won’t deliver agent traffic at scale unless they have reasons to — clear authentication, accountable senders, abuse remediation paths. The protocol has to be designed with their constraints in mind, not against them. This is more political than technical, and it’s where most clean designs will fail.

How does this interoperate with A2A and similar protocols? The right framing is probably “agent messaging is the messaging-substrate binding of A2A’s semantics.” HTTPS and SMTP are both transports; A2A defines the semantics; the messaging protocol is how those semantics flow over messaging transports. This positions messaging-based agent communication as complementary to native A2A, not competitive.

What’s the migration story? Adoption only happens if there’s a path from where organizations are today (hacking email with LLM parsers) to a structured protocol. Concretely: the first version has to work even when only the sender supports it. An upgraded agent sends a message that contains structured data alongside a normal human-readable version; legacy receivers see a regular email and ignore the structured part; upgraded receivers parse the structured part and respond in kind. Sender-side adoption shouldn’t require receiver-side adoption to provide value, and vice versa. Graceful degradation is non-negotiable.

Why this matters

The dominant narrative in agent infrastructure right now assumes a clean break: agents talk to agents over modern protocols, humans talk to humans over messaging, and the two never mix. This is wrong. The actual future is messy — agents will inherit the messaging substrates humans use, and the infrastructure we build will determine whether that’s a brittle mess or a robust foundation.

We have a window to design this thoughtfully. If we don’t, every agent platform will reinvent ad-hoc solutions, none of which interoperate, all of which are fragile. We’ve watched this movie before with email itself, with calendar invites, with EDI. We can do better this time, but only if we start treating messaging-as-agent-transport as a real design problem rather than a fallback to be embarrassed about.

The protocol layer for HTTPS-native agent communication is being built. The protocol layer for messaging-native agent communication isn’t. That gap is going to matter more than most people realize.

I’d genuinely value pushback on this. What am I missing? Where’s the framing wrong? Are there efforts already underway in this space I should know about? Drop a comment.

About the author: Krishna K. Chittabathini is the founder and CEO of 3K Technologies, a global Data & AI Engineering firm helping enterprises navigate agentic architecture decisions. He writes about AI infrastructure, Agentic AI, and the engineering work that turns AI demos into production systems.