Setting up an agent involves registering the brand, configuring the agent’s identity and use case, and getting it verified/launched through Google and the carriers, a process a provider like SimplyRCS manages for you. Once live, the agent is addressed by an agent ID in API calls.
How an agent is structured
An agent bundles three things that are easy to confuse. First, the identity: the display name, logo, brand colour, description, and contact details a recipient sees. Second, the use case, which is the category the agent is approved for and which governs what it may legitimately send. Third, the technical binding: an agent ID that API calls address, plus the webhook endpoint where inbound messages, taps, and delivery events arrive.
Use case matters more than people expect, because it is enforced rather than advisory. An agent approved for OTP exists to deliver one-time passcodes; sending promotional content from it is a violation that risks the agent, not just the message. Multi-use combines transactional and promotional, but deliberately excludes OTP, which is why high-volume senders often run more than one agent. If the surrounding vocabulary is unfamiliar, the RCS glossary defines agent, use case, and verification term by term.
Why the agent is the unit that matters
Everything reputational attaches to the agent, not to your account. Approval, verification status, the use case, and the sending record all sit at agent level. That is why an agent is treated as an asset worth protecting: losing verification on it costs the brand treatment on every message it sends, and re-approval is slower than the original launch.
Example. A retailer runs two agents. A transactional agent sends order confirmations and delivery updates, and a promotional agent sends offers. Splitting them means a customer who opts out of marketing keeps receiving delivery updates, and a problem with promotional content cannot jeopardise the agent carrying order notifications.
What is an RCS business message?
An RCS business message is a message sent to a customer from a verified RBM agent rather than from a personal phone number. It arrives in the phone's default messaging app under the brand's name, logo and verification checkmark, and it can carry what SMS cannot: images, rich cards, carousels, suggested replies and tappable actions, with read receipts back to the sender. If the recipient's phone cannot take RCS, the same message is delivered as SMS or MMS instead.
Three things distinguish it from a plain business text. The sender is verified, so the identity on screen is drawn from the approved agent record rather than typed into the message. The format is rich, so a reminder can carry a Confirm button and a promotion can carry a carousel. And it is measurable, so the sender can see delivery, reads and taps per message. What it costs, and how the classes are billed, is on how much RCS costs; what one looks like, by industry, is in RCS messaging examples.
Every agent also carries a machine identifier of the form [email protected], which some phones show in a chat's details; what rbm.goog is explains what a recipient is looking at.
- An RBM agent is the verified brand sender: it carries the name, logo, and verification badge.
- Each agent has a use case: OTP, Transactional, Promotional, or Multi-use (which combines transactional and promotional but not OTP).
- All business RCS messages are sent from an RBM agent, addressed by agent ID.
- Verification, approval status, and sending reputation attach to the agent, so many brands run separate agents per use case.
- SimplyRCS registers the brand, configures the agent, and carries it through Google and carrier approval.