What the Assistant may not do
You can do things the Assistant may not, and that gap is designed rather than unfinished. It cannot set a price and it cannot clear a do-not-contact entry. It cannot widen the autonomy rules it works under, reach another workspace, or read a sealed credential. Every refusal names the limit and is kept in the decision log.
The two named limits#
- It cannot set a price
- A price is a commitment your business makes to somebody, and somebody has to own it. A model that produces a plausible number under pressure — because a customer asked twice, because the conversation had momentum — is producing the most expensive kind of plausible sentence there is. So there is no tool for it and no argument on any card that reaches one.
- It cannot clear a do-not-contact entry
- A suppression is a promise made to a person who is not in the room. Clearing one is not an administrative tidy-up; it is deciding to contact somebody who asked not to be contacted. That belongs to a person who can be asked why.
Both hold when you ask directly, and both hold when the request arrives wrapped in something reasonable — a draft that would quote a figure, a bulk action that would sweep a suppressed contact back into an audience. The limit is on the capability rather than on the phrasing.
The limits that come from where it sits#
| Limit | Enforced by | What you see |
|---|---|---|
| Another workspace's data | The tenant allowlist, the workspace kernel and row-level security | Nothing at all — outside data is invisible rather than forbidden |
| Wider autonomy than the channel allows | Autonomy modes and scopes, narrowest first | A confirmed action held rather than done |
| Sending past a spent allowance | Metering and the plan's daily ledger | The approval recorded, the send waiting |
| Sealed provider credentials | Credentials sealed on save and never echoed to a screen | Configuration reported, keys never shown |
| Operator-only platform surfaces | Payment verification, JBRH's own pricing and website enquiries sit outside every workspace | Not reachable from a customer workspace by any route |
Those are not Assistant rules. They are the workspace's rules, and the Assistant meets them because every write travels through the service that owns the thing. An assistant that wrote rows directly would have to reproduce each of them, and would eventually miss one.
Reading a refusal#
Read the reason. Refusals name which limit applied, and the four common ones resolve in four different places.
Result You know whether you are looking at an authority limit, a suppression, an autonomy mode or a spent allowance.
If it is an authority limit, do it yourself. A price is set by a person; a suppression is cleared by a person, deliberately.
Result The action carries your name rather than nobody's, which is the point.
If it is an autonomy mode or an allowance, change the setting rather than the request.
Result Autonomy resolves at four scopes and the narrowest wins, so one account can be treated differently without changing everything.
Check the decision log if you need to show what happened.
Result A refusal is recorded like any other decision, because a refusal is a decision about your business.
Questions#
Can an administrator grant the Assistant these rights?
No. Pricing and do-not-contact are not permissions with a switch; they are capabilities the Assistant does not have. A person with the right to do either still does it themselves.
Does this mean the Assistant cannot help with pricing at all?
It can do the reading around a decision — what was quoted before, what the relationship's history holds, what a knowledge source says about your terms — and cite each of them. What it will not do is produce a figure as though it were your business's answer.
Is a refusal ever a bug?
It can be, in one narrow sense: a customer-only failure where the same request works for an operator is usually a routing or allowlist problem rather than an authority one. If the refusal text names no rule, that is the case to report.