How to steer mid-task and read the progress stream

Cowork is not fire-and-forget. You can intervene at any point in the execution stream — and knowing when to do that, and when not to, is one of the skills that separates people who get consistently good output from people who accumulate frustrating sessions.

When to steer

Four situations call for mid-task intervention:

Cowork misunderstood the scope. You asked it to summarise the docs in raw/ and it's reading from archive/ instead. The plan stage should catch this — but if you approved quickly and notice it mid-execution, type the correction immediately.

It's going in a direction that won't work. You're watching the reasoning stream and can see that the approach it's taking will produce the wrong output format, or will miss the key data you actually care about. Don't wait for it to finish. Step in.

It picked the wrong output structure. You wanted one consolidated report and it's generating a separate file per document. Correct it before it generates twenty files you'll have to consolidate yourself.

It's working in the wrong folder. Probably the most consequential one to catch early. If you see it writing to work/ when you wanted out/, stop it before the outputs pile up in the wrong place.

To steer: type your correction in the active session. Cowork reads your message, adjusts course, and continues. You don't need to restart the session or lose what it's already done.

When not to steer

Timing matters. Don't interrupt mid-sentence of an execution step. If Cowork is in the middle of writing a file — you can see the file operation in the stream — let it complete that step before intervening. Steering while an operation is partially complete creates inconsistency: the file might be half-written, the state might be unclear.

The better discipline: watch the progress stream, identify the moment a step completes, then type your correction at the step boundary. Cowork will pick it up cleanly at the next decision point.

Also: don't steer just because you're impatient. If the plan was right and the execution looks on track, let it run. Every interruption costs a context step.

The /clear discipline

When a task is done — outputs are in out/, you've reviewed them, you're satisfied — the right move is to type /clear before starting something new.

Here's why this matters: every message, every tool call, every reasoning trace, and every file read accumulates in the session context. A session at 90% context usage produces noticeably worse output than a fresh one. The context window is finite, and bloated context is one of the most common and least obvious reasons for degraded output quality.

The pattern to build:

1. Finish task
2. Review output in out/
3. Type /clear
4. Start next task in a clean context

This is especially important if you're running Cowork for sustained work across multiple tasks in a day. The /clear habit is cheap insurance against the slow drift in output quality that happens when you keep piling tasks into the same session.

Sub-agents and parallel workstreams

When your task contains independent subtasks — fifty PDFs that all need the same operation, ten competitor websites to scrape, a report with four independent sections — Cowork spawns parallel sub-agents automatically. You'll see multiple workstreams reporting progress simultaneously in the UI.

You don't need to ask for this. Claude decides when parallelisation is useful. But you can nudge it if you're working with obviously independent inputs:

"These 20 files are independent of each other. Process them in parallel and aggregate the results."

When sub-agents are running, your steering role shifts. You're watching the overall progress rather than a single thread. If one sub-agent goes off track, your correction applies to that workstream without stopping the others.