An agent inside the permission model,not beside it
The assistant is not a wrapper that reads your screen. It calls the same REST API you do, as the principal you are, in the organization you are in — so there is no second permission model to keep in step with the first, and nothing it can reach that you could not.
Four properties, each a design decision rather than a setting
Every write is approved
approve / reject cardRead tools run freely; the tools that create, update, delete or relate anything stop and render an approve/reject card in the conversation. You see the exact call and its arguments before it happens. An agent that writes first and reports afterwards is one you have to supervise; one that asks is one you can direct.
Its reach is a role, not a prompt
viewer sees the read-only setTools are gated server-side by the caller's role. A viewer's assistant is not told to behave; it is handed a smaller catalogue. There is no instruction to jailbreak, because the write tools were never in the conversation to begin with.
It answers with the platform's own components
agent-rendered cardsWhen the assistant reports on system health, a vision run or a set of entities, it renders the same React component the rest of the app uses for that data. You are looking at the platform's view of the record, not at the model's paraphrase of it.
It can ask, and secrets stay server-side
ask_userThe agent can pause mid-task for free text, a choice, or a password. A sensitive answer is stashed server-side and reaches the model only as a reference — so a credential can be used by a tool without ever entering the transcript.
46 MCP tools, over the same handlers as the REST API
Agents outside the app — a coding assistant, a scheduled analyst, your own tooling — reach the platform through a Model Context Protocol server. It is not a parallel surface: the dispatch threads the API key's principal into the same handlers the HTTP routes call, so an MCP client is scoped exactly as its token is and audited exactly as a person is.
- Per-token scopes — read, write, admin, ai — bounded by the owner's own role
- Only the SHA-256 hash of a token is stored, so the token table is not a list of live credentials
- Revoking one token leaves every other agent's access untouched
- Entity tools are organization-scoped, enforcing the same rules the REST routes do
What the in-app assistant can actually do
Tools are registered, typed and role-gated. This is the whole surface, grouped the way the registry groups it.
- Read
- Platform overview, entity types, entities, relations, search and documents. Always available, to every role.
- Write
- Create, update and delete entities, add relations, create documents. Every call gated behind an approve/reject card.
- Interactive
- Ask the user for free text, a password, or a single or multiple choice — mid-task, without losing the thread.
- Browser
- A per-user headless Chromium: navigate, click, type, screenshot, extract text. Screenshots stream into the chat.
- Vision
- Object detection over a photo, a video or a live stream. A one-photo question blocks briefly so it is answered inline rather than queued.
- UI
- Typed React components rendered straight into the conversation — the app's own cards, not a re-implementation of them.
The assistant can propose an ontology; only a person adopts one
Pointed at what has been ingested, the agent will infer entity types, their fields and the relations between them, and write the result as a proposal record. The proposal is reviewed and accepted or rejected in the UI. Nothing about your data model changes on a model's own authority — which matters more here than in most places, because the ontology is what every list view, search facet and agent tool is generated from.
- A proposal is a record with a status, not an applied migration
- Accepting one creates the types through the same API a person would use
- Per-organization overlays mean one tenant's accepted proposal is not every tenant's schema
No transcript, on purpose
A screenshot of the assistant answering a question is a screenshot of whichever model the development stack happened to be pointed at that afternoon. The properties above are the product; the reply is not. What the assistant does with your data is worth showing live, against your data, which is what a demo is for.
Provider configuration is admin-only and persisted in the platform, so the model behind the assistant is an operator's choice rather than ours. The tool catalogue, the role gating and the approval flow are the same whichever one you point it at.
Ask it something we did not prepare for
The most useful demo is the one where you ask the assistant a question about your own data and watch which tools it reaches for. Bring one.