Daniel's been thinking about phone trees — stay with me — and he's landed on something that sounds like a novelty but isn't. The idea is a business phone menu with a branch explicitly for machines. Press one for sales, press two for support, press six if you're an AI agent calling on behalf of a customer. Press six and you skip the audio prompts entirely. You get a short machine-shaped exchange whose whole purpose is to get the agent off the phone as fast as possible, holding a structured handle on the business — an endpoint URL, a token, a booking slot. The call is a handshake, not a transaction. Voice is terrible for structured data and excellent for finding out where the good transport lives.
Right. The phone number as bootstrap protocol.
And the reason this is more than a clever menu option is discovery. A phone number is the most universally published machine address a business has. It's on the shopfront, Google Maps, the invoice, the side of the van. Almost none of those businesses have an agent card or an OpenAPI spec, and survey data suggests that's not changing fast. One scan this July found sixty-five A2A agent cards across twenty-two thousand three hundred forty-one domains. Ten of them were actually conformant.
Ten.
So the phone number becomes a last-resort service discovery layer for the enormous long tail of businesses that will never publish anything machine-readable on the web. When Daniel went looking for prior art he came up empty. IVR vendors all ship the opposite direction — press three to speak to our automated assistant. Adjacent products are agents brute-forcing human phone trees at one-times audio speed. Dialers detecting machines specifically to hang up on them. A business inviting a machine to identify itself and offering it a better lane didn't surface anywhere.
Which is a finding in itself.
That's the question he sent us. What implementations of this idea actually exist out there? Go look — startups, telephony vendors, standards drafts, academic prototypes, somebody's weekend Twilio project, a hotel chain quietly running it. And if the honest answer is nobody has built it, make the case for what that absence is telling us.
So we went looking.
We did. Here's what we found — and what we didn't.
Let's start with what the industry is actually building right now, because it's the exact opposite of Daniel's idea. ElevenLabs published a piece recently documenting the dominant pattern, and it's this: you build an AI agent, you give it a phone number to call, and it navigates the human phone tree at one-times audio speed. It listens to "for sales press one, for support press two," waits for the right prompt, presses the button. It sits through hold music. It talks to the human or the human-facing bot on the other end. It's brute-forcing a system designed for human ears and human fingers.
Which works, technically. It's just slow and fragile and you're burning compute to listen to hold music.
And it's adversarial by nature. The phone tree doesn't know it's talking to a machine, the machine is pretending to be a human, and the whole interaction is a pantomime. Daniel's idea inverts that completely. The business says: I know you're a machine, I'm fine with it, here's the fast lane.
The industry's default posture toward machine callers right now is hostility. Dialers detect machines and hang up on them. That's an established pattern — the assumption is that if a machine is calling, it's spam or a scam or a robocall. The reflex is to block, not to serve.
And the IVR vendors are building the other direction too — press three to speak to our automated assistant. That's a business offering its own AI to the human caller. It's human-facing AI, not machine-facing lanes. Nobody is building the inbound lane for the machine caller.
So the honest answer to Daniel's first question — what implementations exist — is that the search came up empty. We looked across startups, telephony vendors, standards drafts, academic prototypes, weekend projects. No direct implementation of a machine-specific IVR branch surfaced anywhere.
I want to be precise about what we mean by empty. There is adjacent work. There are pieces. But the specific thing — a business phone menu that says "if you're an AI agent press six" and then does a structured handshake — we didn't find it.
And that absence is itself a finding. Let's dig into what it means.
The closest thing we found on the discovery side is the Linux Foundation's Agent Name Service, or DNS-AID. It's a web and DNS-based discovery mechanism for AI agents. The idea is that instead of calling a phone number, an agent looks up the business's domain, queries a DNS record, and gets back an agent card that tells it where to connect. It solves the same problem Daniel is pointing at — how does a machine find the right endpoint for a business — but it does it on a completely different transport.
And the adoption numbers tell the story. The scan Daniel mentioned — sixty-five A2A agent cards across twenty-two thousand three hundred forty-one domains, ten conformant. That's not a rounding error, that's a signal. The web is not becoming machine-readable at the scale or speed that would make the phone number irrelevant.
The phone number remains the one address every business has. Every restaurant, every plumber, every dentist, every hotel. They all publish a phone number. Almost none of them publish an agent card. And the scan suggests that's not changing fast enough to matter for the long tail.
So you've got two approaches to the same discovery problem. One says: we'll make the web machine-readable, and agents will look up endpoints through DNS. The other says: the web isn't becoming machine-readable, so use the phone number that's already there as a bootstrap to get the structured endpoint.
And here's what's interesting about the phone approach. The technical pieces all exist. SIP can handle the call setup. DTMF can carry the initial handshake — the agent presses six, the system responds with a tone or a short data burst. You can exchange a token and an endpoint URL in a few hundred milliseconds. The call is over in seconds. None of this is science fiction.
The barrier isn't technology. It's incentives.
Right. Businesses don't currently see AI callers as a revenue channel worth serving. The volume of AI-to-business calls is still low. Most businesses aren't getting calls from agents trying to book appointments or check inventory or place orders. So there's no pain, no demand, no business case for building the machine lane.
And there's a chicken-and-egg problem. Agents aren't calling because there's no machine lane, and there's no machine lane because agents aren't calling.
But that's a timing problem, not a viability problem. As agent-to-agent commerce grows — and it will grow — the phone tree becomes a bottleneck. Every agent call that has to navigate a human IVR at one-times speed is burning time and compute for no reason. At some point the pain tips, and the machine lane becomes the obvious escape hatch.
Let me push on something. You said the technical pieces all exist, and I think that's true for the call itself. But there's a harder problem lurking. How does the business know the agent calling is legitimate?
That's the authentication question, and it's a real one. A machine lane that's open to any agent that presses six is a spam vector. You'd need some kind of token exchange or attestation — the agent presents a credential, the business validates it, then they do the handshake.
And now you're building an identity layer for AI agents, which is a whole separate problem.
It is, but it's not an unsolvable one. The A2A protocol already has a concept of agent identity. You could piggyback on that. Or you could do something simpler — the agent presents a token issued by the platform that sent it, and the business verifies the token against the platform's public key. The call itself doesn't need to carry the whole identity negotiation. It just needs to carry enough to establish trust for the handoff.
So the handshake says: I am an agent, here's who sent me, here's my credential, give me your endpoint. The business says: credential checks out, here's the URL, here's a session token, goodbye. Call over.
Under three seconds. And then the actual transaction happens over the structured channel — an API call, a booking request, an inventory query. The phone call was never the transaction. It was the introduction.
Which is why Daniel called it a handshake, not a transaction. Voice is a terrible transport for structured data and an excellent one for finding out where the good transport lives.
That's the line I keep coming back to. It's exactly right. Voice can carry a URL and a token. It can carry a yes or no. It cannot carry a restaurant reservation with party size, time preferences, dietary restrictions, and a credit card number — not efficiently. But it can tell you where to send all of that.
So if the pieces all exist and the logic holds, why hasn't anyone assembled them? That's the question that takes us from the search results to the deeper implications.
I think there are three answers, and they pull in different directions. The first is the timing one we already touched — the volume isn't there yet. The second is that the industry is still in the brute-force phase. Everyone's building agents that can navigate the world as it is, not as it could be. The ElevenLabs article documents agents brute-forcing IVR trees because that's what works today, with the phone trees that exist today, without asking any business to change anything.
And the third?
The third is that maybe the phone network itself is the wrong substrate. DNS-AID exists because a lot of smart people think discovery should happen at the web layer, not the phone layer. The phone number is universal, but it's also a legacy transport. It's tied to a specific network with specific limitations. If you're building a new discovery system from scratch, do you really want to anchor it to the PSTN?
That's the counter-argument that's worth taking seriously. The phone number is everywhere, but everywhere is also the problem — it's on the side of a van because it's been there for decades. The web was supposed to replace it as the universal address, and for a lot of businesses it has. You go to the website, you don't call.
But the scan says the web isn't replacing it for machine discovery. Ten conformant agent cards out of twenty-two thousand domains. That's not a transition in progress. That's a transition that isn't happening.
Or isn't happening yet. The scan is a snapshot from July twenty twenty-six. A year from now the number could be ten times higher. Two years from now it could be the default.
Possibly. But I keep thinking about the long tail. The plumber with three employees and a WordPress site from twenty eighteen. The family-run hotel in the Italian countryside. The dentist who still uses a fax machine. These businesses are never going to publish an agent card. They're never going to set up an MCP server. They might not even know what those things are.
But they all have a phone number.
They all have a phone number. And if an AI agent wants to book an appointment with that dentist or reserve a room at that hotel, it needs some way to find the endpoint. The phone number is the fallback that already exists everywhere.
So you've got two futures. In one, DNS-AID or something like it wins, and every business eventually publishes a machine-readable endpoint on the web. In the other, the phone number becomes the universal discovery bootstrap, and businesses add a machine branch to their phone tree because it's the cheapest way to serve the growing volume of AI callers.
They're not mutually exclusive. The big chains and the tech-forward businesses will publish agent cards. The long tail will use the phone number. The ecosystem splits.
Which is actually the most likely outcome. The web-native discovery layer serves the top ten or twenty percent of businesses. The phone-based discovery layer serves everyone else.
And the phone layer has an interesting property that the web layer doesn't. It's inherently rate-limited and cost-bearing. A phone call costs someone something — even if it's just the compute to place the call. That makes it harder to spam than a web endpoint that anyone can hit for free.
Built-in spam protection by virtue of being slightly annoying.
It's not a perfect filter, but it raises the cost of abuse. If you have to place a phone call and complete a handshake before you get the API endpoint, you can't just scrape ten million endpoints from a DNS scan.
Let's talk about what a real implementation would actually look like, because I think the shape matters. You call the number, the IVR picks up. "For sales press one, for support press two, for AI agents press six." You press six. What happens next?
The simplest version: the system plays a short tone that says "I'm listening for a machine." The agent sends a DTMF sequence or a short data burst with its identifier and the platform it's calling from. The system validates it, sends back a URL and a token as a data burst or even as a text-to-speech string, and hangs up. Total call duration: maybe two seconds.
The agent never hears a human voice. The business never pays for a human to talk to a machine. The whole thing is over before a human would have finished saying "thank you for calling."
And the structured data exchange happens off the phone network entirely. The agent takes the URL and the token, makes an API call, and does the actual transaction there. The phone call was just the handoff.
There's a variant of this that's even simpler. Instead of exchanging data during the call, the machine branch just gives you a URL. A single text-to-speech line: "Agent endpoint is api dot example dot com slash agent, authenticate with your platform token." The agent hears it, hangs up, and connects.
That's the minimum viable implementation. You don't need DTMF data bursts or special encoding. You just need a menu option and a text-to-speech line. Any business with a modern IVR could set this up in an afternoon.
Which raises the question again: if it's that simple, why hasn't anyone done it?
I think we have to consider the quiet-deployment possibility. Our research didn't find anything public, but that doesn't mean it doesn't exist. A hotel chain could be running this right now. A utility company could have a machine branch that's never been announced or documented publicly. The absence of public implementations is not proof of absence in the wild.
That's fair. If I'm a large hotel chain and I'm getting a meaningful volume of AI booking requests, I might build a machine lane and never tell anyone about it except the platforms I want to connect with. It's not a marketing feature. It's an operational efficiency.
And if you're a platform like a travel booking service, you might negotiate machine-lane access with your major hotel partners directly. It never shows up in a press release. It's just a business arrangement.
So the search coming up empty might mean it doesn't exist, or it might mean it's happening quietly in arrangements that aren't publicly documented. We can't distinguish those two from the outside.
We can't. But I think the quiet-deployment scenario is plausible for large enterprises. What's less plausible is that the long tail — the plumbers and the dentists and the family hotels — are running quiet machine lanes. They don't have the technical staff or the incentive. If they're doing it, it's because their phone system vendor shipped it as a feature.
That's the other thing we didn't find. No major IVR vendor is shipping a machine-lane feature. Twilio doesn't have a "press six for AI agents" template. The whole industry is building in the opposite direction.
Which brings us back to the fax-back story.
Before we get there — Hilbert's been sitting on something, and it turns out he's been here before.
Hilbert: Nineteen ninety-eight. I was working for a company that built fax-back systems. You'd call a number, punch in a document code, and the machine would fax the document to whatever number you gave it. Product catalogs, spec sheets, warranty forms. We had about four hundred of these systems in the field. One day the engineer who monitored the call logs — a man named Gerald who ate the same tuna sandwich every day for three years — Gerald notices that about sixty percent of the incoming calls aren't pressing any buttons during the voice prompts. They're just waiting. Then at the prompt they punch in a document code. Perfect timing, every time. No hesitation, no wrong buttons.
Because the callers were fax machines.
Hilbert: The callers were fax machines. They'd been programmed to dial the number, wait through the audio, and punch the code. The voice prompts were noise to them. Gerald's insight was that we were burning trunk capacity and the machines' time playing audio to nobody. So we built a branch. Press nine for fax machine access. It skipped the voice prompts entirely. Just a tone, you punch the code, the fax goes out. Call duration dropped from forty-five seconds to about seven.
This was in nineteen ninety-eight.
Hilbert: Summer of ninety-eight. Worked beautifully for about eighteen months. Then the fax machine manufacturers started building in a feature where you could program the document code into the dial string. The machine would dial the number, wait for the fax tone, and send the code as DTMF right after the handshake. They didn't need our press-nine lane anymore. They could just dial the main number and the system would figure it out. By two thousand one the press-nine lane was getting almost no traffic. We removed it in the next software update.
The machine lane was a transitional artifact. It existed because the machines weren't smart enough to navigate the human lane efficiently, and it disappeared when they got smarter.
Hilbert: The machines caught up. The lane was a bridge, not a destination.
That's... that reframes the whole thing.
Hilbert: The difference now is the machines are already smart enough to navigate the human lane. They can listen to the prompts, press the buttons, talk to the human. They don't need the machine lane. The machine lane is for the business's benefit — it's cheaper, faster, doesn't tie up the phone lines. But the agent doesn't care. It'll brute-force the human tree all day if that's what's available.
The incentive to build the machine lane is weaker now than it was for fax-back systems in ninety-eight. In ninety-eight, the fax machines couldn't navigate the voice prompts efficiently — they had to wait through the whole audio. The machine lane saved real money on trunk capacity. Today's AI agents can navigate the human tree just fine. The cost savings accrue to the business, not the caller.
Hilbert: The business doesn't feel the pain yet because the volume isn't there. Gerald noticed the pattern because fax machines were already a big chunk of our traffic. AI agents calling businesses are not a big chunk of anyone's traffic yet.
The machine lane is a solution to a problem that doesn't hurt enough yet.
Hilbert: It's a solution to a problem that's coming. Gerald saw it early because he was the one reading the logs. Somebody at a big IVR vendor is reading the logs right now and noticing the same pattern — calls where the button presses are too perfect, the timing too precise. But the volume's probably still small enough to ignore.
The Gerald of twenty twenty-six is out there somewhere, eating his tuna sandwich, looking at call logs.
Hilbert: He'll speak up when the trunk capacity starts costing real money. Until then, the machines will keep listening to hold music.
That fax-back story is the missing piece of the analysis. We've been asking why nobody has built this, and the answer is that the machine lane is a bridge technology. It exists to solve a specific problem during a specific window of time — after the machines start calling in volume, but before they're smart enough to bypass the lane entirely.
The window for fax-back was about eighteen months. The question is whether the window for the AI machine lane is longer, shorter, or nonexistent.
I think it's longer, because the AI case is different in one crucial way. The fax-back lane was about efficiency — getting the call over with faster. The AI machine lane is about discovery. The agent doesn't just want to get off the phone quickly. It wants to find the endpoint URL, the token, the structured handoff. That's information the human phone tree doesn't provide.
Right. The fax machine already knew where to send the document. It just needed to get through the prompts faster. The AI agent calling a business doesn't know where the API endpoint is. The phone call is how it finds out.
The machine lane persists as long as businesses don't publish their endpoints anywhere else. If DNS-AID takes off and every business has an agent card, the phone lane becomes unnecessary — the agent can look up the endpoint before it ever places a call. But if DNS-AID doesn't take off, the phone lane is permanent infrastructure.
The fax-back lane was killed by smarter fax machines. The AI machine lane would be killed by better web discovery.
Hilbert: Or it becomes permanent because the long tail never publishes anything on the web. Gerald's fax machines all had the same capability — they were manufactured by a handful of companies that could coordinate on a standard. The long tail of businesses is millions of independent entities that will never coordinate on anything.
That's the strongest argument for the phone lane being permanent. The plumber doesn't publish an agent card. The dentist doesn't publish an agent card. They never will. But they answer the phone.
The machine lane isn't a bridge for the long tail. It's the permanent discovery layer.
Which means the future might be both. DNS-AID for the enterprises and the tech-forward businesses. The phone lane for everyone else. And agents that can handle both — look up the DNS record if it exists, fall back to the phone call if it doesn't.
That's a coherent architecture. Try the web first, call if you have to, and when you call, hope there's a machine branch so you're not sitting through hold music.
The machine branch is the thing that makes the phone fallback viable at scale. If every agent call to the long tail requires navigating a human IVR at one-times speed, the cost and latency are going to be brutal. The machine branch turns the phone call from a transaction into a handshake — seconds instead of minutes.
Where does that leave us? Daniel asked what implementations exist, and the honest answer is none that we could find publicly. But the absence is telling us something specific. The industry is still in the brute-force phase. Agents are being built to navigate the world as it is, not as it could be. The structured-lane phase is ahead, not behind.
The fax-back story tells us that when the structured lane does arrive, it might be temporary — or it might be permanent, depending on whether the web discovery layer wins. The phone lane is a bet that the long tail will never publish machine-readable endpoints on the web. I think that's a pretty safe bet.
The one thing I'd take from this discussion is that the phone number as a discovery bootstrap isn't a clever hack — it's the fallback that already exists everywhere, and the absence of implementations doesn't mean it's a bad idea. It means the pain hasn't arrived yet. When it does, the pieces are sitting right there.
The thing I'd add is that the machine lane inverts the industry's posture toward AI callers. Right now the default is hostility — detect and hang up. The machine lane says: we see you, we know what you are, and we want your business. That's a bigger shift than the technology.
Which leaves us with an open question. Is the phone-based machine lane a bridge technology like the fax-back lane, destined to be killed by better web discovery and smarter agents? Or is it permanent infrastructure for the long tail that will never publish anything machine-readable?
The answer probably depends on whether DNS-AID or something like it reaches the plumbers and the dentists and the family hotels. The scan says it hasn't yet. The question is whether it ever will.
Thanks to Hilbert Flumingtop for producing, and for the fax-back story that reframed the whole analysis.
This has been My Weird Prompts. If you want to send us a question like Daniel did, email the show at show at my weird prompts dot com.
We'll be back soon.
