Your own assistant

/admin/ai/support/handbook, and a panel on the right of every admin screen. In the console navigation it is labelled Handbook — this page uses the longer name because the screen is no longer only a question box over the documentation.

Everything else in this addon answers your customers. This answers you — the person who bought the platform, installed it, and has to work out on a Tuesday afternoon why a withdrawal is stuck in PENDING.

The one rule that makes it safe

It can never do or see anything your own role could not already do or see.

Every catalogue behind it is filtered by the permissions on your role, resolved from your session on each request:

• a screen you cannot open is never named to you;
• a queue you cannot read is never counted for you;
• an action you could not run by hand is never offered to you.

So the assistant is not a second, weaker door onto anything. The strongest thing it can do is exactly what you could have done by clicking — and the audit trail records that you did it.

Four things it can do

Answer

The same operator corpus the Handbook always used. Ask "where do I set the withdrawal fee" and you get the passage, with the page it came from.

Look

This is the half that a documentation search could never do. Ask "what is waiting for me right now?" and it reads the queues you have access to:

• withdrawals awaiting approval, and how old the oldest is
• deposits awaiting approval
• verification applications awaiting review
• tickets awaiting a reply
• P2P disputes awaiting resolution

It returns counts and ages, never rows. Your customers' names, amounts and destinations do not go into a prompt to answer "how much is waiting" — a number answers that completely. The screen is where the rows are, and the assistant sends you there.

Two other readers: platform health (which addons are enabled, which deposit gateways are switched on, whether the exchange is linked, what the assistant has spent) and recent admin activity (the audit trail — what changed, on which screen, and whether it succeeded). The second is gated on access.admin.audit and drops the actor's IP address before anything reaches a model.

Open

120 admin screens are catalogued, each carrying the permission its own screen demands. It gives you a button rather than typing a path, because a path typed into an answer renders as plain text.

Do — and this is the part that asks

An action is proposed, never run. You read exactly what it does, on a card whose every sentence is a constant in the platform's own code — not something the model wrote — and your click is what runs it.

A card does not wait for ever. An approval card goes stale 30 minutes after it is proposed, and a half-finished procedure expires after 24 hours; both are far shorter than the customer-side windows of a day and a week, because an administrator works inside one sitting. An expired card is refused rather than run, and both refusals end the same way: ask again, and it re-checks the platform before proposing anything. That is the whole point: an action proposed against this morning's state should not still be approvable this evening, after somebody else has changed the thing it was about.

The six actions

The list is short, and that is the honest number rather than an unfinished one. Three are maintenance and three are diagnostics — is this actually working? — which is the other shape that qualifies, because you cannot tell whether email is configured by reading a settings row, only by sending one.

Each demands the permission the screen that does the same work demands. That is copied from the route, not invented for the assistant, so whoever you have already decided may rebuild the index is exactly who may approve this — with no second grant to remember.

Why it is only six

Two rules, and nearly every admin mutation fails one of them:

It needs an id. Approve this withdrawal, reject that application, block this user. Every one is addressed by a row id the model would have to supply — and a write addressed by a string an injected document could have chosen is the one thing this design refuses categorically. On the admin side that string could name any account on the platform.

It is a judgement. Approving a deposit, resolving a dispute, granting a role. These are decisions with a person on the other end, and a "yes" button in a chat panel is not where they should be made.

The way this gets more capable is procedures, not a longer action list.

The procedures

Thirty-four of them, and this is where "do as much for me as possible" actually lives. A step that navigates writes nothing — it opens a screen your own session already has, says what it is for, and waits. So a procedure can cover any workflow the platform supports without the security argument moving an inch.

What that buys is real. Set up deposits is five screens in an order nobody documents, and the order matters: configure a gateway before its currencies exist and the screen renders an empty list, which reads as the gateway being broken. Following the procedure you never have to know that, because the sequence is the knowledge.

Seventeen addons have one, and each of those is gated on that addon being installed — an NFT procedure is never mentioned on a platform without the NFT addon. The rest walk core screens and are always offered: Set up binary options covers the core binary screens under Finance, not the Binary Engine addon.

Three addons with a console of their own have no procedure yet — AI Investment, AI Market Maker and Binary Engine. The assistant will not walk you through those, and their screens are absent from the catalogue it opens either, so it cannot even give you a button to one. Wallet Connect and Chart Engine have no console to walk through at all.

