Tour the Console
The Console is the web front door to your workspace. It drives the same runtime path as the CLI and the Platform API, so anything you do there is inspectable from the others. This tour walks the navigation rail from top to bottom.
Overview
Section titled “Overview”The landing screen for the selected workspace: agent activity, what needs attention, the fleet of enabled agents, connected systems, and the enforcement posture, including counts of actions denied by policy and egress refused. Use it to see at a glance whether anything is waiting or failing.
Sessions
Section titled “Sessions”A session is a conversation with one enabled agent version. The screen shows the session rail on the left, the run timeline in the middle, and a composer to start the next run. When a run pauses for a person, the approval or question renders inline as a card; answering it resumes the same run.
Each session also exposes its evidence, its delegations (work handed to other agents), and its token usage. Forking a session starts a new lineage from a point in the timeline.
Agents
Section titled “Agents”Every agent enabled for the tenant, with its versions, the manifest each version was registered with, and per-tenant enablement. This is where you confirm which version serves this tenant and read the contract it carries: models, egress, policy ceiling, connectors, and trace capture.
Connectors
Section titled “Connectors”Configure service connections and connect your own account where required. In Agent → Integrations, select a version, choose a compatible connection, and Allow access as an administrator. Personal integrations also need each user’s own account. Setup preserves a blocked request; Continue starts it only when ready. See MCP connectors.
Policies
Section titled “Policies”What agents on this tenant may do, and what happened when they tried otherwise. Rules is the live policy as a list of sentences (who it applies to, what it watches, what a match refuses) with what each did in the last seven days. A rule opens on its own screen with a form and the same rule as code side by side, and “what it would do” replayed over last week beside it. Edits are kept as you type into one pending change; Review and publish shows the diff and the impact, and publishes everything together as the next version. Versions rolls back or restores. The Observing / Enforcing switch at the top carries the week’s number. Activity is the feed of decisions in plain words, each naming the rule, with “Why?” and “Make a rule”. See Write tenant policy.
Control
Section titled “Control”Operational controls for what is running: enablement per agent, session lifecycle (stop, resume), and the list of live sessions. Use it when you need to stop serving a version or release a runtime without touching the CLI.
Assurance
Section titled “Assurance”The sealed ledger, the policy decisions, the controls an auditor tests, the chain’s integrity, and the execution traces. The ledger is filterable by period, agent, decision, and plane. An auditor package can be exported from the Integrity tab. See Audit and evidence for what each record proves.
Supervision
Section titled “Supervision”Supervision is where people step into agent work. Its Inbox lists agent asks waiting for a person: every open permission request and question across the sessions in the selected tenant, longest-waiting first, answerable in place. “Mine” shows the sessions you started; “All in tenant” shows everyone’s. Any member of the tenant may answer; the first answer wins. Answering here is the same as answering in the session, and opening the inbox never wakes a parked session.
Work is the queue of work the platform could not settle on its own, longest-waiting first, with any settlement question a human still owes at the top.
Evaluations
Section titled “Evaluations”Where a tenant with evaluation enabled sees evaluation runs, their assessments, cost and latency, and the annotated trace each verdict was made about. See Evaluate a version.
Settings
Section titled “Settings”Your organization: members and roles, invitations, tenant grants, ownership, and the workspaces you can select. See Organization members and access.
Console, CLI, or API?
Section titled “Console, CLI, or API?”| You want to | Use |
|---|---|
| Try an agent, answer approvals, read a run’s evidence | Console |
| Author, deploy, roll out, script an operation | tanomis |
| Call an agent from your product | Platform API |
All three share one control plane, so a session started from the API appears in the Console and a rollout from the CLI is visible under Agents.
Where to go next
Section titled “Where to go next”- Quickstart: deploy and run your first agent.
- Answer approvals in the Console
- Read the audit trail