How to Use OpenClaw Steer

OpenClaw steering is for the moment when the agent is already working and you need to adjust the run without starting over. The docs define /steer as guidance to an already-active run, delivered at the next supported runtime boundary.

30-second answer

Use /steer or /tell when a run is active and the new instruction should shape that same run. It does not start a new run when the session is idle, and it does not change the saved queue mode. If you need to guide a child worker, use /subagents steer. If you need to change default behavior for future inbound messages, use queue settings instead.

Basic examples

/steer prefer the smaller patch and keep the tests focused
/tell summarize before making the next tool call

Those commands are intentionally short. The point is not to re-spec the whole task; it is to nudge the active run before it makes the next important choice. Steering works best when the message is concrete: choose the smaller patch, avoid browser automation, stop before deployment, or focus on one file.

Steer versus queue

The docs draw a clean boundary. /queue steer changes how normal inbound messages behave when they arrive while a run is active. /steer <message> is a one-off explicit command that tries to inject that message into the active run regardless of the stored queue mode.

That distinction matters in busy channels. If your default queue mode is collect or follow-up, a normal message might wait. A steering command is a deliberate intervention. If the session is idle, the command should warn instead of creating surprise work.

Sub-agents and ACP sessions

Top-level /steer does not select a sub-agent by id or list index. For child runs, the docs show /subagents steer 2 focus only on the API surface. ACP harness sessions use their own command path with /acp steer. Keep the target explicit so the wrong worker does not receive the instruction.

Operational uses

Steer is valuable during deploys, refactors, data audits, and long research. If the agent is about to choose between a broad rewrite and a narrow fix, steering can save the run. If a sensitive action appears, steer it to stop before the external side effect. If the agent is over-explaining, steer it to summarize before the next tool call.

Failure modes

Steering is not magic. The active runtime sees the guidance at supported boundaries, so it may not interrupt an already-running command. It also cannot repair a vague original task by itself. If the job is wrong, stop or let it finish safely, then start a clearer turn.

The OpenClaw Playbook treats steering as an operator control, not a chat trick. Use it sparingly, use it precisely, and reserve normal messages for durable instructions that should remain in the transcript.

Rollout plan

Treat How to Use OpenClaw Steer as a workflow you roll out in stages, not a switch you flip once. Start with the smallest harmless proof: a status check, dry run, local-only call, private session, or read-only inspection. Confirm the documented behavior matches your installed OpenClaw version, then write the exact commands and expected output into the workspace so the next agent does not rely on memory or vibes.

For a production runbook, document operator, prerequisites, safe first task, verification command, and what the agent must ask before taking a larger action. Also write down what the agent may do alone, what requires approval, and what must stop immediately. That boundary is the difference between useful autonomy and a workflow that surprises the operator at the worst possible time.

Keep one rollback note beside the guide. It can be as simple as the command to disable a plugin, the channel to pause, the config key to revert, or the owner who must approve the next run. Include the proof that tells you rollback worked, and keep it visible near the production checklist for future maintainers. Agents are most useful when recovery is obvious.

After the first live run, review the transcript or logs while the details are fresh. Look for missing prerequisites, stale assumptions, broad prompts, confusing errors, and any external side effect that should have been gated. Tighten the guide, then repeat with one wider scope. The OpenClaw Playbook is built around this operating rhythm: cautious first proof, written runbook, verified automation, then gradual autonomy once the evidence is boring.