That gap costs something, because all three have exactly the ordering the procedures exist for: a market maker needs an ecosystem market before it has anything to quote on, the binary engine refuses to run until a market maker is active, and an investment plan needs a duration before it can be sold. Until they are catalogued you have to know that yourself.

The setup procedures exist because the order is undocumented and unforgiving. A product cannot be listed before a category exists. A managed forex plan cannot be sold before a term does. A native market needs its tokens first. A bot cannot trade real funds until a switch two screens away is on. In every one of those cases the screen renders an empty list, which reads as the addon being broken — and is the most common thing operators report about a new addon.

A procedure is offered only when you can complete every step. Offering one and letting you hit a wall at step three is worse than not offering it — you have already done two steps of a thing you were told you could do.

The panel on the right

It is mounted above the router, so it survives every navigation a procedure makes. A procedure that walks you across four screens keeps its step list, its progress and its next button the whole way.

It shows what is waiting, what has been done, and what is still to come. Nothing on it executes anything.

The desk strip

Across the top of the panel, above everything else, is the state of your support desk: how many conversations are in the Live Inbox, and a button to it. Beside it, a button to the assistant's Overview.

The number is the queue's depth. When somebody has asked for a person — or a colleague is part-way through a takeover — the strip turns and tells you how many are waiting, because those are the ones with a promise running against them.

Two things about it are deliberate:

• It costs nothing. The assistant could already answer "how many conversations are waiting", and answering it took a model call, several seconds and real money. A number you want on every screen should not be behind a paid question, so it arrives on a poll the panel was already making.
• It is bounded by your own permissions. The inbox count needs view.support.ticket, the Overview button needs access.ai.support, and those are the same keys the two screens themselves demand. You are never offered a button to a screen that then refuses you.

Starting a fresh conversation

New in the panel header leaves the current conversation and starts one with no history; the same button sits at the top of Past conversations, which is where most people look for it.

It does not delete anything. The conversation you left is on the server and in the history list — leaving one must never be a way to lose what it cost. Deleting is a separate button with its own consequences, described below.

It also clears an outstanding card. An approval or a procedure is not part of the conversation — it lives on the server and the panel reads it back — so starting fresh sets it aside as well, or the card would still be sitting there afterwards. Setting one aside runs nothing: only a proposal still waiting can be dismissed, so this can never withdraw something you have already approved. The audit trail keeps the row, marked as never run.

Pinning it beside the page

By default the panel floats over the admin screen. That is right for a glance and wrong for working — a procedure that walks you through a table is sitting on top of the table.

Pin gives the page up the width instead: the layout narrows, the navigation bar narrows with it, and the panel runs the full height of the screen in the gutter. Press it again to go back to floating.

While it is pinned the bar drops three things to give the navigation back the width the panel took: the logo, the search box (⌘K still opens it, and the assistant answers the same "where is…" question in words), and the label on the user/admin switch, which repeats its own icon. The menu items themselves are never touched. Unpinning puts everything back.

A small dashboard button takes the logo's place while it is hidden. On the admin bar the logo is a link to /admin, not decoration — and inside an addon console, where the menu is scoped to that addon, it is the only way back. The button appears in the same moment the logo goes, so one of the two is always there.

While it is pinned there is no close button. The panel is holding a gutter the whole layout is drawn around, so closing it would reflow every admin screen and the next reload would simply reserve the width and reopen — unpin is the way out, and it is the honest one.

• It is yours, not the platform's. The preference is stored in your own browser. Nobody else's console changes, and there is no setting for an operator to manage.
• It survives a reload without a jump. The width is reserved before the page paints, so a pinned console arrives already narrow rather than snapping a moment later — and the panel draws its own outline in that space while it works out what to show, so there is never an empty column waiting.
• Below about 1280px it goes back to floating. The panel is 26rem; pinning it on a laptop leaves too little for an admin table and on a tablet leaves nothing. Your preference is kept and simply not applied until there is room — narrow the window and the panel floats again with its close button back, widen it and the pin returns. The toggle is hidden at those sizes rather than pretending to work.

What is recorded

