Sessions

Agent work piles up fast. A Flow your teammate kicked off this morning, the chat you had on a bug yesterday, the verification run from last week you now need to cite in a review. Sessions is the page you go to when the work you want is not the one in front of you: the searchable, filterable index of agent activity across the whole workspace, with the status, the owner, the timing, and the cost of each one on a single row, and a click-through to the run timeline or the transcript.

Sessions is the operational companion to the Sessions concept, which explains what a session is and why Flow runs, chats, and background tasks all normalize into one shape. This page is about using the Sessions page itself: finding work, narrowing it down, reading a row, and opening what you find.

Where Sessions lives

Sessions is in the Planning area navigation, and it opens at its own full-page route. The page is a single list: a tab bar and a filter control at the top, then a scrolling column of session rows that loads more as you reach the bottom. There is no setup and nothing to configure; the list is populated the moment any agent work runs in your workspace.

The list brings your Flow runs and your chats (both working chats and Ask inquiries) into one place. Background tasks have their own live home in the Background tasks panel and the Command Center, where the work-in-progress controls live; this page is the cross-workspace index of runs and conversations.

Reading a row

Every row says what the work is, who ran it, where it stands, and what it cost, without opening it.

The status colors

The status pill uses one consistent color language across every kind of work, so you can scan a long list and know what needs attention without reading a word.

• Green is live: running or provisioning.
• Grey is settled: completed, merged, reviewed, ended, skipped, or cancelled.
• Red needs a look: failed, rejected, or discarded.
• Yellow is waiting on something: paused, blocked, or interrupted.
• Marigold is lining up: pending or queued.

A live Flow run or a streaming chat shows a spinner in place of the pill, so the things actually moving right now are obvious in a glance down the column.

Ordered by most recent activity

The list is ordered by most-recently-active, so the work that just moved is at the top and older work falls below as you scroll. A running Flow or a chat mid-turn, the things that update second by second, naturally surface to the top because they are the most recently touched. The Sessions concept page defines exactly what counts as active for each kind of work.

Finding the one you want

Two controls narrow a long index down to the work you are after.

The tabs

The tab bar across the top filters by kind: All, Flows, or Chats. It is the fast cut between "show me every Flow run" and "show me every conversation" without opening the filter panel.

Filter by who ran it

The Filter control opens an owner facet listing everyone in your workspace, so you can narrow the index to one person's work, or a few people's. The facet lists every member, not only the people with work on screen right now, so you can filter to a teammate who has not run anything today and watch their next run land.

