Leed Assistant

The Leed Assistant does not only answer questions about your workspace. It calls tools against it — searching pages, resolving page types, drafting a page, creating a campaign deliverable, pulling analytics and drawing the chart in the conversation. Everything it does goes through the same API routes the CMS itself calls, under your identity.

That is the whole reason for the two rules that shape this page: only an Administrator may talk to it, and some of what it tries stops and waits for you.

Who can use it

The gate is enforced twice, in two places, on purpose.

On the server, every route under /api/ai/assistant/ — sending a message, approving a parked action, listing a session’s actions, resolving the current view — sits behind the administrator validator. On the client, the assistant provider is mounted only when the signed-in user is an administrator, and the chat panel refuses to render without it.

What a non-administrator actually sees is not an error and not a paywall. On the page editor’s AI tab, an honest empty state: “The AI assistant isn’t available for your account on this page.” No composer, no upgrade button.

Where it lives

The assistant runs from the page editor’s right-rail AI tab, scoped to the page you have open — the panel is headed Scoped to this page, so you never have to tell it which page you mean.

What it can do

The assistant draws on the same shared tool registry the Operator MCP does, and each tool declares which surfaces may see it. Most tools are visible to both. A handful are visible only to the assistant, and a larger group is visible only over MCP — the split, tool by tool, is in the Operator MCP tool index.

Three of the assistant-only tools are worth knowing by name, because they are the reason the chat feels different from a client connected over MCP:

• get_current_resource reads whatever you are looking at. The assistant is told your current URL, resource type and resource id passively in its system prompt, so “rewrite this page’s summary” resolves without you naming the page.
• suggest_next_steps renders two to six short, clickable chips at the end of a turn. Clicking one sends it as your next message.
• get_analytics draws a chart inline in the conversation instead of returning rows of numbers.

None of the three has any meaning over MCP — there is no “current view” in a headless client, no chip to click and no chat to draw into — so none of them is exposed there.

Two risk tiers, not three

Every tool carries exactly one of two risk tiers. There is no medium tier, and there is no per-workspace setting that moves a tool between them.

There is one more case, and it is deliberately conservative: a tool call the registry does not recognize is treated as high risk and parked. If a model ever emits a tool name that does not exist, the outcome is a card you have to approve, not a silent dispatch.

Note that low risk means auto-run, not harmless. create_page_draft and update_menu_draft are low-risk and they write real drafts to your workspace. What they cannot do is make anything live.

The approval card

When a high-risk call parks, three things happen at once. A row is written to the audit trail with status pending and a freshly generated approval token. The model is told awaiting_user_approval and the id of the parked action, so it stops rather than pretending the work is done. And a pending-action card is streamed into the chat.

The card carries the tool’s human title (“Publishing page”, “Deleting form”), a Preview disclosure holding the exact JSON arguments the model proposed, and two buttons: Approve and Skip.

Press Approve and the parked arguments are dispatched to the real route, exactly as the model proposed them — approval does not re-open them for editing. The route enforces your RBAC permissions on the way through, so approving something your role does not permit fails at the route rather than succeeding because you clicked a button. On success the action’s status becomes approved and the result flows back into the conversation. Skip dismisses the card in the conversation — nothing is dispatched, and the parked action is simply left to expire.

What parks

Thirteen tools park, and they are the same thirteen an MCP client is never shown at all — which is the cleanest way to describe the difference between the two surfaces. The assistant can run them, with your explicit approval each time. A connected MCP client cannot call them by name at any permission level.

Every one of these is a publish, a delete, or an approval — the three classes of action that are hard to take back. MCP tools: publishing and users covers the same set from the MCP side, and explains what a connected client does instead.

stateDiagram-v2
    direction LR
    state "Model emits a tool call" as call
    [*] --> call
    call --> auto_run: riskTier low, route returned 2xx
    call --> errored: riskTier low, route refused or failed
    call --> pending: riskTier high, or the tool has no registry entry
    pending --> approved: you press Approve
    auto_run --> [*]
    errored --> [*]
    approved --> [*]
    note right of pending
        Nothing is dispatched while an action
        sits here. Skip dismisses the card;
        the approval token expires 60 minutes
        after the card appears.
    end note

Those state names are values of the audit row’s status column, so if you need to know how a parked action ended, that is the field to read.

Limits

Twenty messages per five minutes, per user. The count is your own user messages in a rolling five-minute window across every chat session you have open, so splitting work between the Chat tab and the editor’s AI tab does not buy you more. Over the limit, the request comes back 429 with a retryAfterMs telling the client how long to wait.

The assistant runs on a larger, hosted reasoning model than the one-shot helpers behind page summaries and alt text, which is why its first token takes noticeably longer to arrive and why a turn that calls several tools can run for a while. A turn that is still working shows a spinner on the action card rather than a blank chat.

Everything else the assistant can and cannot do is inherited from your role rather than set here: the connection has your permissions and nothing more.

What is recorded

Every tool call the assistant makes writes a row to the AI action log with source set to assistant — the tool name, the full arguments, a summary of the result, the record count where one can be derived, the risk tier, the status, your user and company, and the chat session it belonged to. Auto-run calls, parked calls, approvals and failures all land in the same place.

Your prompt does not. The log records the tool calls the model decided to make, not the natural language you typed to provoke them.

How Leed’s AI is guarded has the full shape of that row, and the four layers of enforcement that sit in front of it. The editor’s own AI shortcuts are a separate feature with separate permissions and a separate audit story — those are covered in AI in the editor.