The console
The nine AI Support screens, grouped by when you use them — the three you open during a shift, and the six you sit down to change. Includes what each one answers and which permission it needs.
The console is at /admin/ai/support and its navigation is grouped by when
you use a screen rather than by what it technically is.
During a shift
Three screens, all top-level so they are one click away: two because somebody is waiting, one because something is stuck and you need to know what to check.
| Screen | The question it answers |
|---|---|
| Overview | Is it working, and what is it costing me? |
| Live Inbox | Somebody is waiting — what did the assistant say, and should I take over? |
| Your own assistant | How do I run this platform, and what needs me right now? |
Your own assistant is labelled Handbook in the console navigation and
lives at /admin/ai/support/handbook. It is the one screen here that is not about
your customers: it answers from the operator corpus — install, configuration,
administration, troubleshooting — rather than from the customer knowledge base the
other screens curate, which is why it is not filed under Knowledge.
It also reads this install's live state, opens the right admin screen for you, walks you through thirty-four procedures, and can offer six platform actions you approve. Everything it reaches is bounded by the permissions on your own role, so it is never a way to see or do something the console would refuse you.
It is gated on view.ai.support.handbook for the documentation half and
access.ai.support for the live half, and every question is a billed provider
call metered against the same budget your customers' answers come out of — it
returns 429 when that budget is spent, exactly as a customer's turn does, and the
turn it writes counts towards the ceiling it just checked.
The same assistant is a panel on the right of every admin screen, mounted above the router so a procedure that walks you across four screens keeps its place.
Sitting down to change something
Nobody opens these mid-incident, so they live behind a menu.
| Screen | The question it answers |
|---|---|
| Sources | What is it allowed to answer from? |
| Gaps | What did customers ask that we cannot answer? |
| Provider | Which AI service answers, and is it connected? |
| Agents | Who is it, how does it speak, and is it sending? |
| Settings | Budgets, thresholds, retention, and where it may appear |
| Actions | What may it do to a customer's account? |
Provider first, because nothing below it has any effect without one — the model pickers on both Agents and Settings fetch their options from the connected provider, so an operator who starts at the bottom is choosing a model from an empty dropdown. Then who it is, then how it behaves. Actions last, because granting the assistant the right to change a customer's account is the decision you make once you trust the other three.
Overview
The dashboard answers one question first — is it working, and what is it costing me? — in a sentence, before any figure is read.
Two banners sit above the figures, and each appears only when it is true:
- Prompt-cache health. When the cache stops being reused the bill multiplies several times over with no error, no failed request and no log line. The reuse ratio on this screen is the only detection mechanism that exists. If it falls, read Troubleshooting.
- Open gaps. A count of the questions customers have asked that your documentation does not answer, with a Review button to Gaps. It counts real customer questions, so a fresh install shows nothing here — the onboarding problem, where the knowledge base documents the software and nothing about your fees, limits or policies, is closed from the seeded-questions banner on Sources instead.
The masthead rail underneath reports live state: which provider is answering, the mode, whether the budget still allows a call, and whether the cache has gone bad.
The Mode chip in that rail, and the readiness card at the foot of the page,
both read the platform-wide aiSupportAutonomy setting — which the engine only
consults when there is no agent. The rung actually in force is the Mode column
on Agents. See Autonomy.
Permissions
| Key | Grants |
|---|---|
access.ai.support |
Opens /admin/ai/support, the master on/off route, and the whole admin-assistant API |
access.ai.support.settings |
Read and write the Settings screen and the Actions console |
access.ai.support is a bigger key than its name suggests. Beyond the Overview
URL and the master switch it gates all eight admin-assistant routes: asking it a
question, reading its catalogue, reading pending proposals, approving an action,
dismissing one, and listing, reading or deleting your conversations. What that
assistant can then reach is filtered by the rest of your role — the approval
route re-derives each action's own permission from the caller's live permission
set — so the honest reading is "may open the assistant", not "may use it".
Every other screen is gated on a different key in
frontend/middlewares/permissions.json — the Live Inbox on view.support.ticket,
Sources and Gaps on view.ai.support.knowledge, Agents on
view.ai.support.agent, and so on. And it does not load a single figure on the
Overview itself: those come from routes wanting view.ai.support.analytics. The
full screen-by-screen list is in Permissions.
Twelve settings are Super-Admin only regardless of role. Six decide whether
the assistant speaks to customers and what it may spend: the master switch, the
fallback autonomy mode, the provider, both spend ceilings and the account-tools
switch. Three live on the Actions console and decide whether it may change a
customer's account — aiSupportOperationsEnabled, aiSupportWorkflowsEnabled
and aiSupportWorkflowKeys. The last three decide whether your own operational
state is described to a model at all: aiSupportAdminAssistantEnabled,
aiSupportAdminActionsEnabled and aiSupportAdminActionKeys.
That list is not restated anywhere: settings/index.put.ts derives it from its
own SUPER_ADMIN_ONLY plus the platform-wide PROTECTED_SETTING_KEYS, and the
Settings screen greys out exactly what that derivation produces. It used to be a
hand-maintained six-entry list, and the missing entries were a privilege
escalation — a role holding only access.ai.support.settings could tick "let it
carry a process across several steps", allow redo_verification, and give the
assistant a workflow whose first step runs cancel_pending_kyc against a
customer's verification.
They are still shown to non-Super-Admins, greyed. A control you cannot find is a control you assume does not exist, and an operator hunting for a master switch that is merely hidden files a support ticket of their own.
The Settings screen saves as one batch. If a payload contains any key you are not allowed to write, the entire save is refused — not just the offending field. That is why the greyed-out state is derived from the same list the server enforces: so you cannot click something that will silently take your other edits down with it.