Async Chat: /background, /queue, and /steer
- Use /background to fire off a long-running task without blocking the current session
- Apply /queue and /steer to manage conversation flow while an agent turn is in progress
- Choose between /background, /goal, and delegate_task for a given async use case
The Blocking Problem
A standard Hermes session is synchronous. You send a message, the agent runs, you wait for it to finish. If the agent is doing something that takes five minutes — indexing a large codebase, running a long test suite, generating a detailed report — your session is occupied for five minutes. You cannot ask the agent something else while it works. You cannot queue the next task while the current one runs.
v0.18 addresses this with three slash commands that break the synchronous model in different ways: /background for fire-and-forget work, /queue for preloading the next turn, and /steer for injecting a note mid-run. Together they give you a much more fluid, responsive conversation experience during long agentic tasks.
/background: A Separate Session, Non-Blocking
The /background <prompt> command runs your prompt in a completely separate Hermes session — a background session that operates independently of the one you are currently in. Your current session stays free. You can continue asking questions, starting new tasks, or just waiting without the interface being locked.
/background analyze all Python files in /src for security issues and write a report to security-report.md
The background session starts immediately, running the full agent loop with tool access, file writes, and all normal capabilities. When it completes, the results appear as a panel in your current session — a summary of what was done and where to find the output. You also have the aliases /bg and /btw for the same command.
Background sessions run with the same model and configuration as the current session. They inherit the working directory and memory context. They do not share the conversation history of the current session — they start fresh, with only the prompt you provided.
/queue: The Next Turn, Ready When You Are
The /queue <prompt> command (alias: /q) pre-loads a prompt into the queue for the next turn without interrupting the current agent response. If the agent is currently generating output, your queued prompt is held and sent automatically as the next turn when the current one completes.
-- Agent is currently running a task... /queue now run the linter on the files you just modified
This is useful for pipelining: you can observe what the agent is doing mid-run and already specify what you want it to do next, without waiting for it to finish and then typing the follow-up. The agent finishes its current turn and immediately picks up the queued prompt.
Multiple prompts can be queued. They execute in order, one per turn, each waiting for the previous turn to complete before starting.
/steer: Inject Mid-Run, After the Next Tool Call
The /steer <note> command injects a note into the current turn — but not immediately. The note is delivered after the next tool call completes, appended to the tool result. The agent processes it as part of that tool's output, without interrupting the current turn or creating a new turn.
-- Agent is running a multi-step task... /steer focus on the authentication-related files only
This is the least disruptive async command. The agent does not stop, does not restart, and does not lose its current thread. It just has an additional piece of context available after the next tool call completes. Use /steer when you want to nudge the agent's direction without derailing what it is currently doing.
Comparing the Three Async Patterns
v0.18 now gives you three distinct approaches to async work, each designed for a different scenario:
Separate session, fully independent. Your current session is free while it runs. Results appear as a panel when done. Best for: long tasks that you can fully specify upfront and do not need to watch closely.
Same session, judge-loop driven. The agent works toward a defined objective over multiple turns, verifying completion. Best for: complex multi-turn work where you want completion guarantees and evidence.
Synchronous delegation to a child agent (covered in Lesson 9). Blocks the parent turn until the child finishes. Best for: structured parallel work where you need the child's output before the parent can continue.
These patterns are composable. A /background session can use /goal internally. A /goal loop can use delegate_task to parallelize its subtasks. Understanding which pattern to reach for first is a skill that develops with practice — but the starting heuristic is simple: if you want to keep chatting, use /background. If you want verified completion, use /goal. If you need the result before continuing, use delegate_task.
Background Sessions and Memory
Background sessions have one important limitation: they cannot write to your memory files while running. Memory writes from a background session are queued and applied after the session completes and the panel is presented in your current session. This prevents race conditions between a running background session and your current session's memory state.
If write_approval is enabled, memory writes from a background session appear in the pending queue alongside skill writes, and require approval before they are committed. This is the correct behavior for background sessions: they produce outputs (files, reports, memory entries) that you review before they take effect.
- /background runs a prompt in a separate Hermes session — your current session stays free, and results appear as a panel when the background session completes; /bg and /btw are aliases.
- /queue pre-loads a prompt for the next turn without interrupting the current agent response — prompts execute in order and can be chained; /q is the alias.
- /steer injects a note that is appended after the next tool call completes — the agent receives it as part of that tool result without interrupting or restarting the current turn.
- The three async patterns serve different purposes: /background for fire-and-forget long tasks, /goal for verified multi-turn completion in the same session, and delegate_task for synchronous parallel work that blocks the parent turn.
- Background session memory writes are queued and applied after the panel is presented — they do not race with your current session's memory state, and write_approval applies to them like any other memory write.