Every walkthrough, action and process the assistant can offer

Actions explains the three tiers and the two allowlists. This page is the contents of all three catalogues, by key, so you can answer "what exactly is ticked?" without reading a React file.

Everything here is read-only data shipped with the build. There are nine catalogues; the three the customer assistant can offer are what this page spells out, and the rest are here so the numbers agree:

The console at /admin/ai/support/workflows fetches the customer three at page load:

Read this first: two of the three tiers are gateway-only

The three actions

An action is a single reversible, non-financial change. The model may propose one from this fixed list and nothing else; the customer reads a constant description and confirms it, and the write then happens through an ordinary authenticated route under the customer's own session. The model executes nothing, and no action takes a parameter from the model — every value a runner uses is derived from the confirming user's session.

requiresStepUp is false on all three, and the console shows the flag rather than assuming it. None of them changes an authentication factor or moves value.

Three things worth knowing before you switch actions on:

• cancel_pending_kyc starts a 24-hour cooldown. Setting the application to REJECTED is what the submit route's rejection check reads, so the customer cannot submit for that level again for a day. The description the customer confirms says exactly that. It is still usually a good trade — a reviewer rejection starts the same clock — but it is the reason this one is behind a modal rather than a single tap.
• Verification emails are capped at three per account per hour. Over that, the customer gets a plain sentence rather than an error, and is offered a person.
• An offer expires after 24 hours (PROPOSAL_TTL_MS). A transcript is readable forever; without an expiry a customer scrolling back through an old conversation could confirm an action proposed for a situation that no longer exists.

The nineteen processes

A process is a sequence over the same action allowlist, plus navigation. There are no new runners: an operation step runs the very definition above, a navigate step opens a page and writes nothing, and a guide step runs a walkthrough and writes nothing. The model picks which process; it does not compose, order or describe the steps, and after the first step it is not in the request at all — the confirm route writes the next step itself.

aiSupportWorkflowKeys is the allowlist and empty means none.

Two of the forex entries are genuinely different products: start_forex_trading needs the forex_trading extension (the multi-asset terminal), start_forex_investing needs forex (managed plans). An install can have one and not the other.

Eleven of the nineteen are gated, and the row is still shown

Nine name an addon in requires.extension — ico, ecommerce, copy_trading, forex, forex_trading, p2p, mlm, staking, dex — and two name a platform setting: binaryStatus and investment. availableWorkflows() drops them when the addon is not installed and enabled, or the setting is off.

The console still lists them, but it only reports the addon half of that. installed is derived from requires.extension alone, so a process whose addon is absent comes back installed: false: the row is dimmed, its switch is disabled, the badge naming the addon turns to a warning tone, and a link to the product page appears where a store slug is known.

The two setting-gated processes are the exception, and it is worth knowing before you go looking for a warning that is not there. start_binary_trading and start_investing name a setting rather than an extension, so they have no requires.extension and always serialise as installed: true — even when the setting is off. Their rows are never dimmed, their switches stay live, and the badge naming binaryStatus or investment is drawn in the same neutral tone either way. Ticking one saves happily and still offers nothing, because availableWorkflows() reads the setting at request time and drops the process when it is off. If one of those two is ticked and never appears, check the platform setting itself — this screen will not tell you.

Hiding an unavailable process is the tempting choice and it is wrong twice: an operator who cannot see it cannot discover it exists, and a missing row is indistinguishable from a build that does not ship it.

A workflow abandoned mid-way expires after seven days (WORKFLOW_TTL_MS) — longer than a single offer, because a process legitimately spans days. See Scheduled jobs for why that expiry has to be a sweep and not only a lazy check.

The twenty-one walkthroughs

A walkthrough opens a page the customer's own session may already open and points at the controls on it, one stop at a time. It writes nothing, reads nothing about the account, and never fills anything in — it says which box, and the customer types.

aiSupportGuideKeys is the allowlist and empty means all.

Four of them carry no stops of their own. The binary, spot pro, forex and swap terminals each shipped an onboarding tour long before this addon existed; those guides name the existing tour and the frontend starts it, rather than authoring a second, worse tour of the same screen that drifts the first time either changes.

Walkthroughs carry no requires field. Their gate is their route's gate: each is pre-flighted through resolveAction, the same call the navigation tool makes, so a guide for a page an addon does not provide — or that this particular customer's verification level cannot enter — is never offered. That is per customer, not only per install.

The console shows every stop's wording, not a count. A stop's text is a constant the customer reads while something on their screen is highlighted; "put your wallet address here" aimed at the wrong field is a lost deposit, and it is your product being described, so you are the one who has to be able to check the words.

Why the two allowlists point opposite ways

The nine tools behind all of it

These are what the model is actually offered. Every one reads the customer id from the authenticated session — no tool schema accepts a user id, because a tool that took one would be a lateral-read primitive one prompt injection away. None of them mutates anything.

A tool that cannot run is withheld from the prompt, not merely refused when called. A model shown a tool it will always be refused for offers it in prose — "I can resend that for you" — and then nothing happens; the refusal is invisible to the customer and reads as the product being broken.

Individual agents can narrow this further with their own tool list — see Agents.

The nine areas of get_my_activity, and what gates each one

Each area is a separate reader with its own gate, and the tool's area enum is built from the ones this install actually has. An area that is not available is not in the enum and is refused area_unavailable if a model names it anyway.

Three of those are worth reading twice, because each is a place an operator looks for the wrong thing when the assistant says it cannot see something:

• investments and binary are gated on a platform setting, exactly like the start_investing and start_binary_trading processes above. There is no addon to install and no addon to check. If the assistant will not discuss a customer's investment plans, the switch is investment on the platform settings screen.
• affiliate needs the mlm extension. The area key and the addon name are different words for the same product, and only one of them is searchable.
• orders is ungated, so the tool is never dropped for want of an area — the enum shrinks instead. "No areas at all" is not a state this addon reaches.

The catalogue is cached for a minute and sorted, because it lands in the prompt prefix the provider caches on: an order that wobbles between requests turns every cache read into a write.

aiSupportAccountToolsEnabled, precisely

This is the Super-Admin switch on the Guardrails tab labelled Account tools enabled, and it ships on. Turning it off is "docs-only mode": the three tools marked Yes above are dropped from the tool spec and refused again at call time, so nothing about any customer's account leaves the install for a model. The assistant answers from documentation alone.

The three propose tools have their own gates, and none of them is this one: propose_operation and propose_workflow on actionsAvailable(), propose_guide on aiSupportGuidesEnabled plus at least one walkthrough this customer can reach.

All three of aiSupportOperationsEnabled, aiSupportWorkflowsEnabled and aiSupportWorkflowKeys are Super-Admin only, and the Actions console is where they are changed. See All settings for the full protected list and Permissions for who can open the screen.

The operator's four catalogues

None of the above is what the assistant on the Handbook screen works from. That surface has its own four catalogues, sharing no entries with the customer ones, and the operator's own assistant is where they are described. The counts, so this page and that one agree:

All four are dark until aiSupportAdminAssistantEnabled is on, which ships off and only a Super Admin can change. And all four are filtered against the asking administrator's own permissions on every request, so the assistant is never a second, weaker door to a console that would have refused them.