Cadence RCS · CARRIER LAUNCH

Your RCS agent is approved and still reaches nobody

Google approving your agent and your agent being able to message a person are two different events, separated by a commercial agreement Google does not broker. Here is what sits between them, what the API actually returns, and what reaches a real handset today.

Written from taking an agent from creation through brand verification to a launch request, against Google's live API. Updated 26 August 2026.

The number that reframes the whole thing

GET /v1/regions returns every carrier Google can route to, each with a managementType. Called against a live partner account, it returns 154 regions worldwide: 25 Google-managed, 129 carrier-managed.

The US breakdown is the part that matters:

Google-managed — 1–3 business days	Carrier-managed — needs a direct commercial agreement
C-Spire Google Fi	AT&T T-Mobile Verizon Tracfone · Dish · Spectrum · Xfinity · and others

All three major US carriers are in the right-hand column. Google's own wording for that column:

Carrier-managed carriers operate their own approval process and charge for delivery of RBM messages to their subscribers. You need to have a commercial agreement in place directly with these carriers before you can deliver RBM messages to their subscribers.

So a brand-new Google RBM partner, with an approved agent and no carrier paper, has a reachable US footprint of C-Spire and Google Fi. That is a rounding error of subscribers.

Google does not broker carrier access. We asked.

The obvious question is whether partner status carries any standing with carrier-managed networks — an introduction, a contact, a queue. We put it to rbm-support@google.com directly. The answer, paraphrased from their reply:

No brokering of any kind. No introductions, no contact details, no standing conferred by being an approved partner. Partners are expected to establish their own commercial agreements with carriers directly.
You may submit a launch request with no agreement in place. It is the sanctioned way to start that conversation. Whether the carrier launches you is between you and them.
Routing via an aggregator is the normal path, and they named the usual ones. For carrier-managed networks, a direct contract with either the carrier or an aggregator is required to handle local routing and billing.

This is worth stating plainly because the marketing around RCS does not: nobody reaches AT&T, T-Mobile or Verizon through a Google partner account alone. Every provider advertising fast US RCS is either holding carrier paper or sitting on somebody who does.

The two launches are not the same animal

Most published guidance quotes a single timeline for carrier launch. There are two, and the gap between them is months.

Google-managed clears in 1–3 business days, assuming brand approval returns within 24 hours and the submitted assets are accurate and reachable. The agent becomes reachable roughly 30 minutes after approval.

Carrier-managed is where the multi-week figures come from, and the clock does not start until you have an agreement. If you have read "RCS carrier approval takes 6–16 weeks" and concluded RCS is slow, that number describes a path you may not even be on.

Reachability is per carrier, not per agent

An agent launched on one carrier reaches that carrier's subscribers and nobody else. There is no global "launched" state. This is the single most common misreading of the model, and it means your delivery rate is a function of which carriers your recipients happen to use — something you do not control and usually cannot see.

The verification deadlock

This one costs days and reads like a bug in your integration.

Brand verification confirms that an authorised representative of the brand agrees you may send on their behalf. You submit the verification information before your first launch request. But verification itself only happens during launch approval — Google or the carrier emails the brand contact as part of reviewing the launch.

So if you wait for the agent to read verified before requesting launch, it will sit at submitted forever. The real prerequisite for a launch request is submitted, not verified. We deadlocked on exactly this: our launch call refused until verification completed, and verification never started until a launch was requested.

Two other things about verification that bite

An individual employee address, never a distribution list. support@ or info@ is a rejection. This is machine-checkable and worth checking before you submit.
Google-managed contacts the brand once and stays verified for future Google-managed launches. Carrier-managed means every carrier may contact them separately — so a brand contact who ignores email becomes a silent, repeated failure with no signal on your side.

What the launch questionnaire asks for, which you probably are not collecting

Launch is a questionnaire in the Developer Console, and it cannot be edited after submission without going through RBM support. There is no cheap correction, which makes every answer worth getting right once.

Target countries and carriers
Name, email and phone for the points of contact responsible for the agent — a title is required too, and its absence is a refusal that reads as a generic validation error
What actions or events trigger messages
The types of interactions the agent will have
The exact message you send when a user opts out — the literal text
A way for a reviewer to test it. Google prefers a screen recording at a public URL over written instructions, showing the declared use case and clearly demonstrating STOP working

Most onboarding flows collect a website, a logo and a use case. None of the above is in that list, and all of it is needed at submission time.

The multi-use trap

If you register an agent as Multi-use but launch demonstrating only one use case, you must declare that in the questionnaire and then prove you launched the second within six months, or request an extension inside that window. Miss it and the agent is converted to single-use, permanently reflecting whatever it launched with.

Use case is also fixed at agent creation. It cannot be changed afterwards.

AT&T is not on Google's cloud

AT&T handles business RCS through its own gateway rather than routing through Google's infrastructure. Practically, that means AT&T reachability is a separate integration concern from every other carrier, and allowlisting a test number there is a manual process that goes through whoever holds the AT&T relationship — not through the API you use for everyone else.

If you are testing carrier reach and AT&T behaves differently from Verizon for reasons you cannot find in the API, this is why.

So what actually reaches a phone today

Three things, and only three:

Allowlisted test devices. These work on an unlaunched agent, over real RCS, on real hardware — including iPhones, which have rendered verified agent messages since iOS 18.1. This is the honest way to demo and to test. The limits are Google's and they are not resettable: roughly 20 invites per agent per day and a couple of hundred for the agent's lifetime. Spend them on numbers that will be used, not on smoke tests.
Google-managed carriers. Real launch, days not months, genuinely small subscriber base in the US.
An aggregator's carrier agreements. The normal path, and the one Google names. Expect a contract with a minimum commitment, per-brand vetting handled through a third-party framework, and carrier-levied setup fees that are charged per brand and per agent rather than per message.

The pricing consequence, if you are building a platform

Carrier vetting costs are per brand, one-time, and paid before a single message goes out. Per-message pricing can never absorb them: a brand sending a few hundred messages a month will not recover a fixed onboarding cost within any horizon you would plan against. If you are onboarding many brands rather than running one large sender, that shape forces a platform fee or a setup fee. It is not a negotiating position — it is arithmetic.

What you cannot undo

RCS has an unusual number of one-way doors, and they are not flagged as such in the flow.

Agent deletion is deprecated. An agent created by mistake is permanent. Archiving hides it; nothing removes it.
Hosting region and use case freeze at creation.
Artwork freezes when verification is requested. Whatever Google fetched at that moment is what your agent looks like forever, absent a support ticket. Check what your CDN serves rather than what you exported — an image optimiser sitting in front of your origin can re-encode a logo in transit, and Google fetches the CDN copy.
The launch questionnaire cannot be edited after submission.

If you take one thing

Approval and reach are different states, and almost everything written about RCS conflates them. Before you plan around a launch date, call the region list and read the managementType of the carriers your recipients actually use. That one field tells you whether you are days away or negotiating.

We built the pre-submission check we needed

Cadence validates a brand against the things that get RCS submissions rejected — role mailboxes, domain age, entity mismatches, artwork that Google will reject or silently re-encode, missing consent disclosures — and rehearses agent creation without creating anything. Run it free, no account. It is the tool we wrote because we kept finding these the expensive way.