AI in Ortha

Both are off by default. Off means the routes are not registered at all — they answer 404, not a refusal.

COPILOT_ENABLED=true   # also needs a model backend — see Setup
MCP_ENABLED=true

Both surfaces call tools from one shared registry — see tools and permissions.

Where the copilot lives in the admin

• Launcher — Ask Ortha AI, in the strip under the work area at its right end, on every page inside a workspace (there since 0.9.0; before that it was an icon in the top bar). It always starts a new chat, as does ⌘J / Ctrl+J; since 0.13.0 it no longer opens a list of the open ones.
• Docked chats — several can run at once. A minimised chat waits as a pill beside the launcher that says what it is doing — working…, finished or waiting for you (with an amber dot) — and stays alive while its pill exists. Past three pills the rest fold into N more chats. While a chat waits for your answer, the sidebar’s Agents switch carries the dot too.
• Agents view — a full page at /workspaces/:id/agents, with Skills at /workspaces/:id/agents/skills. The launcher hides there. Since 0.13.0 the chats are in the workspace sidebar, in place of the content tree: Chats, New chat, a search, the chats grouped by day, and Tools (Skills, Archived). A chat carries a spinner while an answer streams and an amber dot while a run waits for your answer. Switch back to CMS and the content tree returns.
• A new chat greets you with What can I help you with in {workspace}? and up to four openers written for that workspace — from the types it holds, the skills it has on and the tools your role is offered (a viewer gets read-only ones) — with the message box right under them.

The launcher renders nothing outside a workspace, for a user without copilot:use, or when the deployment has the copilot off.

The copilot acts as its user

A run has no identity of its own. It holds exactly the permissions of the person who started it, re-resolved on every call.

• A Viewer’s copilot is read-only — no write tool is offered without the permission it declares.
• A Contributor’s copilot can draft content but cannot change who may read an entry (segments:manage, Admin only).
• Every change is audited as the person’s, marked as made via the copilot.

A write asks once, then applies

A run about to change something parks before the call and asks:

• No “always”. A standing allow-list would outlive the context it was granted in.
• “Allow for this chat” skips the prompt, never the permission check.
• A parked run waits up to five minutes. The prompt shows no clock: while it is open in a visible tab it keeps the run waiting, so only a prompt left in a background tab runs out — and then says Time ran out, so nothing was run. Unanswered = refused and audited.
• Reads never ask.

Where the tool can work out the change first — the content plugin’s three propose tools can — the prompt shows it before you answer: Ortha CMS AI wants to save 23 records as drafts, then the change card the receipt will show — per record, each field’s old value struck through beside the new one — marked Not saved, and what happens to the live versions. The raw arguments fold under What it will send. The preview is a picture: allowing runs the tool again against the records as they are then, and the receipt is what happened.

Every change leaves a receipt

• Each change is written as a copilot_proposals row before it is applied.
• It goes through the normal write path — it appends a version and can be undone like any edit.
• A failed apply reopens the row with its error; the card says it did not happen. Nothing retries.
• protection_request_review is the one tool that writes directly. It is still prompted and still leaves a row.

The copilot cannot publish or approve

• No publish tool, at any role — even for a user who can publish.
• No approve tool, on any surface.
• No bulk publish, no bulk delete.

The copilot may prepare a publishable draft. A person presses Publish.

Shared workspaces (0.7.0)

Content tools on both surfaces now see published records of shared workspaces, read-only:

• Lists take source: "own" | "shared" | "all"; every item reports source (null = own).
• A single-entry read of a shared record returns source and readOnly: true.
• Every write to one is refused with a message telling the model to link it by id, never copy it.

Details: MCP and tools.

Prompt injection is a real risk, and is not solved

Bounded runs

Every run is bounded by model calls, wall clock and total tokens at once. A run that hits one stops and the chat marks the answer “This answer is incomplete” with the reason. Raise the three together — see the run ceilings.

How much the copilot is used overall is a separate, optional set of limits (since 0.11.0): daily token quotas per person and per workspace, runs per minute and runs at once. A refused run is a 429 before anything starts; a run that spends the last of a quota stops between steps with its partial answer. See usage limits.