OpenClaw BTW Tool Explained

OpenClaw's /btw command is for the small question that would otherwise derail a useful run. The official docs describe it as a quick side question about the current session. It sees the current session as background context, answers separately, and then disappears instead of becoming part of the normal conversation.

30-second answer

Use /btw when you need a temporary answer while the main task should keep its shape. OpenClaw snapshots the current session context, runs a separate tool-less model call, returns a live side result, and does not write the question or answer to session history. /side is an alias. This is not a sub-agent, not a durable session, and not a way to sneak in extra tool work.

What actually happens

When you send a BTW question, OpenClaw treats the current session as background only. If a main run is active, the Gateway snapshots the current message state and includes the in-flight prompt as context. The side call is explicitly told to answer only the side question, not resume the unfinished task, and not emit tool calls or pseudo-tool calls.

That separation matters for operators. A normal assistant answer becomes part of the future transcript and can influence the next turn. A BTW side result uses the separate chat.side_result event instead of the normal chat event, so clients can display it without replaying it as conversation history.

Good use cases

Use BTW for a fast clarification: what changed in this run, what a term means, whether an instruction conflicts with the current plan, or what the agent is likely waiting on. It is especially useful during long coding, research, deploy, or debugging runs where a normal message would either steer the run or enter the queue.

The operator win is context hygiene. You can ask a side question without teaching future sessions that this temporary aside was part of the job. That keeps transcripts cleaner, reduces accidental instruction drift, and makes later trajectory review easier because the main task stays separate from side chatter.

When not to use it

Do not use BTW when you want the agent to change the current task. Use /steer for active-run guidance, queue modes for normal inbound behavior, or a fresh message when you want a durable follow-up. Do not use BTW for tool work either; the docs are clear that it is tool-less and ephemeral.

Operator checklist

Before using BTW, decide whether the answer should matter later. If the answer affects the plan, capture it in a normal message or in a workspace file after the main run finishes. If it is only a momentary clarification, keep it as BTW and let it vanish. That one habit prevents a lot of accidental context pollution.

The OpenClaw Playbook goes deeper on context discipline: when to queue, when to steer, when to spawn, and when to keep side questions ephemeral so your agent stays useful instead of noisy.

Rollout plan

Treat OpenClaw BTW Tool Explained 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 decision owner, source document, acceptance check, upgrade risk, and where future agents should look before changing the behavior. 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.