Watch it think: the answer and the reasoning, live

Someone types "refund order #4821, it arrived broken" into web chat and presses enter. Then one of two things happens. Either a spinner turns for twenty seconds and an answer appears, or lines start arriving straight away:

proposed get_order(4821)
read — ran in 120 ms
proposed create_refund(4821, $64.00)
policy: refund → approval required

Then the reply: the order was delivered on Tuesday, the refund is ready, and it is waiting for someone on the team to approve it.

Both versions take the same time. Only one of them tells you what is going on while you wait.

What actually streams

Two kinds of thing arrive as the run happens. The first is the agent's prose, token by token. The second is a step: what the agent is doing, which tool, and how long it took. A step event lands immediately before every tool call, so the longest silence you can sit through is bounded by that one tool's timeout rather than by the length of the whole run.

The steps are not a narration the model writes about itself. They are what the platform recorded: what the model proposed, what the checks decided and what actually ran. A model can describe its intentions however it likes. The step list says what happened.

Why every turn streams

The obvious rule is to stream the first turn of a reply. With tools involved, that gets it backwards. The first turn is usually nothing but tool calls with no prose at all, and the answer the person is waiting for is produced on the *last* turn. An earlier version of the chat followed the obvious rule, and the effect was that a tool-using agent streamed nothing whatsoever.

So every turn streams. If the model says "let me check the order first" on the way, you see that too, and it is cleared when the next turn starts so it does not stay glued to the front of the real answer.

When the run finishes, the server sends the final reply, and that version wins. Streamed text covers only the turns that streamed, so the browser replaces what it assembled with what the server says. What you read at the end is the answer that was stored.

The pause is part of the picture

In the refund above, the interesting line is the fourth one. The read ran. The refund did not, because policy requires a person to approve it. Seeing that live matters more than it sounds: before the reply has even arrived, you know nothing has been refunded yet, and why.

The approval itself works the same way it does everywhere else. It covers that call, with those arguments, once. One approval. One call. Exact arguments. explains why.

The same steps, kept

Every step you watched is also written to the execution trace as it happens. A run that crashes halfway still shows how far it got. Refused calls are kept alongside the ones that ran, because the difference between what was proposed and what was allowed is usually the thing you were trying to find out.

That is also where to look for runs that came in from Slack, WhatsApp or Telegram. Those channels receive the finished reply rather than a live feed, but the trace behind each one is the same.

A few practical notes. The stream uses server-sent events: one direction, short-lived, and finished when the agent stops talking. The chat still works as an ordinary form post with JavaScript switched off. And the stream releases your session before it starts, so the rest of the app stays usable while a long run is talking.

An agent you cannot watch is one you have to take on trust. Every step on screen as it happens gives you something better: the answer, and the record of how it got there.