Last updated 30 August 2026. Written while building an MCP server for RCS and watching agents use it — including the ones that got it wrong, which taught us more.
Getting an AI agent to text you sounds like a small thing. It is not, and the reason is regulation rather than code.
US messaging providers cannot let you send to a real phone until a brand and a campaign are registered with the carriers. That is 10DLC, it involves a legal entity, a website, a privacy policy and a use-case description, and it takes days at best. RCS adds a verified brand at Google and separate approval from each carrier on top.
None of that is optional and none of it is unreasonable — it exists because unregistered messaging is how smishing works. But it means the gap between "I want my agent to text me" and the first message is measured in weeks, which is fatal to the thing you actually wanted, which was to try it.
Split the two problems. Building the conversation is a code problem you can solve in an afternoon. Reaching a real handset is a compliance problem measured in weeks. There is no reason the second should block the first.
A sandbox key should let an agent do everything except reach a phone: open a conversation, send rich content, receive typed replies, simulate an inbound answer, and read the transcript back. Every code path runs. Nothing touches a carrier, so nothing needs registering.
Then the same code sends for real once the brand clears, with one key swapped.
Most messaging APIs were designed for application code, where a human read the docs once and wrote an integration. An agent reads the docs every time, has no memory of last time, and cannot ask you a question. That changes what the API has to do.
An agent that receives 409 Conflict will guess. An agent that receives a code, a
sentence explaining the state, and a specific next call will act correctly. Every error should
carry all three, and the remediation should name a route that exists.
Some operations cannot be undone. Creating an agent at Google is permanent — RBM has no delete. Requesting verification freezes your logo and brand colour for good.
An agent exploring an API will call things to find out what they do. So one-way doors need to refuse until confirmed explicitly, and a dry run that shows exactly what would be sent without sending it. That is not a safety feature bolted on; it is the difference between an API an agent can explore and one it can only be trusted with under supervision.
When someone taps a button, the useful answer is which button, not what it said. Text is ambiguous — the same word arrives differently over RCS than over the SMS fallback, where the recipient types a number instead. An API that resolves the tap server-side and hands back a label and an index removes an entire class of parsing bug.
An llms.txt that describes the whole surface in prose, with the traps stated
inline, is worth more to an agent than a browsable reference. Write it for a reader who will act
on it immediately and cannot ask a follow-up question.
The Model Context Protocol lets an agent call your API as a set of tools rather than by writing HTTP requests. For messaging that matters more than usual, because the failure modes are invisible: a message that is refused looks the same as one that was sent, unless the tool tells you otherwise.
Tools also let you scope what is reachable. Irreversible operations can be absent from the tool list entirely unless explicitly enabled — not refused when called, but not present. An agent cannot misuse a tool it cannot see.
Not a broadcast. Broadcasts are the least interesting thing messaging does and the most likely to annoy someone.
Build something that asks a question and does something with the answer. A daily check-in that records a number. A confirmation that reschedules. An alert with two buttons that resolve to different branches. The interesting part is the loop, and the loop is what most messaging APIs make hardest, because they were built to send.
Then check what your conversation costs. Under US billing, a conversation that earns two replies triggers a flat 24-hour session; one that does not bills per message and can cost more despite being shorter. A one-question flow can never trigger. That is worth knowing while you are designing the flow, not after the first invoice.
One API and an MCP server for RCS with automatic SMS fallback. Brand onboarding, carrier readiness and the checks in this article are built in, so the failures above are reported rather than discovered.
Get a free sandbox key — no card, nothing to verify first — or read the agent-facing reference.
The operational side: why replies never arrive when sending works fine, why your bill will not match your quote, and the nine undocumented traps in Google’s API.