Harness Engineering · ~7 min
A live run drifts toward the wrong file. You don't have to let it finish or throw it away — you can redirect it mid-flight and keep every bit of context it has already built.
A steering message is a mid-run message that interrupts tool execution and redirects behavior without discarding accumulated context. A follow-up is a correction queued during execution and delivered after the current step. Both preserve context; restarting throws it away.
When a run is live, you have four options — and reading the tool-call stream is what tells you which.
| Move | Use when |
|---|---|
| Steer | The direction is clearly wrong but recoverable — wrong file, wrong approach, misread scope |
| Follow up | The current step is fine; you want to adjust the next one ("also update the tests") |
| Restart | It's too far down the wrong path — a fresh context with a better prompt is cheaper |
| Let it finish | The approach is acceptable, even if not ideal |
Steer as early as possible — ideally right after the first tool call that signals a problem. Indicators: reading files unrelated to the task, creating new abstractions where existing ones should be reused, or repeating the same search with minor variations (stuck).
That's the whole case for steering: it's the cheapest way to fix a recoverable wrong turn, because the expensive part — the context the agent built — is exactly what it keeps.
Steering only works if your message actually interrupts. In Claude Code, typed messages queue until
the next turn boundary — pressing Enter alone does not stop the current step. To interrupt immediately, press
Ctrl+C first, then send. Sending a follow-up when you meant to interrupt lets the wrong step keep
consuming context, and the correction arrives too late to be cost-effective. The anti-patterns rhyme: waiting
too long (context burned on useless work you still have to undo), and over-steering
(interrupting every few steps usually means the initial prompt was underspecified — restart with a clearer one).
Irreversible side effects already executed: a steer redirects future steps but cannot undo a sent request or a pushed commit — which is exactly why Lesson 14's rollback-first design has to come first. Heavily cached sub-agent setups: a steer to the orchestrator doesn't reach already-dispatched workers; only the next dispatch gets the correction. Contaminated context: if earlier tool calls filled the window with verbose errors or irrelevant files, preserving that context hurts more than it helps — restart with a cleaner prompt. Steering is the right tool for a recoverable wrong turn, not for a run that's already poisoned.
Ctrl+C first; a typed message alone only queues.Retrieval practice — recall, don't peek
Question 1A steering message differs from a restart in that it…
Question 2You should steer when the agent's direction is…
Question 3In Claude Code, a typed message during a step by default…
Question 4Steering every few steps usually signals that…
Question 5 · spaced recall from Lesson 14Rollback-first design tells you to choose…