Enterprise Server
Workspace pages
The pages every member of the server's project sees. Each shows exactly what that person's own assistant could use: every read runs under their own session.
Overview
Where the console opens: context requests from assistants — served, withheld, or honestly silent — and how ready each repository is, with what stands between a repository and indexed context and a link to fix it. For server admins it opens with Assistant usage: the last seven days' prompts, tokens used, tokens saved and Knwlge calls, each leading to the Prompts dashboard with that figure charted. With session capture off, the figures that depend on it say so instead of showing zero.
Guardrails
One Markdown document: the rules every assistant working through this server must follow — secrets, data, scope of changes, destructive actions, what to report. Everyone reads it here; server admins write it, starting from an example the page can insert. Assistants read it word for word with guardrails.list. Every version is kept and every edit audited, and the document never leaves the server.
Knowledge
What Knwlge knows and serves, in several views:
| Tab | What it holds |
|---|---|
| Repositories | Each readable repository's index state, its units by kind and owner, and the newest units. Text copied from the repository is read-only; what Knwlge generated itself an admin can rewrite, which replaces it in briefs once reviewed. |
| Documents | The team's topic documents, filed in six areas — System map, Entities, API routes, Components, Files, Practices — each opening with its overview, with its full history and who changed what. |
| Memories | Every memory you can read: captured from sessions, written by assistants, imported from pull requests and issues, or uploaded. Its owner or a reviewer edits it — every edit a new version — or archives it. |
| System map | The HTTP routes each repository serves and calls, and the connections matched between them. |
| Entities, API routes, Components, Files, Practices | The knowledge catalog: each entry's location, its description and who wrote it, the facts extracted from the code, related entries, its history, and how often assistants used it. |
| Entity | Summary | Used |
|---|---|---|
| InvoiceLedgerbilling · src/ledger/invoice.ts:14 | Append-only ledger of invoice events; the only writer of billing_events. approved · admin | 48 |
| Invoiceapi · src/models/invoice.ts:3 | An invoice as customers see it; totals are derived, never stored. needs review · assistant | 31 |
| InvoiceLineapi · src/models/invoice-line.ts:7 | One priced line of an invoice. extracted | 12 |
A description starts as the one extracted from the code and improves as admins, assistants and — when a provider key is set — the server's LLM write it. An admin of the team that owns a repository writes, approves, rejects or resets descriptions; a stale marker shows one written before the code changed.
Context
What assistants actually received, card by card, with the cited source behind each one — and what was withheld, and why. It is the page to open when an answer seemed to come from nowhere.
My memory
- Memories: what the server learned from your sessions and your writes. Personal memories take effect without review; edit, revert or archive them here, with each one's timeline and provenance.
- Contributions: what you and your assistants changed in the team's documents, newest first, with a way to revert a change.
- Session capture: the mode your organization set, and your opt-out. Opting out here stops capture of your sessions on every machine (Session capture and learning).
Insights
Daily adoption from the nightly rollup: briefs served and cards accepted, per team, with sparklines and a per-team drill-down. Server admins also see context delivered and tokens saved, estimated at four characters per token — delivered is the text of the cards briefs served; saved is the rest of each card's source file, which the assistant did not have to read. Costs are estimates from a pricing table, never an invoice.