Agents
The agent has one home in the console: the Ask agent panel. It is a control on the console's right edge (⌘I, or the sparkle in the top bar on a phone), on every workspace surface, and it opens beside the page you are reading rather than instead of it — so asking about a service, a run, a secret, or a settings page never costs you the thing you were asking about.
There is no Agents page. The surface that used to carry one has been three things — a chat-first landing, a merged front door with kind tabs, and a set of fleet lists — and is now none of them: a page whose job was to list agents was a second answer to the question the panel already answers. Every /orgs/{slug}/agents link, including every ?kind= tab it ever had, redirects to the Overview with the panel open.
The panel
It carries the conversation and nothing that is not one — no mode switch, no repo chip, no model picker. You say what you want, and the agent delegates through its own governed verbs: it spawns the task session, grounds it on a repository, and says so in the thread.
- History browses everything the workspace has — threads, sessions and routines — with search and filters. This is the thread browser; there is no list page.
- Expanding a thread opens it full-page at
/orgs/{slug}/agents/chat/{chatId}. It is the same durable thread, not a copy: a turn in flight keeps running, because the Durable Object owns it, not the panel. - A session's own page (
/orgs/{slug}/agents/{sessionId}) is a page about a run — reached from the work it is doing, from Activities, or from History. - Workspace memory — what the agent remembers across threads — is linked from History's footer.
On a phone the panel is a bottom sheet; from 1024px it is a side panel; from 1440px the page reflows to make room for it instead of being covered.
Where agents show up elsewhere
Agents are not hidden, they are simply not a destination:
- Initiatives — an initiative's byline names the agents live on its open tasks, and the task carries the assignee. This is where putting an agent on a piece of work belongs.
- Activities — what a run actually did.
- The Overview — the week's conditions, and previews of both planes above.
Kinds
A session's kind is resolved from its profile's agent type: implementer → task agent (works a task on a branch in a sealed sandbox), orchestrator → design agent (turns an epic into a design and proposed contracts, never a branch). Any unrecognized type classifies as a task agent, so no session is ever unclassified.
Two more kinds of agent are not sessions at all: chats (Workspace Agent threads you steer) and routines (standing agents that fire on a trigger — a routine spawns sessions, it never acts inline; two consecutive failures park it until you resume). History renders all four.
The command palette answers the retired names (dispatch, implementers, fleet, chats, routines) as synonyms for Ask agent, so old muscle memory opens the panel rather than landing on nothing.
Attention
An agent blocked on a human is the console's loudest state. The verdict is answerable in place — in the thread, on the session page, or from the needs-you count the Overview's rail row carries — and it resolves only through the credentialed endpoint, never from a rendered card's own state.
Setup
What a session runs as is workspace administration, not a fleet: Settings → Agent profiles holds the identities (agent type, harness, model, owner, autonomy) with their track records, beside Settings → AI providers, which answers what they run on. A workspace always ships a default impl-default profile bound to a platform-minted default-agent API key holding the builder role, so you never have to create one to get started.
Threads are named automatically from the first message; the name resolves live while the first answer is still streaming — no reload.
The console never smuggles hidden instructions into a thread on your behalf — what the agent was told is always what you can read in the transcript.