Watch a modern browser agent work and it is genuinely impressive. It reads the page, understands the layout, fills in forms, clicks the right buttons in the right order, handles a dropdown it has never seen before. For a hundred steps in a row, it looks like it is going to nail the whole task.
Then it hits a screen that says "Enter the code we texted you," and it stops. Not because it got confused. Because there is no phone to receive the text.
This is the single most common way an autonomous agent's task silently ends -- not a reasoning failure, not a broken selector, not a rate limit. A verification step designed for a human holding a phone, handed to something that has no phone at all.
The wall was built for a different problem
Phone verification exists to answer one question: is a real, present human doing this action? For twenty years that question made sense, because the only thing capable of automating a browser was a script -- and scripts are exactly what phone verification was built to stop.
Now the thing driving the browser is an agent acting on behalf of a real person, doing something that person asked it to do: renewing their own subscription, booking a table under their own name, checking their own account balance, signing up for a service they already decided to use. The agent is not the adversary the OTP wall was built for. It is standing in for the same human who would otherwise be typing the code in themselves.
The wall does not know that distinction. It just sees no phone, and stops everything.
Why this is not a small edge case
Any agent that does something real -- not a demo, not a sandboxed toy, an agent that actually completes a task on someone's behalf -- eventually touches an account. Accounts are gated by phone verification almost everywhere: signup, login from a new device, password reset, a security check before a sensitive action, a booking confirmation.
An agent that can browse anywhere but cannot get past any of those checks can only ever do the same narrow slice of tasks: read-only lookups, form-fills that stop short of submission, browsing that never becomes action. The moment the task requires proving "a real person is doing this" -- which is most tasks worth doing -- the agent needs a way to actually receive that proof.
Without it, the honest failure mode is: the agent gets 95% of the way through a task and then a human has to take over, defeating the point of automating it at all.
Why the obvious fix doesn't work
The instinct is: give the agent a phone number. Buy a SIM, register a Twilio account, hook it up.
This runs straight into a second wall. Getting a phone number provisioned for programmatic SMS and voice use is itself a process built for humans -- business verification, carrier registration paperwork, campaign review, sometimes a multi-day approval cycle. None of that is designed to be completed by an agent mid-task. It is designed to be completed once, by a person, before the automation starts.
So the actual state of the world for most agent builders today is: a human sets up a phone number ahead of time, out of band, and hopes it is still usable whenever the agent needs it later. That is not "the agent has a phone." That is "the agent borrows a phone a human configured last week" -- brittle, manual, and completely disconnected from the moment the agent actually needs it.
What it looks like when this is actually solved
The fix is not a smarter way to guess OTP codes or bypass verification. It is giving the agent the same thing a human has: a real phone number it can receive a text or a call on, provisioned the moment it is needed, inside the same loop that is already doing the task.
# The agent hits the OTP wall mid-task and provisions a number on the spot
curl -X POST https://getdial.ai/api/v1/phone-numbers \
-H "Authorization: Bearer $DIAL_API_KEY" \
-d '{"country": "US", "capabilities": ["sms"]}'
# It enters that number in the signup form, then blocks until the code lands
curl -X POST https://getdial.ai/api/v1/messages/wait \
-H "Authorization: Bearer $DIAL_API_KEY" \
-d '{"phone_number_id": "clxxx...", "timeout": 30}'
# { "body": "Your verification code is 482913", "from": "+15005550006" }
# The agent reads the code, types it in, and keeps going. No human touched any of this.No carrier account to set up in advance. No paperwork completed by a person who is not in the loop when the agent actually needs the number. The provisioning and the verification happen in the same session as the task, because that is the only way an agent operating autonomously can actually clear the wall itself.
The legitimacy question, addressed directly
The obvious objection: doesn't giving agents self-service phone numbers just make it easier to spin up fake accounts at scale?
It would, if the use case were mass account creation. It is not. The agents that actually need this are acting on one real account at a time, on behalf of one real person who already has a relationship with the service -- renewing their own subscription, confirming their own appointment, logging into their own account from a new device. The volume pattern looks nothing like abuse: one number, one verification, one task, done.
This is exactly why the fix has to be a real, individually-attributable phone identity rather than a trick for defeating verification. A number that receives one legitimate OTP for one real task builds exactly the kind of reputation a spam number never does. The agents worth building this for are the ones doing what a human would do themselves, at the one step in the flow a human isn't there to do it.
The pattern repeats
A few years ago, the wall every browser agent hit was CAPTCHA. Browser automation tooling got good enough to navigate around it, and CAPTCHA stopped being the place agent demos died.
Phone verification is next in that sequence, and it does not get solved with better prompting or a cleverer selector. It gets solved by giving the agent the one thing it was missing: a real, working phone number, available the moment the task needs it.
If your agent's task list has a ceiling right at "enter the code we texted you," that ceiling is not a reasoning problem. It is a missing capability, and it is the one thing Dial exists to hand your agent.