Which channels may a support agent use?

Only channels where it can confirm who it is talking to, and where the customer has agreed to hear from you. Within those, what it may discuss depends on how secure the channel is: account details in a logged-in app, general help on a website, nothing personal in a public post. Outbound messages need their own consent and stricter rules.

Why do channels need their own rules?

Because the same sentence carries different risk in different places. "Your balance is 1,240" is fine in a logged-in app. Sent by text message, it may be read on a shared phone's lock screen. Posted as a reply on social media, it is a data breach. The agent's knowledge and limits can be identical across channels; what it may say must still vary.

Channels also differ in how well they establish identity. A logged-in app session has already authenticated the customer. An email can come from a spoofed address. A phone number can be faked. The channel sets the starting level of trust, and the agent must not assume more.

What may the agent do in each channel?

What extra rules apply to outbound messages?

Contacting a customer who did not contact you first is a different act. It needs a lawful basis and often consent, especially for anything promotional. It needs the customer's channel preferences to be respected, including quiet hours. And it must carry less detail than an inbound reply, because you cannot be sure who will see it.

Offers are the sharpest case. Using purchase history to make offers, and sending them through channels the customer has not agreed to, is set out in whether an AI support agent can use purchase history to make offers.

An illustrative example

Take a regional bank whose agent works in its app, on web chat, by phone and on two social platforms.

A customer posts publicly on social media: "Your app charged me twice for my rent!" The agent replies publicly with an apology and asks them to message privately or open the app's chat. It does not mention the amount, the account or anything else. In the app chat, now authenticated, the agent finds the duplicate payment, explains it, and starts the refund within its bounds.

The next day, the agent sends a text confirming the refund. The text says a refund has been made and to check the app for details. It does not include the amount, because the text may be seen by someone other than the customer.

How should the line be drawn?

Two decisions underpin the table. First, which data the agent may see and repeat in each channel, set out in how to decide which data an AI agent may see. Second, which actions are off-limits in every channel, covered in how to decide which actions no AI agent may take. The channel rules then follow.

The knowledge base should reflect them too: an article may need a different answer for email than for the app. That is part of writing a knowledge base an AI agent can use. The goal is one service across channels, not separate rules that customers can play against each other, as explained in what omnichannel support is.

What controls keep it safe?

• Channel as a condition on every capability, so an action allowed in the app is not automatically allowed by text.
• Content limits per channel, enforced by an output check that strips account details from low-trust channels.
• Preference and consent checks before any outbound message.
• Public-reply rules that block personal data in public posts entirely.
• Channel recorded on every verdict, so audits can see where each decision was made.

Where Pryme fits

In Pryme, channel is a condition inside each capability, and the customer's own limits can narrow what is allowed per channel. The verdict names the channel and the bound that decided it. More is in the AI support agent that knows when to say no.