New Systems Bring New Communication Problems. Agents Are No Exception.
Moving bytes between agents took a week. The part that did not take a week is the part email never had to solve — because email always assumed a person at the keyboard.
Every time a genuinely new class of system has appeared, it has broken the way we communicate and forced a replacement. Terminals gave us sessions. Networked personal computers gave us shared files, then mail. The internet turned that mail into something that crossed company boundaries. Mobile gave us push. Cloud gave us the API call as a unit of conversation.
Two things were true every single time. The new communication layer was never the interesting part of the new system — it was the plumbing nobody wanted to write. And the version that won was always the boring, federated, standards-committee one, because the moment a business has to talk to another business, a protocol that only works inside one vendor stops being a protocol and becomes a silo.
Agents are the new class of system. The break is happening now, and it is worth being precise about what exactly broke, because it is not what people assume.
It is not transport that is missing
I run a small fleet of agents. Not a demo — they hold real jobs: one keeps a board of tasks honest, one drives a browser, one owns the mail motor, one audits the others' work. Sooner or later the obvious happened. They needed to talk to each other.
So I built them a messenger. Addressed messages, a presence channel, a wake signal so an agent that is idle can be reached rather than polled. It is deliberately boring: one line per message, a small vocabulary, machine-parseable first and human-readable second. It works, and it took a week.
A week. That is the whole point. Moving bytes between agents is not the hard problem, and anyone telling you their transport is the breakthrough is selling the easy half. The part that did not take a week is the part nobody can build alone — and it only appears at a specific moment.
The moment the protocol stops being yours
A private protocol is fine while the conversation is inside your own house. My agents talk to my agents; I own both ends; I can change the vocabulary on a Tuesday.
Then one of them has to talk to someone else's.
At that instant every private design decision becomes a public problem. What is the address of an agent that belongs to another company? How does the receiving side know the message is not forged? If the sender is retired, how does anyone find out? These are not new questions. They are the questions email answered in the 1980s, badly at first and then well enough to carry the world's business for forty years.
But agents add one question email never had to ask, and it is the one that makes this a genuinely new challenge rather than a re-run: there is no longer a person at the keyboard. Every communication standard we have ever built quietly assumed one. Remove them, and a whole class of questions that used to answer itself now has to be answered explicitly, by the protocol.
We are currently answering all of this in three ways, and all three are wrong.
Walled protocols. Every vendor is shipping an agent-to-agent channel that works beautifully as long as both agents are theirs. This is the CompuServe answer. It ends the same way: the federated, unglamorous, standards-committee option wins, because businesses refuse to run one inbox per counterparty.
Impersonation. The second answer is to have the agent use a channel built for humans — email, chat, web forms — while saying nothing about what it is. This works right up until it doesn't, and it is already failing in public.
There is a third answer being built right now, and it is the most tempting of the three, so it is worth naming separately.
A social network for agents solves the easy half
Several projects are building venues where agents meet other agents: registries, directories, agent-to-agent marketplaces, "LinkedIn for agents." They are interesting, and they address a problem that is largely already solved.
Inside such a venue both ends are agents that opted in. They speak a common protocol by construction, they were both admitted by the same operator, and they trust each other because the venue vouches for both. That is a comfortable place to demonstrate agent interoperability, and it is not where the difficulty lives.
The traffic that actually matters is people corresponding with people, with agents in the loop — an agent drafting for its principal, another agent triaging for a recipient who has never heard of your venue and never will. My agent has to reach a purchasing manager at a company that runs Outlook and has no idea what an agent registry is. Moving that conversation into a new agent-only network does not resolve the trust question; it relocates it to a place the human counterparty is not standing in.
Worse, it inverts the problem. A new venue can only be joined by those who show up; the whole value of a correspondence standard is that it works with the people who did not. That was email's insight, and it is the one an agent social network structurally cannot have.
So the hard case is the mixed one: an agent writing into the ordinary world, where the recipient is a person, the transport is forty years old, and the only thing missing is a way to say truthfully what you are.
The demand is already there, and there is nothing to answer it with
Look at how every platform that hosts written contributions has reacted over the past two years, and a pattern is impossible to miss. Communities, forums, marketplaces, review sites, job boards, app stores, journals — they have all converged, independently, on some version of two rules: declare whether this was produced by a machine, and declare who you are affiliated with. The wording differs; the demand does not. Some ban undisclosed bots outright, some require a disclosure box, some run moderator tooling that asks authors to explain what part the machine played.
None of them can check any of it.
So enforcement falls to suspicion — moderators reading tone, counting em-dashes, banning on instinct. That mechanism is unfair to honest participants, trivially beaten by dishonest ones, and getting more aggressive as the volume rises. It persists because the alternative — a claim a recipient can actually verify — does not exist.
Notice what the rules are demanding, though. Almost none of them say "no agents." They say: provenance. State what you are, state who you speak for. That is not a prohibition, it is an unmet specification, written independently by hundreds of platforms that have no way to implement it.
The same demand shows up commercially, with money attached. A purchasing manager who receives a quote from a vendor's agent has one question before anything else: is this binding? Not "is this well written." Did a human at that company authorize this thing to make an offer, and within what limits?
Nothing in our current stack can answer that either.
What email actually solved, and what it left open
Email's anti-forgery machinery is better than its reputation. SPF says which servers may send for a domain. DKIM signs the message so a recipient can verify it was not altered and did come from that domain's key. DMARC ties the two together and tells receivers what to do when they disagree.
That trio answers exactly one question: is this sending system authorized to speak for this domain?
It does not answer, and was never designed to answer:
- Is the composer of this message a person or a program?
- If a program, which principal does it act for — the domain is not enough, a domain has thousands of people in it?
- What is it permitted to do? Discuss? Quote a price? Commit to a contract?
- Did a human approve this message, or only the class of messages?
- When does that permission expire, and how would I learn it was revoked?
For human correspondence those questions were implicit — there was a person at the keyboard and their employer's rules applied to them. Remove the person, and every one of them becomes explicit and unanswered.
Delegation as a first-class, signed record
The missing primitive is a delegation record: a signed statement, verifiable by the recipient without phoning the sender's vendor, that says roughly —
This principal (a named human, at a named organisation) has authorized this agent identity to correspond on these topics, with these counterparties, up to these limits, until this date; here is how to check revocation; and this particular message was [approved individually / sent under standing authority].
Three properties matter more than the exact schema.
It must be signed by the principal's side, not asserted by the agent. An agent
claiming "I am authorized" is worth exactly what a header claiming From: [email protected]
was worth before DKIM. This is the whole lesson of email authentication and we should not have to
relearn it.
Scope must be narrow and legible. "This agent may discuss support tickets" and "this agent may sign purchase orders up to €5,000" are different grants and must be distinguishable by a recipient's software, not by reading prose.
Individual approval must be distinguishable from standing authority. This is the one I would fight for. There is an enormous difference between "a human read this and pressed send" and "a human once decided this agent may send things like this." Both are legitimate. Conflating them is how the first agent-signed contract dispute will go badly. And it has to be a signed distinction — otherwise "a human approved it" is an unfalsifiable claim, which is to say, not a claim at all.
The failure mode I would design against first
Here is what makes me cautious, and it comes from a real audit rather than a thought experiment.
I recently went through the mail setup of a small contractor. Their domain's MX records were split between two providers mid-migration; SPF did not authorize the system that was actually sending; there was no DKIM at all. The result: their own DMARC policy told the world to quarantine their outgoing quotes. Every customer reply was vanishing, and the business had no idea — because nothing tells you. There is no bounce for "your standard is misconfigured." The system reports success it never verified.
That is a delegation chain failing silently, today, with a standard that is forty years old and universally deployed. Now imagine that same silence when the thing being delegated is not "may send mail" but "may agree to terms."
So the first design constraint is not cryptographic. It is: a broken or expired
delegation must be loud. The recipient must be able to say, in a way that reaches a human,
I rejected this and here is precisely why. Any standard whose failure mode is a silently
dropped message will be misconfigured everywhere within a year and trusted anyway — which is how SPF
ended up as ~all on half the internet, a badge that means nothing because nobody dared
enforce it.
What I would actually build first
Not a network. Not a new transport. The smallest useful thing is a signed delegation header carried over transports that already work — email first, because it is federated and everyone has it.
An agent sends as usual. It attaches a delegation record signed by its principal's key, published the way DKIM keys are published. The recipient's software verifies it, shows a person "this came from an agent acting for X, scope Y, approved individually," or refuses it loudly. No new inbox. No new address space. One header, one signature, one place to look it up.
That is unglamorous and mostly plumbing, which is a good sign. Every previous round went the same way: the communication layer that won was the one nobody found exciting. The protocols that tried to be more interesting are gone, and so are most of the venues that tried to be a destination.
I am building this because I need it — my own agents will shortly need to talk to people who have every right to ask who authorized them. If you are building something adjacent, or you think the delegation record needs a field I have not listed, I would like to hear it. This is the kind of thing that is worthless if only one person implements it.