I fell down a Wikipedia rabbit hole last month. Started looking up something about SMTP timeouts, and three hours later I'm reading about how the Reuters news agency used carrier pigeons to beat the telegraph in 1850.
And here's the thing that struck me: the pigeons had deliverability problems too.
I'm not even joking. Stay with me here.
(Fair warning: some of this is necessarily speculative—ancient sysadmins didn't leave us delivery dashboards—but the patterns are unmistakable.)
The Original Delivery Network
The Romans were the first to really scale carrier pigeons. They called them columba livia domestica because of course the Romans had a fancy Latin name for everything. By the time of Julius Caesar, they'd built an entire messaging infrastructure across the empire. Pigeons stationed at outposts. Breeding programs to ensure reliability. Handler training.
They had, essentially, a distributed messaging network with redundancy built in.
But here's what nobody tells you: pigeon delivery rates were terrible. Like, maybe 50% on a good day. Hawks would intercept them. Storms would throw them off course. Sometimes pigeons just... didn't feel like going home that day. (I respect that, honestly.)
So what did the Romans do? The same thing we do today with email. They sent multiple copies.
If a message was important, you'd send three pigeons with the same message. Sometimes five. The assumption was that at least one would make it through. Sound familiar? It's basically retry logic, just with more feathers.
And they had delivery confirmation problems too! You'd send a pigeon and then just... wait. Did it arrive? Is the recipient reading it right now? Did a hawk eat it over Gaul somewhere? There was no way to know.
The anxiety of "did my message get through" is literally two thousand years old.
The Victorians Were Obsessed With Speed
Let's jump forward to the 1800s, because this is where it gets really fun.
The Victorians had this beautiful insane confidence that technology could solve everything. And their solution to messaging was pneumatic tubes. Yes, those things you see at bank drive-throughs. Except everywhere.
London built a pneumatic mail network in 1863 that could shoot a letter across the city in under five minutes. Paris had one. Berlin had one. New York built one in 1897 that ran 27 miles under Manhattan. At its peak, the New York system was moving 95,000 letters a day through underground tubes using compressed air.
Think about that for a second. They built an underground internet made of air and brass cylinders, and it actually worked.
But—and you knew there was a but coming—the pneumatic system had deliverability problems too. Cylinders would get stuck. Pressure would drop in certain segments. Sometimes letters would arrive damaged, or arrive in the wrong station, or just vanish somewhere in the network.
So what did they do? They built monitoring systems. Pressure gauges at every junction. Operators who would track which cylinders made it through and which didn't. They created what we'd now call observability infrastructure.
The New York Pneumatic Mail system kept logs. Actual paper logs of every cylinder sent, received, and lost. They calculated delivery rates. They identified problem segments in the network.
They were doing email deliverability analysis in 1897. They just didn't know it.
The Telegraph's Dirty Secret
Here's a story I love.
In 1850, Paul Julius Reuter—yes, that Reuters—was trying to get stock prices from Brussels to Aachen faster than the competition. There was a telegraph line, but it had a gap. A 76-mile gap between two German cities where the telegraph just... wasn't built yet.
So Reuter filled the gap with pigeons.
He'd receive the telegraph in Brussels, write the stock prices on tiny slips of paper, attach them to pigeons, and launch them toward Aachen. The pigeons would fly the 76-mile gap in about two hours. A courier on horseback would take six.
Reuter was running a multi-protocol messaging system. Telegraph where available, pigeon fallback where not. He was basically doing what enterprise email senders do today when they route transactional mail through one ESP and marketing through another.
And he tracked delivery rates! He kept records of which pigeons made it and which didn't. He bred the reliable ones and retired the flaky ones. He was A/B testing pigeons in 1850.
The thing that kills me is that this isn't even unusual. Every major advancement in messaging technology has faced the exact same problems, and humans have invented the exact same solutions, over and over again.
SMTP: Same Problems, New Wires
When Ray Tomlinson sent the first network email in 1971, you'd think we'd have figured this all out by then. Telegraph had been working for a century. Telephone for decades. Surely email would just... work?
Ha.
The early ARPANET email system was a mess. Messages would disappear. Delivery would fail silently. There was no reliable way to know if your message had been received. The first email protocols didn't even have proper error handling—if something went wrong, the message just vanished into the void.
Sound familiar? It's the pigeon problem all over again.
So they invented SMTP, with its codes and handshakes and retry mechanisms. 250 OK. 550 User Not Found. 421 Try Again Later. They built a system to track what happened to messages, because without that, email was just screaming into the darkness.
But here's the part that fascinates me: SMTP was designed in an era when everyone on the network was a known, trusted academic institution. There were maybe a few thousand email users in the world, and they all kind of knew each other.
The protocol has no built-in concept of spam. No authentication. No reputation. None of the things we now spend our entire careers managing. It's like building a house in a friendly village and then being surprised when the village becomes a city of eight billion people and suddenly you need locks on the doors.
Every deliverability problem we deal with today is, in some sense, a consequence of SMTP being too trusting. Too optimistic about human nature. It's almost sweet, really, how naive early email was.
What Actually Never Changes
Alright, so I've dragged you through two thousand years of messaging history. What's the point?
The point is this: we keep inventing new ways to send messages, and we keep facing the same fundamental problems.
Problem 1: Did it arrive?
Romans didn't know if their pigeon made it. Victorians didn't know if their pneumatic cylinder got stuck. Early email users didn't know if their message was received or lost. We still don't really know—we infer from opens and clicks, but those are proxies at best. The fundamental uncertainty of "did my message reach a human" has never been solved. We've just gotten better at estimating.
Problem 2: How do we handle failure?
Every system invents retry logic. The Romans sent multiple pigeons. SMTP has exponential backoff. ESPs have queue management. It's the same solution wearing different clothes across centuries.
Problem 3: Who's watching the network?
The pneumatic tube operators had their pressure gauges. Telegraph offices had their operators listening for faults. We have our dashboards and alerts. Monitoring is inevitable. You cannot run a messaging system without someone—or something—watching to see if it's actually working.
Problem 4: Trust and reputation
This one's interesting. The Romans had to trust their pigeon handlers. Telegraph operators could read every message they transmitted—integrity was based on professional ethics. Early email trusted everyone because the network was small.
Every messaging system eventually develops a trust layer. For email, it's sender reputation, authentication, and filtering. But the need for trust isn't new. It's just that the scale of email made the trust problem impossible to solve with social norms alone.
So Where Does AI Fit In?
Here's where I land after thinking about this way too much.
Every messaging system in history has needed humans to monitor it, interpret the signals, and fix problems. The pneumatic tube operators watching pressure gauges. The telegraph operators listening for line faults. The email operations teams staring at dashboards.
The job is always the same: watch the system, notice when something's wrong, figure out why, and fix it.
For two thousand years, that job has required human attention. Human pattern recognition. Human judgment.
What if it doesn't anymore?
That's what autonomous AI actually represents in the messaging world. Not a new way to send messages—SMTP is going to be around for decades still. But a new way to watch the system. To notice when something's wrong. To investigate why. To recommend fixes.
The pigeon handlers of ancient Rome would recognize what we're trying to do. They watched for pigeons that didn't come back, tried to figure out why, and adjusted their approach. We're just doing it at the scale of billions of messages per day, which means humans literally cannot watch it all anymore.
So we're teaching machines to watch for us. To notice the patterns we'd notice if we had infinite time and attention. To ask the questions we'd ask if we weren't juggling fifteen other things.
It's the same job it's always been. Just with better tools.
The Part I Can't Stop Thinking About
Here's my favorite detail from all this research.
In 1870, during the Siege of Paris, the city was completely surrounded by Prussian forces. No telegraph. No mail. No communication in or out.
So they launched carrier pigeons from hot air balloons.
Let that sink in. They put pigeons in hot air balloons, floated them over enemy lines, and then the pigeons flew back to Paris with messages. They used microfilm to fit more text onto smaller paper so the pigeons could carry more messages per flight.
It was absurd. It was brilliant. It was humans refusing to accept that communication was impossible, and inventing whatever crazy solution was necessary to keep messages flowing.
That's the through-line of all of this. Pigeons, pneumatic tubes, telegraph, telephone, email, AI—it's all the same fundamental human need. We need to communicate. We need to know our messages arrived. We'll invent whatever it takes to make that happen.
And when the current solution starts to break down—when there are too many messages, too many failures, too much complexity for humans to manage—we invent the next thing.
Two thousand years of message delivery, and we're still just trying to answer the same question the Romans were asking:
Did my message get through?
At Engagor, we're building AI that watches your email program the way the pneumatic tube operators watched their pressure gauges—continuously, intelligently, and ready to tell you when something's wrong. It's not a new idea. We just finally have the technology to do it at scale.
