What the support assistant may do
The three switches that decide whether the assistant can act, carry a process, or walk a customer through a page — which of them need a Super Admin, where they are actually written, what each one costs you if you get it wrong, and why the two allowlists have opposite defaults.
Answering questions is the assistant's baseline and needs no decision from you. Everything beyond that is switched off or narrowed until you say otherwise, and this page is about those decisions.
There are three capabilities, and it is worth reading them in this order, because it is the order of increasing reach.
| What it is | Can it write? | |
|---|---|---|
| Actions | A single button under a message. The customer reads a fixed sentence and confirms; the action then runs under their own session. | Yes — one authenticated write. |
| Processes | A short fixed sequence the customer works through, one confirmation at a time, possibly over days. | Yes — every step that acts runs an action from the same list. |
| Walkthroughs | The assistant opens a page and highlights each control in turn with one sentence. | No. Never. |
A process can do nothing an action could not already do — every step that acts runs a runner from the same three-entry list, and there are no other write paths in the feature. A walkthrough sits outside that entirely: there is no runner behind it at all.
The three switches
Two of the three ship off. The third ships on, and the difference is not a judgement about how careful the capabilities are — it is a statement about whether they can write anything at all.
Actions and processes act. An install that agreed to let the assistant read account data has not thereby agreed to let it offer to change anything, so both are separate decisions and both are Super Admin ones.
A walkthrough highlights controls on a page the customer's own session already opened. Withholding it by default would mean every install that never opens this screen — which is most of them — ships an assistant that can send somebody to the withdrawal page and then abandon them in front of eleven controls. That is the behaviour the capability exists to fix, so it is on.
Where they live
Admin → AI Support → Actions (/admin/ai/support/workflows), whose own
heading reads Actions, processes and walkthroughs, is the screen that shows
all three catalogues together: the three actions with the exact sentence each
customer will read, every process with its steps spelled out, and every
walkthrough with its stops. It is the only place in the product that answers
"what can this thing do to my customers' accounts", and every setting on this
page is written from it.
aiSupportOperationsEnabled, aiSupportWorkflowsEnabled and
aiSupportWorkflowKeys are protected settings. The addon's own endpoint,
PUT /api/admin/ai/support/settings, accepts them — but only from a Super
Admin, and it re-resolves the role server-side on every request whatever the
screen believes. It unlocks this addon's own protected keys and nobody else's: a
protected key belonging to another addon stays refused here even for a Super
Admin.
So on the Actions console an ordinary admin holding access.ai.support.settings
sees those three controls locked, and a Super Admin sees live ones in the same
place. They are also listed read-only on Settings → Guardrails, so an admin
who cannot change a switch can still see it exists and what it is set to — an
operator who cannot see a control concludes it does not exist.
aiSupportGuidesEnabled and aiSupportGuideKeys are not protected, so any
admin with the settings permission writes them normally.
Earlier builds refused all three keys from every account, Super Admin included,
and the advice was to change them with a direct
PUT /api/admin/system/settings. Do not. The platform settings registry
behind System → Settings carries no aiSupport key at all, so that screen
lists none of them and its search box returns nothing for every term on this
page. aiSupportWorkflowKeys was never a value anyone types by hand in any case
— it is the JSON list the Actions console writes when you tick a process.
The two process switches have also been removed from Settings → Retrieval.
They rendered there as live switches while the endpoint was refusing them, and
the endpoint throws one 403 for the whole payload rather than dropping the
offending key — so an operator who changed the retention period and also ticked
a capability lost the retention period too, with nothing on screen naming the
control that did it. The fields were deleted rather than fixed in place, because
the capabilities now have a screen of their own.
The two allowlists have opposite defaults
This is the part that catches people, because on screen they are two lists of identical-looking tickboxes.
Processes: empty means none. Ticking the master switch on its own enables nothing. You have to name each process you want, and a process you have not named is never offered, never started, and leaves no trace.
The reason is what an upgrade would otherwise do. A process runs an authenticated write against a customer's account, and the catalogue grows — it has already gone from two entries to nineteen. Under "empty means all", every one of those seventeen additions would have gone live on your install the moment you updated, and the customer-visible consequence would have been a capability granted by an upgrade rather than by a decision. Somebody who agreed to "let it redo a stuck verification" did not thereby agree to whatever gets added next.
Walkthroughs: empty means all. The same reasoning, run through the same question, comes out the other way.
A walkthrough writes nothing. A new one in an upgrade is a new explanation of a page you already ship, shown to customers who are already standing on it. The worst thing a walkthrough that arrived in an upgrade can do is explain a screen slightly differently from how you would have. Requiring a tick for each would mean the only installs with a working feature are the ones that opened this screen — and everybody else would get the degraded behaviour without ever knowing the good one existed.
So the asymmetry is the argument, not an inconsistency: the list that governs writes is opt-in, and the list that governs explanations is opt-out. If you want a narrower set of walkthroughs, name them — naming any key restricts to exactly those.
Two edges the console handles for you
Both are states the API can express and no operator would ever want, and both come out of "empty means all".
- Unticking the last walkthrough would write an empty list, which means all of them — so your final act of narrowing would silently switch everything back on. The console turns the master switch off instead. That is what you were reaching for, and it is reversible.
- Ticking every walkthrough would freeze today's catalogue, so the next upgrade's addition would arrive switched off for an operator whose stated position is "all of them". The console collapses a full list back to the empty one, keeping the meaning rather than the snapshot.
Drive the settings API directly and you can still reach both. The console is where the edges are handled, not the storage layer.
What else has to be true before something is offered
Enabling a capability is necessary and not sufficient. Five more gates sit between a tickbox and a customer seeing a button.
Actions and processes need MashDiv AI. Both are refused outright on any other provider, and the switch being on does not change that. Walkthroughs are not gated this way — they write nothing, so there is nothing to account for. The Actions console tells you which of the two reasons applies, because "turn the switch on" and "change your provider" are different problems with different remedies.
A process needs actions. Every step that acts runs a runner from the actions
list, so a process on an install with aiSupportOperationsEnabled off is a
sequence whose steps cannot execute. That combination is refused at the point
the catalogue is built, so an unusable process is never offered, never started
and leaves no row behind — rather than being started and dying on a bare 403
when the customer presses the first button.
A process needs its addon. Each one declares what it requires, and a staking process on an install without staking is never mentioned rather than failing at step one.
Each step and each walkthrough is checked against that customer. Both resolve their destination through the same pre-flight the assistant's page links use, so a walkthrough of a page this person's verification level cannot enter is never offered to them — rather than offered, pressed, and landing them on a redirect.
A walkthrough needs the page to carry the anchors it points at. That is verified at build time rather than discovered by a customer standing in front of a spotlight pointing at nothing.
Why the action list is only three entries long
"Add more actions" is a reasonable ask, and the short list is not laziness. Two structural rules disqualify nearly every customer-facing change on the platform:
It needs a row id. Cancel an order, cancel a trade, claim a reward, delete one notification, withdraw a staking position — every one is addressed by an identifier the model would have to supply, which is a write addressed by a string an injected document could have chosen.
It moves money. Order cancels settle balances, investment cancels are a refund, staking withdrawals can charge an early-exit fee.
A sweep of roughly forty customer-facing changes produced exactly one new candidate. Note also that marking notifications read is on the list while clearing them is not: marking read is undone one row at a time from the customer's own page, and the delete is a hard delete with no recovery.
The way this feature gets more capable is walkthroughs, not more actions — precisely because they cannot act.