Twilio is excellent infrastructure. It's also human infrastructure.
This isn't a criticism of Twilio. They built one of the most developer-friendly APIs in the history of technology. The problem is that what they built was a well-engineered abstraction layer over carrier infrastructure — and carrier infrastructure was designed for humans.
What Twilio actually is
Twilio is an API layer over carriers and messaging platforms. When you use Twilio to send an SMS, you're using Twilio's abstraction over carrier A2P networks. When you use Twilio's voice API, you're using Twilio's abstraction over PSTN/WebRTC carrier infrastructure.
Twilio didn't design the underlying systems. They made them accessible to developers. That's genuinely valuable.
But accessible doesn't mean appropriate. The rate limits that Twilio exposes are carrier rate limits. The reputation model that determines whether your messages get delivered is the carriers' reputation model. The trust framework that STIR/SHAKEN provides is a carrier-level framework.
All of these systems were designed with one assumption: the entities communicating are humans.
The rate limit problem
Twilio's A2P SMS rate limits:
These numbers come from the carriers, not from Twilio. The carriers set them based on their estimate of legitimate human-speed outreach. A dialing center making sales calls can do about 200 contacts per rep per day. Short codes are for high-volume campaigns that are manually managed and reviewed.
An AI agent doing real-time order confirmations in an e-commerce workflow can exceed 200 SMS in the first hour of a busy day. The carrier doesn't know or care that this is a legitimate workflow. The limit was set for a different world.
Twilio can't change this for you. They're bound by the same carrier agreements everyone else is.
The registration problem
Before you can use Twilio for agent SMS outreach, you need to:
1. Register a 10DLC brand (1–3 weeks for carrier approval)
2. Register a campaign (add another 1–5 weeks)
3. Potentially appeal a rejection (add another 2–4 weeks)
Twilio doesn't control this process. They submit your registration to The Campaign Registry, which submits it to the carriers, which review it on their own timeline.
Your agent can be built and running in hours. The permission to send its first SMS takes weeks. Twilio can't change this.
The identity problem
When you give your agent a Twilio number, you're giving it a human-era identity. The number appears in recipient caller ID without any indication that it's an AI agent calling. There's no mechanism in the PSTN to signal entity type.
Under the EU AI Act and emerging US legislation, AI agents communicating with humans may have mandatory disclosure requirements. Caller ID says nothing about who — or what — is calling. Twilio provides no mechanism to address this because the underlying protocol provides no mechanism.
The reputation problem
Twilio's shared number pools share reputation across all their customers. When you buy a long code from Twilio, you don't know its history. If the previous user ran a spam campaign, you're starting with compromised reputation.
More importantly, Twilio's reputation management — monitoring complaint rates, rotating numbers, managing blacklist risk — is the customer's responsibility. There's no infrastructure-level reputation management that scales with agent volume.
What "built for agents" means
The difference between Twilio and agent-native communication infrastructure isn't just better APIs or higher rate limits.
It's a different identity model: cryptographic, not possession-based. It's a different compliance model: enforced at dispatch time, not the legal team's problem. It's a different session model: cross-channel context as a protocol feature, not custom engineering.
Twilio gave developers access to the carriers. What agents need is infrastructure that was designed for agents — not carrier infrastructure with a better API on top.
This is the same difference as between "a very fast dial-up modem" and "broadband." The underlying architecture matters, not just the throughput.