Every approval writes a row in ai_support_admin_action carrying who approved it, when, what it required, and what happened. Your identity is written from the approving request's own session — never from the proposal — in the same statement that moves the row out of PROPOSED.

Which makes the audit claim a query rather than an argument:

SELECT COUNT(*) FROM ai_support_admin_action
 WHERE state IN ('COMPLETED','FAILED') AND approvedBy IS NULL;   -- always 0

A crash mid-run leaves a CONFIRMED row with a named approver and no completion. That is visible, and it is the honest record of what happened — rather than a completion nobody can attribute.

Switching it on

Super Admin only, and from this screen. All three controls live here and nowhere else: Settings lists the same three keys in its Guardrails panel, locked for everybody including a Super Admin, under their raw key names and with no link out. Reading them there tells you the current state; changing them happens here — with one exception. Turning the assistant back off is not on this screen: Turn it on renders only while it is off, and no control anywhere writes the key back. That is a Super Admin sending aiSupportAdminAssistantEnabled as "false" to the settings PUT, which checks the role rather than the permission. The other two are two-way.

Every question here — documentation or live — also checks aiSupportEnabled first, so switch the customer assistant on before expecting an answer.

1. Turn the assistant on. You now get answers, queue reads, screens and procedures made of navigation. Nothing writes.
2. Turn actions on — a separate switch, deliberately. Wanting the assistant to read your platform is not agreeing to let it offer writes on it.
3. Tick the actions you allow. Empty means none, never all. The catalogue grows in upgrades, and a permissive default would hand a future release a platform-wide write you never agreed to.

While the assistant is off there is no panel and no launcher on any admin screen. Nobody on your staff sees a control they cannot use — which also means turning it off is a complete answer, not a half-measure that leaves a button behind that refuses everyone who presses it.

Conversations are kept

Every answer is a billed model call, so throwing it away is throwing away money. The panel used to hold one answer in browser state: asking a follow-up destroyed the answer you were following up on, and navigating away lost both.

Now each question and answer is written to ai_support_admin_turn, grouped into a conversation you can reopen from Past conversations on this screen or from the history control in the rail. The rail and this screen share one open conversation, so you can ask in the rail and continue here.

The last few exchanges are replayed into each new question, so "and what about deposits?" resolves against what you were just discussing. That window is bounded on purpose: every replayed turn is input tokens on the next call and every call after it, so an unbounded thread would bill quadratically.

Deleting a conversation clears its content and keeps its cost. The question, the answer, the sources and any proposal are emptied and the session row goes, so it leaves your history; the turn rows stay, carrying only their cost and their timestamp. The budget sums what every turn cost, so destroying them outright would refund that spend against your own ceiling — you could spend past your cap by tidying up. The retention sweep does exactly the same thing on your retention clock, and it runs unattended, which is why it matters more there than here.

On a demo install it does not answer for real

If NEXT_PUBLIC_DEMO_STATUS is true, every ask route returns a fixed notice before it reaches a provider — above the budget check, above getProvider(), and the approval route refuses outright.

The reason is arithmetic. A demo is open to anyone who finds the URL, every question is a real billed model call, and none of that spend buys anything. It is also silent: nothing fails, the assistant works perfectly, and the bill arrives later.

Simply disabling it would be worse. A visitor evaluating the platform opens the one feature they came to look at, finds it dead, and concludes the product does not have it. So the assistant stays visible and interactive, the whole catalogue below still renders — the screens, the procedures, the actions — and the reply says what it does on a live install and where to get trial credit to run it.

This reads the environment and only the environment. There is deliberately no settings row: a gate that could be switched off from a screen on a demo install is not a gate.

What it deliberately is not

It reads no customer account. Not one of the customer-facing account tools is wired in. Ask about a customer is the surface for that, it is gated on view.user for that reason, and it is audited per question. Keeping the two apart is what lets the permission on each be the honest one.

It does not act on your behalf. There is no autonomous mode, no scheduled action and no "just do it". Every write is one card, one reading, one click.

It is metered. The same budget as every other model call, billed per token rather than at the delivered-answer rate. Your own questions spend the same allowance your customers' answers do — hiding that would make the budget screen wrong, which is worse than the spend. It also stops for the same reasons: a ceiling reached, or a month in which some call recorded no cost at all while a cap was set, which is refused rather than assumed free. See Cost and budgets.