Every screen in the console¶
One page, every module, described. Screenshots follow the theme you are reading the site in - switch it with the toggle in the header and every image on this page switches with it.
Captured 2026-09-01 from a running deployment: 35 screens, 27 of them in both
themes under docs/assets/screens/, named identically in light/ and dark/.
The eight Builder screens are dark only, and say so where they appear.
The chat, in twenty seconds¶
A CSV dropped into the conversation, one sentence of instruction, and the agent writes Python, runs it in a sandbox, and answers with charts it drew from the data. Nothing here was configured for this file in particular.
Where you land¶
Dashboard¶
Arrangeable widgets, the whole deployment first and then this organization. Runs, spend, service health and answer quality; each card is gated on the permission its own data needs, so a card whose primary read you cannot make is a card you are not offered.
Chat, mid-run¶
The agent thinking, then the shell commands it actually ran in the sandbox, each one expandable. Transparency is the product here: what a tool did is on screen, not in a log somebody else can read.
Building an agent¶
Agents¶
The catalog. Every agent carries the version that is live, who may reach it, and whether a draft is waiting. An agent is configuration, not code - which is why this list is editable by whoever knows the answer.
Agent templates¶
Templates by industry, over the catalog. Installing one creates a draft you finish and publish; nothing runs until you do.
Skills¶
Know-how written once and shared by every agent bound to it - how refunds are handled, what the house style is. Edit it here and each agent bound to it is current on its next run.
Skill gallery¶
Skills by industry. Installing copies one into your organization, where you can edit it - a copy, so upstream cannot change what your agents say.
One skill¶
Open for editing, with its category. The name the model refers to is fixed at creation and cannot change; everything else here can.
Context¶
Standing context every agent can draw on - a glossary, a policy, a brand voice. Injected into the prompt or read on demand, and current the moment you edit it.
Inside one agent¶
The Builder, tab by tab. These eight are dark only - the light half has not been captured, so unlike every other screen on this page they do not follow your palette.
Build¶
Instructions, model and endpoint. The behaviour lives here rather than in code, in Markdown the model reads for structure - and the header carries published beside Draft differs from v40, which is the whole point: editing does not ship.
Toolbox¶
Every capability as a switch - knowledge search, a browser, Python in a sandbox, charts, delegation - and the per-tool approval gate beside each. Configuration reaches only what code registered.
MCP servers¶
Which connections this agent may reach, and which of their tools. The organization's list still bounds it; an agent can narrow inside that and cannot reach past it.
Limits¶
One monthly cap and a step ceiling. The cap is checked before each model request, and the step limit catches the other runaway - a tool loop that is cheap per call and never finishes.
Availability¶
Where this agent answers: the dashboard and the API always, plus any chat bot bound here. An agent is mentionable by @handle only on the bots it is bound to.
Routines, on the agent¶
What it does with nobody typing, on this same tab - a schedule that can be paused, or an event trigger.
History¶
Every version this agent has had. The one that was live in March is still readable, which is what makes a rollback a choice rather than an archaeology project.
Visual map¶
The same agent as a graph: what reaches it, and what it reaches for. A dashed box is something nothing is attached to - a budget with no ceiling of its own reads as a gap rather than as a default.
Knowledge¶
Knowledge bases¶
Collections. Group related documents into one, then choose in chat which collections an agent may search.
A collection¶
Its documents, their chunk counts, and anything that failed to ingest with the reason. Chunk boundaries are what a search matches against, so a document re-uploaded after a settings change is re-chunked.
Parsing, per upload¶
The choice nobody else exposes: PyMuPDF, LiteParse or LlamaParse, the chunking strategy, chunk size and overlap, OCR and its language. Set on the collection and overridable on the next file you add - because a scanned rate card and a Markdown runbook do not want the same parser, and the wrong one is the difference between an answer and a refusal.
What happened, and what is waiting¶
Runs¶
Every run this organization made, with its status, surface, model, person and cost. A run is the process: it starts, it can be stopped, and it leaves a record.
One run, opened¶
Tokens in and out, cost to four decimal places, how long it took, and the timeline of every turn and tool call. The chat it happened in is one click away.
Approvals¶
Everything waiting on a person, with what the agent intends to do. An approval is decided exactly once - a second decision on a settled one is refused, which is the detail that makes the gate worth having.
Spend¶
What was actually spent, by period. A budget is checked before the model request rather than tallied afterwards, so a run that breaches one stops mid-answer and still records its cost.
Routines¶
What agents do with nobody typing - on a schedule, or when an event arrives. Those runs are budgeted, approved and audited like any other.
A new event trigger¶
Naming the event that starts a run, over the routines list.
The organization¶
Organizations¶
Switch between them, manage members, and create new ones. Authority inside an organization is a membership row plus the permission catalog - there is no role column on a user.
Vault¶
Every key this organization has stored, sealed per tenant. Replaceable, never readable again; and rotating one is invisible to a published agent, which references the secret rather than its value.
MCP servers¶
Connect any MCP server by URL and its tools become switches in the Builder. Connect it for the organization and every agent may use it; connect it for yourself and it stays in your own chat.
Channels¶
The chat platforms this organization answers on - Slack, Telegram, Mattermost. A bot serves every agent bound to it, and the binding is made on that agent's Availability tab.
Sandboxes¶
Where this organization's agents run shell commands and keep files. An agent names a connection by id, so moving to another host is one edit here rather than a republish of every agent.
Workspaces¶
The files agents are keeping for you. A workspace is scratch space - it is deleted with the conversation it belongs to, and is not a place to store anything durable.
Deployment administration¶
Users¶
Everybody who can sign in to this deployment, and the app-admin flag that is separate from any organization role.
All organizations¶
Every tenant on this deployment, with its owner, members and agents.
System¶
Database, Redis, the vector store and model access - the same checks agenticos cmd doctor runs, on a page.
Deployment¶
This deployment's own identity and policy: sign-up, invitations, notices, and what a first-time visitor meets.
What is not here yet¶
- The light half of the Builder - the eight shots above exist in dark only.
- Sign-in and onboarding, which is what a first-time visitor actually meets.
Recap¶
- 27 modules have both themes in
docs/assets/screens/, under the same name; the eight Builder screens are dark only. - On this site an image is written twice, with
#only-lightand#only-dark; Material shows the one matching the reader's palette. - In the README the same pair goes in a
<picture>withmedia="(prefers-color-scheme: dark)", which is how GitHub does it. - Parsing is the setting worth knowing about before you upload anything: the parser and the chunk size decide whether a table can be answered at all.