Reading the step trail: files opened, tools used, decisions made

Cowork shows its work: each file it opens, each tool it uses, each decision it makes, with progress indicators as it goes. This is genuinely useful and it is routinely wasted, because most people watch it the first time out of curiosity and never again.

The trail is worth reading properly for one specific reason: it is the only place where a run tells you what it did not do.

What a healthy trail looks like

Spend one deliberate session watching a task you do not care about. You are building a baseline. In a run that is going well you will see:

• The file count matching the folder.
• Tool choices escalating sensibly — a connector where one exists, the browser where it does not, screen interaction only as a last resort.
• Steps that follow from the goal rather than from the previous step.
• Approval prompts arriving where you would expect them.

Once you know that shape, deviations are obvious without close reading.

The four things to look for later

Coverage. Count. A folder of eighteen documents and a trail that opens fourteen is the single most useful signal available, and the finished summary will not mention it.

Escalation. Reaching for screen control on a task that should have been a connector usually means the connector failed. The output is still produced; its provenance is now different and less reliable.

Repetition. The same file opened repeatedly, or the same operation retried, usually means it is stuck and working around something rather than solving it.

Scope creep. Files touched that are not part of the task. Helpfulness is still an unreviewed change.

Steering mid-run

You can redirect a task while it runs, and this is much cheaper than letting it finish and repairing the output. If the trail shows it heading somewhere wrong at step three, say so at step three. Twenty steps of work built on a wrong turn is twenty steps to check.

The corollary: the trail is only useful if you look at it while there is still time to act. A trail read after the fact is forensics.

What goes wrong

Watching it like television. Following along step by step feels like supervision and mostly is not. Read for the four signals above instead.

Only reading the trail when something already looks wrong. By then you have no baseline to compare against, so everything looks slightly suspicious and nothing is conclusive.

Approving prompts reflexively. The prompt is the mechanism; your attention is the control. If you are approving without reading, switch the task to a narrower folder rather than pretending the prompts are protecting you.

Treating the trail as an audit log. It shows what happened in this session. It is not centrally retained, and for local sessions it lives only on that machine.

How to check it worked

After a run, answer one question from the trail alone: how many source files did it actually open? Compare to the folder. If the numbers differ and the output did not say so, you have learned something more important than anything in the output.