Sessions
One live list of every piece of agent activity. Flow runs, background tasks, and chats, in one place you can monitor and resume.
A session is any piece of agent activity that is happening or has happened: a Flow run, a background task, or a chat. Sessions is the single list that brings all three together, so you have one place to see what is running, what finished, and what is waiting on you, and to jump back into any of it.
Sessions is a lens, not a separate kind of work. A flow run is still a flow run and a chat is still a chat. Sessions normalizes them into a common shape so they can sit in one list, sort together, and be resumed from one place.
The three kinds
Every session is one of three types, and each opens its own detail view when you click it.
| Kind | What it is | Where it opens |
|---|---|---|
| Flow run | A run of a Flow: its steps, checkpoints, transcript, and artifacts. Run a Flow covers the timeline in depth. | The run timeline. |
| Background task | Longer-running work that proceeds without you watching, including a chat or flow you sent to the background. Background tasks covers the states, review, and fan-out. | The task detail. |
| Chat | A conversation with an agent, whether a read-only Ask inquiry or a working Chat. | The chat transcript. |
What a session shows
Each row in the list carries the same set of signals, derived from whatever the session actually is.
- Status, color-coded so you can scan a long list. Work in progress reads as active, finished work as success, a failure or rejection as a problem, and anything paused, blocked, or waiting as needing attention.
- Progress, where it makes sense. A flow shows how far along its steps it is ("Step 2 of 5"), a task shows its effort ("12 turns"), and a chat shows its length ("8 messages").
- Owner and timing, so you can tell whose session it is and when it last moved.
- A clear error when something went wrong, surfaced on the row rather than hidden in a detail view.
Active first
The list puts what is happening now at the top. A session counts as active when it is genuinely live:
- a flow run that is running, paused at a checkpoint, or pending;
- a background task that is running, queued, provisioning, or waiting; or
- a chat whose last message landed in the past half hour and that has not been ended.
Everything else falls below, ordered by how recently it changed. The effect is that the work that needs you, or that you are most likely to return to, is always in view first.
The Command Center
Sessions also lives as a panel you can open from anywhere in the app, the Command Center. It is the live hub for in-flight work: it splits your active chats, Flow runs, and background tasks into Active Now (the work currently in motion) and Recent (the work that finished or went quiet in the last twenty-four hours), updates in real time as steps complete and statuses change, and lets you resume any of them without leaving the page you are on.
This is where backgrounded work lands. When you send a run to the background, it keeps going as a task you can follow here, and when it pauses at a checkpoint for your approval it shows up ready for you to act on.
Finding a session
The full Sessions list is tenant-wide and built for finding things, not just watching them. You can narrow it by owner, by kind (flows or chats), and by the initiative or plan a session is tied to, and it is ordered with the most recently active work first. The Sessions page guide walks through using it: the tabs, the owner facet, reading a row, and clicking through.
Sessions does not replace the work
Because Sessions is a view, the things it lists keep their own homes and their own lifecycles. A flow run is still managed as a Flow, a chat still lives in your conversations, and a background task still runs on its own. Ending a chat removes it from the active set without touching the flow runs or tasks beside it. Sessions simply gives you one honest, real-time answer to the question "what is my agent doing right now, and where do I pick it back up?"
Sessions and the audit trail
A session is also the second half of the audit trail. Where the audit log records what changed on a record, the session is the full transcript of how it changed: every message, every tool call, every file edit with the before-and-after, plus the metadata of where the work ran (sandbox, profile, runtime, repo, branch, and whether it was opened in the web app, attached from the VS Code panel, or scheduled as a Flow step). A credential-redaction pass runs over the transcript before it is persisted, so a token that flashed through the work for a moment is recorded by its name rather than its value. The audit log gives you the headline; Sessions gives you the receipts.