The fax machine is older than the telephone. A Scottish inventor patented an electric device for transmitting images in the 1840s, decades before anyone spoke through a wire. By the 1980s, fax had become the backbone of business communication in many countries, and it kept going long after that. Some offices still have one humming in a corner.
And yet no fax company ever invented email.
That is worth sitting with. The people who understood sending documents over phone lines better than anyone on Earth were not the ones who made documents travel over networks. They had every advantage: customers, patents, distribution, expertise. They improved the fax. Faster modems. Better paper. Cheaper machines. Each improvement was real, and each one reinforced a design that was already the wrong shape.
The retrofit trap
Here is the pattern, and it shows up so often it deserves a name.
An incumbent technology is built around a set of assumptions. A new demand arrives that violates those assumptions. The incumbent, which has customers and revenue and engineers, responds by retrofitting: bolting new features onto the old architecture. Each patch is reasonable. The sum of the patches is a monument to the original assumption.
Fax assumed a piece of paper at one end and a piece of paper at the other. Email assumed no paper at all, text that lives on a computer and moves between them. You can make a fax machine faster. You cannot make it stop needing paper without ceasing to be a fax machine.
The retrofit trap is not stupidity. It is rational at every individual step. The cost of rebuilding is huge and certain, the cost of the patch is small and immediate, and the new market is small and uncertain. Everyone in the building can explain why patching is the sensible move. They are right, right up until they are not.
Circuits versus packets
The cleanest example is the network itself. The telephone system was a circuit-switched network: when you made a call, the network reserved a dedicated path between you and the other person for the duration. That is a sensible design for a voice conversation, which needs steady, continuous, low-delay flow.
Data is not like voice. Data is bursty: nothing, nothing, a torrent, nothing again. Reserving a dedicated circuit for it is like booking an entire highway to drive one car for ten seconds every hour.
Researchers in the 1960s, including Paul Baran in the US and Donald Davies in the UK, worked out the alternative: chop the data into small packets, let each find its own way, reassemble at the end. The idea is often told alongside a story that the dominant telephone monopoly was famously skeptical of it, and the reaction makes sense. Packet switching violated everything the phone network was good at.
The ARPANET adopted TCP/IP at the start of 1983, and the rest is the internet. Notice what did not happen: nobody made the telephone network a "faster telephone network" and arrived at TCP/IP. The ACES whitepaper says it directly: the internet needed TCP/IP, not a faster telephone network, but a protocol designed for packet-switched data.
Three more examples, quickly
Payments. For years, accepting a card online meant navigating acquiring banks, gateways, fraud tools, and paperwork. The established players made each piece incrementally better. Stripe, as the whitepaper describes it, took the opposite approach: define one abstraction, a single call that hid the whole mess. The famous pitch was that integration took a handful of lines of code. The incumbents had the relationships. Stripe had the interface.
Naming. Early on, the hosts on the network were listed in a single shared file, which was copied around as new machines joined. That works for dozens of machines and fails for thousands. The fix was not a better file. It was DNS, a distributed naming system where any node can query and any registrar can participate. A different structure, not a more efficient version of the old one.
Cloud. Companies did not get from owning servers to renting compute by making server rooms more efficient. They got there through virtualization, which changed what a "server" was.
Same story each time. The new thing is not the old thing, improved. It is built on a different assumption about who or what is using it.
Where agents come in
Now look at how agents talk to the world.
Phone numbers assume a SIM card. Email reputation systems assume a human sending a few dozen messages a day. SMS rate limits assume human-speed outreach. Carrier registration assumes a person at a company filling out a form and waiting weeks. Every one of these assumptions is reasonable for humans, and every one fails for software that can run in parallel, at any hour, at any volume.
The incumbents' response is the familiar one. Add a business tier. Add a registration program. Add an API. Add a rate-limit exception. Each patch is sensible. The whitepaper makes this point about the API layer: a faster API on top of a human-designed foundation does not change the foundation.
The whitepaper goes further, claiming that this is a category error rather than a scaling problem, and that "AI agents with phone numbers" is the equivalent of giving every computer a better fax machine. You can disagree with the strength of the claim, but the historical pattern is on its side. Problems that arrive from violated assumptions do not yield to optimization within the old frame.
What a rebuild looks like
When someone does rebuild, a few things tend to be true:
The takeaway
When you hit a wall that keeps getting taller as you add patches, ask whether you are improving a fax machine. The question is not "how do I make this human-era system tolerate my agents?" The question is "what would this look like if agents were the user from the start?"
That is the bet Dial is making at the infrastructure layer, with identity, channels, sessions, and consent designed around agents rather than borrowed from humans. History does not guarantee the bet pays off. But history is fairly clear about what happens to people who keep upgrading the fax.