Your Agent Can Deploy in Seconds. Your Phone Number Takes 6 Weeks.

Here's a timeline that every team building with AI agents has lived through:

Day 0: Agent is working. The demo is impressive. You're ready to go to production.

Day 0 + 2 hours: You realize the agent needs to send SMS. You sign up for Twilio.

Week 2: A2P 10DLC brand registration submitted. Waiting for carrier review.

Week 5: Campaign approval received (first pass rejection, resubmission, second approval). SMS live.

Meanwhile, your competitor who started 3 weeks earlier has been building market position the entire time.

The regulatory wall

The gap between "agent deployed" and "agent allowed to communicate" is not a technical problem. It's a regulatory one — and the regulations were written for humans.

These timelines exist because regulators were thinking about human-speed mass outreach — the kind where companies hire call centers and blast campaigns. They were not thinking about an AI agent that needs to send a single follow-up SMS in the context of an ongoing workflow.

The workarounds are worse than the problem

When teams hit this wall, the instinct is to find workarounds:

Using personal numbers: Attaching the agent to a founder's or employee's number. This works for a few hours. Then it gets flagged. Then the person's actual contacts start having delivery issues. Then someone's real phone number is burned.

Using shared number pools: Buying blocks of numbers from a reseller. Cheaper, faster. Also means you're sharing reputation with every other agent that used those numbers. You inherit their spam history.

Using unregistered A2P: Sending SMS without proper registration. Works briefly. Then carriers throttle it to zero, or block it entirely, or the FCC issues a notice.

Every workaround either fails immediately or creates a liability that surfaces later at the worst possible moment.

During the wait, the agent is already running

Here's the part that makes this genuinely painful: you've deployed the agent. It's running. It's billing you for compute. It's doing its job — except the communication piece, which is the whole point.

Your agent can reason, plan, access databases, call APIs, and make decisions. But it cannot send a text message, because a carrier registration process that was designed for humans in 2017 hasn't been completed yet.

What the right infrastructure looks like

The right answer isn't a faster registration process. It's infrastructure that pre-handles the registration — where provisioning a communication-capable agent identity is as fast as provisioning a compute instance.

from dial import DialClient

client = DialClient(api_key="dial_sk_...")

agent = client.acn.provision(
    namespace="mycompany",
    agent_id="sales-agent-prod",
    capabilities=["voice", "sms", "email"],
    policy={"disclosure": "required", "consent_model": "tcpa_express_written"}
)

# T+10 seconds:
# agent.phone:  +14155551234 (purchased, active, ready to call/SMS)
# agent.email:  [email protected] (active immediately)
# Compliance policies: enforced at infrastructure layer

Ten seconds. Number purchased. First call made. First SMS sent and received.

This is what the infrastructure should look like: the complexity lives in the platform, not in the registration queue. Your agent communicates the moment it's ready to — not six weeks later.

The six-week wall isn't a bureaucratic nuisance. It's evidence that the entire regulatory and infrastructure stack was designed for a world where agents don't exist.