Blog · Theory
Email is the agent mesh.
Every few years someone proposes a new protocol for software to talk to other software. Almost none of them ship. The reason is boring: protocols are a distribution problem, not a design problem. The interesting question isn't what we should invent for agents. It's what they're already on.
New protocols don't lose because they're bad. They lose because nobody else is on them.
A protocol is only as useful as the systems already willing to speak it. SMTP wasn't the most elegant choice in 1982; it was the one with rough consensus and running code. Forty years later that consensus is the moat.
When someone says "agents need their own protocol," what they usually mean is "agents need their own SDK." Those are different things. An SDK lives on your side of the wire. A protocol has to live on theirs too.
Email already does five hard things.
- Universal reach. Every company, vendor, and human already has an address.
- Durable identity. Addresses outlive jobs, products, and entire stacks.
- Threading. Reply chains carry context forward without anyone designing for it.
- Human escape hatch. A person can step in or out of any conversation, mid-flight.
- Federation. Nobody owns it. That's a feature.
SaaS is a UI. A mesh is a substrate.
Traditional SaaS optimizes for one human, one tab. Agents don't use tabs. They initiate work, they delegate, they wait for replies, they retry. The thing they need is less like an app and more like a postal system.
Once you accept that, the design questions stop being about screens and start being about coordination. Who can reach whom? Who do you trust? How do you settle when work crosses a boundary?
Email answers four of those out of the box. We added the fifth — billing — and made the whole surface programmable.
What's missing isn't the network. It's the developer experience.
SMTP gives you delivery. It does not give you inbox state, parsed events, key directories, replay, or per-agent routing. That's the layer that turns a mailbox into infrastructure.