When you open Sessions from inside an initiative or a plan (the Sessions tab on that record's detail page), the list is already scoped to that record's work, and the owner facet narrows within it. That scope holds even if you edit the address bar, so an entity's Sessions tab always shows that entity's work.

Finding a run someone else made

Marcus, a VP of product, needs the verification Flow run Priya's team did against the Insights project last sprint to cite in a review. He opens Sessions and clicks the Flows tab, which drops every chat out of the list. He opens Filter and checks Priya and her two engineers in the owner facet. The list narrows to their Flow runs, most recent first. He scrolls back to last sprint, finds the run titled for the CSV format verification, reads the grey Completed pill and the cost on the row, and clicks through to the run timeline to read the transcript he came for. Two filters and a scroll, no asking around, no pinging Priya to dig up a link.

Acting on a row, and opening one

Some actions are right on the row, so you can act without opening anything. An active Flow run carries a Cancel control; a chat carries an End control to close a conversation you are done with. The work you most often want from a long list, stopping a runaway run or closing a finished chat, is one click from the index.

To go deeper, click the row and it opens where that kind of work lives:

• A Flow run opens its run timeline: the steps, the transcript, the checkpoints, the artifacts.
• A chat opens its detail view. A summary card up top carries the run at a glance (owner, when it started, duration, message and tool-call counts, the model it ran on, the cost, and links to the initiative, plan, repository, branch, and pull request it touched), and two tabs sit below it: Transcript, the full conversation, and Metadata, the key facts as a table. The header carries Resume in Chat, which reopens the conversation in the chat drawer from where it left off, an Open Disco AI in VS Code action to pick the work up in your editor, and End.
• An Ask inquiry opens that same detail view, marked with an Ask badge so you can tell an inquiry from a working chat. (The pin-and-save controls for Ask live in the Ask area itself.)

The standalone Sessions page navigates to the detail view when you click a row. Resuming a Flow run, a background task, or a backgrounded chat is covered on the page that owns each: Run a Flow and Background tasks. Resume in Chat, Open in VS Code, and End each require the conversation-manage scope and an open conversation, so an ended chat keeps its transcript for reference but does not reopen.

Sessions on a record

The same Sessions list also appears as a tab on an initiative or a plan detail page, pre-scoped to that record's agent work. It is the answer to "what has the agent done on this initiative," right where the initiative lives.

Two things make the embedded tab its own surface. First, the scope is locked to the record: it shows that initiative's runs and chats and only those, and it holds even if you edit the address bar, so the tab cannot be tricked into showing work from elsewhere. Second, clicking a row opens the detail inline on the same page rather than navigating away, so you read a run without losing the record's context. The owner facet still works inside the tab, narrowing within that record's sessions.

What you open Sessions to do

Sessions earns its place because of the questions it answers in one screen. The common ones:

• Unstick a stalled run. Scan the list for a yellow pill, the work that is waiting on something, and you catch a Flow paused at a checkpoint before it stalls a sprint. Open it, approve or reassign, and it moves again.
• Review what the agent spent. Filter to a sprint's owners, read the cost captions down the list, and open the one outlier to see its per-turn breakdown. The whole team's AI spend is one filtered list, not a report someone has to assemble.
• Prepare for a review or an audit. Find a completed verification run, confirm its status, and link its timeline straight into the review you are writing, the way Marcus did above.
• Learn the work by reading it. A new hire scrolls the recent runs and reads two or three transcripts end to end. Watching how the team actually works with the agent is faster than any onboarding doc.

What a session cost

A chat's session view carries the full AI-spend detail for the conversation, for the people who should see it. The header shows the total cost in dollars; a metric grid breaks down turns, events, AI credits, tokens, and tool calls; and a per-turn list shows each turn's model, status, and cost.

What makes the number trustworthy is that each turn is labeled for how its cost was known. A priced turn is one the runtime reported a real charge for. An estimated turn is one the platform priced from its token counts when the runtime did not return a figure. An unpriced turn is one that genuinely carried no charge, and saying so plainly is the difference between a total you can defend in a budget review and one you have to caveat. For a lead managing an AI-spend budget, the row caption is the scan and this detail card is the drill-down, both on the same surface.

The Sessions row carries a compact version of this, a small cost caption in the steps column, so you can read spend down the whole list without opening anything. A caption can read a plain dollar figure, a dollar figure with the AI-credit count beside it, "Unpriced" when every turn was free, or a dollar figure followed by "+ unpriced" when some of the run was. The full breakdown, and whether cost shows at all, is gated by the AI-spend visibility scope and by your workspace having spend tracking switched on, so cost is in front of the people who manage it and out of the way for everyone else.

The whole list stays live

The Sessions page updates itself as work moves. A Flow that starts a step, a chat that takes a turn, a run that reaches a checkpoint or finishes: each lands on the list within a second, and the row's status and timing update in place. You do not refresh the page to see the current state; the page is the current state.

Sessions, the Command Center, and the audit trail

Three surfaces show agent work, and each is the right tool for a different question.

• Sessions answers "find me a specific piece of work across the workspace." It is the full, filterable, scroll-back index.
• The Command Center answers "what am I working on right now." It is the live panel of in-flight and just-finished work, openable from anywhere, where you resume the thing you stepped away from.
• The audit trail answers "who changed what, when." Where Sessions holds the transcript of what an agent did inside a run, the audit log holds the record of the change that run produced.

Together they mean no piece of agent work is ever a black box: you can find it, watch it, read exactly what it did, and trace the change it made back to the moment it happened.

One index the whole team can see

Sessions is workspace-wide by design, and that is a deliberate choice. A per-person view answers "what am I doing." Only a shared index answers "what has the agent been doing for us," and that is the question that matters once a team trusts agents with real work. The same list that lets you find your own run lets a lead see the team's, which is what turns a fleet of individual agent runs into something a team can see, learn from, and govern as one. Agent work is team work, and the record of it is shared by default.

Permissions

Viewing Sessions (the list, the owner facet, and a chat session's cost detail) is governed by the sessions-read scope, which every content-facing role holds, so the whole team can see the workspace's agent activity in one place. Opening a Flow run's detail uses the same Flows read scope that gates Flows everywhere; opening a chat uses the sessions-read scope. Cancelling a Flow run from a row is an elevated control (the cancel-any scope a lead or admin holds), and ending a chat uses the conversation-manage scope. The AI-cost figures carry their own visibility scope, held by the people who manage spend (admins, owners, and billing managers), and they show only where your workspace has spend tracking switched on, so cost is in front of the people accountable for it and out of the way for everyone else.