Watching a run

The timeline on the run screen is live. Rows appear while the run produces them: the model thinking, a tool starting and then folding into its completed line with a real duration, a step going green or red, a gate coming up for your decision.

There is no separate live view and archive view. The thing you watch is the record, and the record is what you re-read next month.

A reload loses nothing

The run screen streams from the durable log with a cursor. Reload the page, close the laptop, open a second tab: you get exactly the same run, and the stream picks up from where the log is rather than from where your connection was. If the stream cannot hold, the page falls back to polling the same rows and returns to streaming when it can. Nothing is buffered only in your browser, so nothing is lost by leaving.

When the run settles, the stream ends. The page stops asking, and the terminal status is the last word.

The lists say what is happening right now

You do not have to open a run to see it is moving. A workflow row and a run row both carry a green pulse while their run is live, and the pulse names the tool the run is inside at that moment. When the model is thinking rather than calling anything, it says working….

The Runs screen has a Waiting on you filter, which is the fastest way to find runs that are paused on a decision rather than paused on nothing.

Watching the browser

While an agentic run drives a browser, the run screen embeds a Live browser card and you can watch the session in the page. It is read-only while the agent is driving, which is what the watching chip means.

When the run pauses for your approval, that same view becomes interactive and the chip changes to take over. A paused run is not driving anything, so you can step in yourself: finish a login, get past a screen the agent could not, then approve and let it continue.

What is lined up, not just what ran

Pick a workflow on the Runs screen and switch to Queued and you see the backlog rather than the history: work that is enqueued and waiting, work parked because a spend limit was reached (with the date it resumes), and triggers that failed before any run existed.

That last one matters. A trigger that dies at the door never creates a run, so it would have no page to appear on. It appears here instead, in red, with the reason it failed.

A run that goes silent is failed out loud

Liveness is measured by what a run produces, never by a worker claiming to still be there. A run that stops producing anything at all for long enough is failed deliberately, and the run screen says so: The run went silent and was marked failed.

That is a conservative default and it is on purpose. A run that hangs forever is worse than a run that fails visibly, because only one of the two brings you back to look at it. For a codified workflow, going silent enters the same failure review as any other failure, so the workflow's health reflects it.

The status is the truth

A stopped or finished run can still gain a line or two of activity from the worker on its way out. The run's status wins on screen: once a run is settled, the screen shows it settled, whatever else arrives afterwards.