Control a Busy Hermes Agent with Queue, Steer, and Interrupt

A follow-up message sent while Hermes is working can stop the current run, wait for the next turn, or guide the work already in progress. The right choice depends on whether the new information invalidates the task, merely belongs afterward, or should influence the next decision without discarding completed work.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/

Understand the three modes

Interrupt is the default. It stops the active run and combines the new message into the next prompt. Use it for a wrong target, unsafe action, changed requirement, or any correction that makes continued execution wasteful.

Queue lets the current run finish, then starts a new turn with the waiting message. It is the safest default for “when you are done, also…” requests and independent follow-up work.

Steer injects the message after the next tool call without creating a separate turn. Use it when the current goal remains valid but the agent should adjust its route, emphasis, or acceptance criteria. If a run has not started, steer falls back to queue behavior.

Configuration checklist

• Decide whether the channel is primarily conversational, operational, or approval-driven.
• Set gateway.busy_input_mode to interrupt, queue, or steer.
• Keep busy acknowledgments enabled during rollout so users can see what happened.
• Disable only the acknowledgment with display.busy_ack_enabled: false if it becomes noisy.
• Teach operators that /stop cancels without adding a follow-up prompt.
• Test rapid consecutive messages on the actual platform.
• Document which mode is expected in shared rooms.

Practical decision rule

Use interrupt when continuing is wrong, queue when the message is a separate next task, and steer when the destination is unchanged but the route needs adjustment. Avoid using steer for a hard safety stop: the active tool call completes before the steering message arrives.

Common pitfalls

• Assuming every follow-up immediately reaches the model.
• Using queue for a correction that makes the current action unsafe.
• Using interrupt for harmless additions and repeatedly throwing away progress.
• Treating the acknowledgment emoji as proof the requested work succeeded.
• Forgetting that busy state and session context may be isolated per user in group channels.

Verification steps

1. Start a harmless multi-step task in a test channel.
2. Send one follow-up in each mode and record the observed order.
3. Confirm interrupt stops the run, queue starts a later turn, and steer changes the active run after a tool boundary.
4. Send /stop and verify no follow-up task is created.
5. Restart the gateway if configuration was changed and repeat the test.
6. Keep the mode only after its behavior matches the channel’s operating expectations.