What is an RCS agent? The practical difference from RCS verified sender

RCS agent

It is not simply “the RCS phone number.” In the RCS for Business model, the agent is closer to a branded application identity.

What belongs to the agent

An agent can carry or reference information such as:

• brand/business identity
• agent display name and visual assets
• declared use-case category
• configuration needed for messaging
• launch/verification relationships
• webhook/backend integration
• conversation behavior and supported journeys

Google’s current documentation describes use cases including OTP, transactional, promotional and multi-use configurations. The declaration matters because the experience reviewed for launch should match what the agent actually sends.

Creation is only the first control-plane step

Creating an agent gives the business a configured object to test and prepare. It does not automatically create production reach. A useful lifecycle is:

1. Create the agent and declare its use case
2. Configure branding and backend integration
3. Test message and event handling
4. Verify the brand/authorized relationship
5. Submit launch information and opt-out behavior
6. Launch on specific carrier/network coverage
7. Operate while monitoring delivery, user feedback and policy state
8. Expand coverage by adding further carriers/regions where supported

This is why one global agent_active flag is inadequate. An agent can be real and verified but not launched for the carrier serving a particular recipient.

The backend conversation loop

At runtime, the agent’s backend needs to handle more than outbound sends. Typical events include:

• user messages
• suggested-reply/action interactions
• delivery/read outcomes where available
• unsubscribe or subscribe events as the platform rolls them out
• errors showing that a user is not RCS reachable or a feature is unsupported

The message handler normalizes these events into conversation state and preference state before deciding what to do next. For example, a user tapping “Change delivery day” can generate an action that the backend maps to an order workflow. A user sending STOP should update opt-out state, not merely generate an automated “Sorry, I didn’t understand” reply.

One agent can still have several launch states

Launch is scoped by geography and carrier/network. The backend should be able to answer:

• Is this agent verified?
• On which countries/carriers is it launched?
• Is this recipient reachable through one of those launched networks?
• Which capabilities are available for this user?

This is control-plane data that should be cached carefully and refreshed when platform status changes. If a platform stores only “agent launched on 2026-06-01,” it may incorrectly assume that launch covers every recipient worldwide.

Agent use case affects the experience

A narrowly transactional agent can be easier to reason about than a multi-use agent because the allowed content is more constrained. A multi-use agent can support several communication purposes but also demands stronger internal classification: which message is promotional, which is essential, and which permission/opt-out rules apply?

Google’s current RCS policy includes brand-level promotional revocation expectations. That means a brand with several promotional agents should not treat them as independent escape hatches after a user opts out. The agent model needs a link back to the owning brand and the brand-level preference system.

Opt-out is a first-class agent behavior

Google’s launch documentation requires a working STOP/opt-out flow for review. Current event documentation also describes built-in unsubscribe interactions and webhook behavior. The backend should therefore treat opt-out handling as part of the required agent protocol:

1. receive the opt-out event or equivalent user text
2. identify the brand and relevant message purpose
3. persist the revocation
4. stop non-essential messaging in the affected scope
5. acknowledge where appropriate
6. prevent other workflows from re-enrolling the user accidentally

Do not implement STOP inside only one chatbot flow. The preference update has to reach the shared send gate.

Agent versus sender versus conversation

These 3 objects are easy to confuse. Agent: the business application identity and configuration. Sender/network route: where that agent has been approved/launched and can reach users. Conversation: the user-specific interaction state and message history.

One agent can have many conversations. One agent can also have different launch coverage across carriers. The same user can move between capability states over time. Keeping these objects separate makes routing and debugging far easier.

Fallback belongs around the agent, not inside its identity

When a user is not RCS reachable, the business may fall back to SMS or another channel. That does not mean the RCS agent “becomes” an SMS sender. The orchestration layer should choose another route and apply that channel’s independent sender registration, consent and timing rules.

This separation prevents identity leakage: an approved RCS agent is not evidence that an arbitrary SMS long code or toll-free number is approved for the same traffic.

Agent configuration should be versioned

Brand assets, declared use case and conversational behavior can change. Keep configuration versions and the platform status associated with them so a later rebrand does not erase what reviewers approved when the agent first launched. For high-integrity operations, distinguish:

• local draft configuration
• configuration submitted for verification/launch
• currently approved production configuration

That prevents an unreviewed local edit from being mistaken for a live approved state.

Webhook security is part of agent integrity

The agent backend turns inbound events into customer actions, so webhook handling should authenticate the platform/provider request according to the current integration method, reject replay where appropriate and process events idempotently.

Preference-changing events such as unsubscribe deserve especially careful handling. A forged inbound event should not be able to suppress arbitrary customers, while a genuine event should not be lost because the same webhook is retried.

Multi-tenant platforms need strict ownership boundaries

If a SaaS provider manages agents for many merchants, map every incoming event and outgoing send to the owning merchant before reading customer data or consent state.

Never infer ownership only from the recipient number. The same user can legitimately talk to several brands. Resolve the agent/business identity first, then the merchant-specific conversation and preference record. This is also why brand-level promotional opt-out means brand-level, not “all tenants on the SaaS platform.”

What does this page teach beyond a generic glossary definition?

It teaches an RCS agent as a control-plane identity with lifecycle and coverage, not a universal sender. Creation, brand verification, per-network launch, recipient capability and conversation state remain separate objects that the orchestration layer combines at send time.

Worked example

A shoe brand creates a promotional agent with rich product cards. The agent passes brand verification and is launched on Carrier A in the US. The same agent has not yet launched on Carrier B. 2 opted-in customers receive the campaign:

• Customer 1 is on Carrier A and RCS-capable. The agent can send the rich campaign if the message and permission gates pass
• Customer 2 is on Carrier B. The agent object exists and is verified, but the launch gate fails for this recipient. The system must choose an allowed fallback or skip

The correct debugging statement is not “RCS is down.” It is “this agent is not launched/reachable for this recipient’s route.”