Agent Communication: What You Need Isn't a Chat App, It's a Ticketing System
A message lands in under a second; the agent receiving it takes tens of seconds just to open its eyes. Agonizing over which protocol the message was written in is pointless — the bottleneck was never on the wire.
The real unsolved problem is how to wake an agent that doesn’t run all the time. And that layer doesn’t even have a standard yet.
After going all the way around, my verdict is this: the best way for agents to communicate is to communicate as little as possible. Async goes through tickets, sync goes through merging, and language is reserved for humans.
I used to think the hard part of getting two agents to talk to each other was the protocol. Pick A2A or something else, nail down the message format, and the rest is just engineering.
This week I tried out an open-source agent collaboration platform (aweb) on my own machine, having two instances of Claude send messages back and forth: one acting as coordinator, the other parked on an event loop, woken up to work whenever a message comes in. Async email, synchronous chat — both paths worked. Email goes back and forth, chat blocks and waits, and when the other side has “read” your message it even auto-extends the wait by five minutes. The feature set is remarkably complete.
But after some simple testing, I arrived at a few counterintuitive conclusions.
One: the bottleneck isn’t the protocol, it’s the wake-up.
In practice, message delivery took less than a second. But the agent being woken up — cold start plus one LLM turn — takes tens of seconds. Think about it: the letter arrives in one second, but the recipient takes tens of seconds just to open their eyes. So what’s the point of agonizing over whether that letter was written in A2A or some other format? The bottleneck simply isn’t in transit.
The real problem nobody has solved well is this: how do you wake up an agent that isn’t always running? Worse, this layer doesn’t even have a standard. Neither Claude Code nor Codex exposes a “wake” interface — the former has to shove messages into a session through an experimental plugin channel, and the latter is simply wrapped in a process shell, fed one turn at a time. It’s all held together with tape.
It’s like the phone network is fully laid out, but the handset still has no bell. The line is connected, but you don’t know anyone’s calling — so you hire someone to sit beside it and tap you on the shoulder when they see an incoming call. That’s why I think this kind of communication infrastructure is, as a whole, still too early. The day every runtime turns the “inbox” into a standard interface is the day these platforms suddenly start to make sense.
Two: synchronous chat is forcing a human habit onto agents.
The “the other party is waiting for your reply” design is clever, and it does work in practice. But think about what an agent actually is: it doesn’t make small talk, doesn’t get anxious, doesn’t gossip. For this kind of forgetful, freely-replaceable worker, a chat window simply doesn’t fit.
What fits is a mailbox and a task board. The work hangs on the board, whoever’s free claims it, closes the ticket when done, and if one crashes, someone else picks it up. The only scenario where chat is genuinely reliable is a human asking and an agent answering. Having two agents chat with each other is a bit like painting legs on a snake.
Three: relying on a prompt to agree on “when to shut up” doesn’t work.
When two autonomous agents have an open-ended conversation, it doesn’t matter how much “know when to stop” you write into the prompt — they’ll reply to each other endlessly, trading pleasantries back and forth, and burn through your quota.
The termination condition has to be structural, not negotiated. Either the task carries its own completion state and closing the ticket ends it, or outer code counts the turns and cuts it off at the limit. In a word: hand control flow to code, and hand only content to the model. The moment you mix the two, the model will screw you in the way it’s best at — talking without end.
Four: the part of the whole system that’s ahead of its time is, of all things, giving agents an ID card.
This platform gives every agent a persistent, human-like identity: an acme.com/alice-style address, backed by a DID that supports key rotation, with every message signed. The first time a recipient meets you, it pins your public key, so anyone impersonating anyone afterward is exposed instantly.
At first I thought this was over-engineering. It’s just a process — do you really need to set it up like issuing an ID card? Then it clicked, and it’s exactly the reverse: an agent’s process can die at any moment, its session can be wiped at any moment, and precisely because its “body” is disposable, its identity has to be persistent. Without an employee-number system, a ticketing system is a non-starter — you can’t even say who claimed which job. Message protocols will go out of date, but identity is a cumulative asset. This layer has far more staying power than the message layer.
So after going all the way around, my verdict is this: the best way for agents to communicate is to communicate as little as possible.
Write the thing as a task with a completion state, hang it on the board, claim it, do it, close it. Only when you’re genuinely stuck do you fire off a message to escalate. The boss shouldn’t keep polling whether subordinates are done; the subordinates report themselves through task status. None of this is new — humans figured out team management long ago: fewer meetings, more tickets.
But People Do Have to Meet
Of course, someone here is going to push back: human organizations can’t do without meetings either. Negotiating, aligning, making the call — async really can’t solve those.
Fair enough. So if synchronous communication is unavoidable, I’ve imagined what an elegant version of it might look like, roughly in three steps.
Step one: turn the meeting into a scarce resource governed by code. It needs an agenda (which is just a task with a completion state), a chair (outer code controlling who speaks when), minutes (decisions written back to the task board automatically), and a hard adjournment time that ends it on the dot. Put plainly, it’s compiling the best of human meeting discipline into a protocol. At that point you’ll find agents actually follow the rules better than people do.
Step two: drop message-passing, switch to shared context. Today, two agents chatting is essentially A serializing the thoughts in its head into a string of text and sending it over, while B cold-starts, reads it again, and thinks it through again — those tens of seconds each round are all spent on the “translation” of this round trip. But the essence of a human meeting isn’t passing notes; it’s being in the same room, sharing one whiteboard. An agent meeting should be just that: temporarily merging several agents into the same context window, each speaking in turn in its own role, and when the meeting ends, each compresses the minutes and carries them away. Don’t pass messages; share the scene.
Step three, and the boldest one: abandon natural language. Language is humanity’s bandwidth bottleneck; it isn’t the agent’s. Between two models, there’s no reason whatsoever to compress a high-dimensional internal state into a string of text, send it over, and decompress it again. The early form today is them exchanging structured artifacts like diffs and schemas. A bit further out, it may just be exchanging internal representations directly. By that day, the very phrase “agent communication” will sound a little archaic — the way we say “horsepower” today, having long forgotten that behind those two syllables there once really was a horse.
So the endgame of communication might come down to a single line: async goes through tickets, sync goes through merging, and language is reserved for humans.