Subscribe to our financial-operations agent and you will notice something missing. Consumer messaging — WhatsApp, SMS, the chat channels every other agent in the workspace can reach — is marked never on that blueprint. Not "available on request". Not "requires admin approval". Never, in every workspace running that role, with no screen anywhere that offers it.
The first reaction is usually that this is paternalistic. Our customers are large organisations with competent risk functions; who are we to decide what channels their agent may use?
It is a fair objection and the answer is not what people expect. The constraint is not about trusting the agent. It is about what a ledger action has to be in order to be evidence.
The actual reasoning
A financial action needs an auditable instruction: a named counterparty, a retained record, and a channel where the instruction cannot be silently edited or deleted after the fact. A consumer chat thread is none of those three. Messages are editable, deletable, tied to a phone number rather than a verified entity, and retained at the platform's discretion rather than yours.
So the question a role scope answers is not "would this be safe?" It is "could this ever be evidence?" And for a payment instruction arriving over consumer chat, the answer is no — not because the agent might be fooled, but because the resulting record could not support the decision it produced.
Our support agent carries that same channel with no restriction at all. For a support case, the thread is the record. Same channel, same platform, opposite answer, because the artefact each role has to produce is different.
The question a role scope answers is not "would this be safe?" It is "could this ever be evidence?"
The sentence that took us six months to arrive atClasses, not vendors
Role scope is stated in connector classes — consumer messaging, moving money, the books, the customer record, social accounts, and five more — rather than in named products. This is deliberate and it is the part most likely to matter to you later.
If we listed vendors, then every new integration would be a silent widening of what a role can reach. Add a messaging product to the catalogue, and unless someone remembers to exclude it from the accountant blueprint, the accountant now has consumer messaging. The permission model would decay by default, one integration at a time, and nobody would notice until it mattered.
Stated in classes, a new vendor inherits the answer that already exists for its class. The blueprint does not need updating. There is no maintenance burden that someone can fail to perform.
Why it sits above your workspace
Role scope is set by us, when a blueprint is published, and it is identical in every workspace running that role. Customers cannot loosen it. This is the single most-questioned decision in the product.
The reason is that a bound with an exception path is not a bound. If any customer can widen a role, then "the financial-operations agent cannot use consumer messaging" stops being a property of the system and becomes a default — and a default tells you nothing about what any particular deployment actually permits. The claim only means something if it holds everywhere.
What you can always do is tighten. Every guardrail stacks on top of the platform floor, and your own ceiling sits inside your plan's maximum. The asymmetry is the point: the floor is ours, the room above it is yours.
