How to Run Multiple Agents in One Hermes Agent Window: Subagents, /bg, and Live Sessions

On macOS, Linux, and WSL2, the install script clones Hermes to ~/.hermes/hermes-agent, links the hermes command into ~/.local/bin, and keeps your config and data in ~/.hermes. On native Windows, the PowerShell installer puts code and data under %LOCALAPPDATA%\hermes and adds hermes to your user PATH.

Reload your shell profile, or open a new terminal on Windows, so the hermes command is found. Then run hermes doctor. It reports anything missing and tells you how to fix each item.

hermes model walks you through choosing a provider, signing in or pasting a key, and picking a model. Settings go to config.yaml and secrets to .env, both in your Hermes home. hermes setup runs the full wizard instead, if you want to choose tools and skills in the same pass.

Then start a chat and ask for something small that needs a tool, such as describing the files in the current folder. If that works, delegation will work too, because subagents inherit the parent's provider, credentials, and toolsets unless you override them.

For a local model, choose Custom endpoint and point Hermes at your server. With Ollama the base URL is http://localhost:11434/v1 and the context length must be at least 64000. Ollama's default context is smaller than that, so raise num_ctx for the model first and enter the same number in Hermes.

Delegation settings live in the delegation block of config.yaml. The most useful key is delegation.model. The docs make the case well: splitting a problem needs a strong model, but a subtask that arrives with a clear goal and context usually does not, and the children are where the tokens go. Keep the model you chat with on a frontier model and pin the workers to something cheaper.

The defaults are generous. Up to 10 children run in parallel per batch, each child can take 250 turns, and there is no wall-clock timeout. We start new setups at 3 children, 60 turns, and a 30-minute cap. Those are our starting numbers, not vendor limits. Raise them once you have seen what a real batch costs.

Leave max_spawn_depth at 1. That keeps delegation flat: the main agent spawns workers, and workers cannot spawn their own. Every extra level multiplies how many agents can run at once. Restart Hermes after editing the file so the new values load.

delegate_task has no toolsets parameter for the model to fill in. That is deliberate: a model cannot hand a child a capability its parent lacks. The flip side is that you cannot give one child web access and deny it the terminal while another child keeps both. Start the session with the tools the whole job needs and nothing more.

Some tools are always removed from children. They cannot ask you clarifying questions, write to memory, send messages to other platforms, or schedule cron jobs. Leaf children, the default role, also cannot delegate further. They keep the terminal, file tools, web tools, and code execution when the parent has them.

Open Hermes in the repository you want worked on and ask for work that splits cleanly. You do not call delegate_task yourself. The main agent does, when the task is complex enough, and it can pass a list of tasks that run in parallel. The call returns a handle right away, so you can keep typing while the children work. By default their results come back as one consolidated message once all of them finish.

The rule that matters most is written in the docs as a warning: subagents know nothing. Each child starts a fresh conversation with only the goal and context the parent writes for it. It does not see your chat history. The one exception is project context files. AGENTS.md, CLAUDE.md, .hermes.md, or .cursorrules in the workspace are embedded automatically. Everything else, including file paths, error messages, commands to run, and what done looks like, has to come from your prompt, because the parent can only pass on what it knows.

Ask for independent work. Children in a batch run at the same time, so if task B needs the output of task A, run A first and ask for B afterwards.

While children run, the classic CLI, the TUI, and the desktop app show a dock above the composer with the live count, task names, elapsed time, and latest activity. You can keep typing underneath it. Press F7 to collapse the dock to a single summary line when it takes too much room.

Press Ctrl+T to open the full roster. In the classic CLI (F6 also works), pick a worker with the arrow keys, press Enter to read its transcript tail, s to send it guidance, and x then y to stop it. In the TUI, Ctrl+T or /agents opens a tree: Enter or t for the live transcript, d for details, e to steer, x to stop one worker, and capital X to stop it and everything under it.

Steering is queued, not instant. The child reads your guidance at its next checkpoint. Stopping one worker leaves its siblings running. /stop, /new, or closing the session cancels every child that session owns, so leave the window open while a batch is in flight.

Type /bg followed by a prompt. Hermes confirms with a task ID and hands your prompt line straight back. The background agent uses the same model, provider, toolsets, and reasoning settings as your session, but it knows nothing about the conversation so far. Write the prompt as if you were briefing someone who just walked in.

You can start several. The status bar shows a ▶ with the number still running, and each result lands as its own panel in the terminal when it finishes. Background sessions are not added to your main conversation history, so copy out anything you need.

/bg and subagents look alike and suit different jobs. Subagents work for the main agent: it writes their briefs, waits for them, and merges their results. /bg works for you: you write the brief, and the main agent never sees the result unless you paste it in. For a quick question about the current conversation that should not derail it, /btw is lighter still. It answers from a snapshot of the transcript and leaves the running turn alone.

Start Hermes with hermes --tui. Press Ctrl+X or type /sessions to open the switcher, which lists every session live in this TUI process. Select +new, type a prompt, and press Enter to dispatch a new session with that prompt. Press Tab before Enter to choose a model for just that session.

Inside the switcher, Enter jumps to the selected session, Ctrl+N opens a blank one, Ctrl+D closes one, and Esc returns you to where you were. A closed session stays saved and can be reopened later with /resume.

Use this when the parallel pieces are conversations rather than tasks. A frontend session and a database migration session that each need back-and-forth with you belong here. A fan-out of five read-only checks belongs to subagents.

Live sessions opened in the same folder edit the same files. If two of them will change code, give each its own git worktree first, as step 09 shows.

By default every child shares the parent's working directory, and two children editing one file will overwrite each other. Set delegation.worktree_isolation to true and each child starts in <repo>/.worktrees/subagent-<id> on a branch named hermes-subagent/subagent-<id>, created from your current HEAD. Your own checkout stays untouched.

When a child finishes, its result reports the worktree path, branch, commit count, and whether the tree is dirty. A worktree with no commits and a clean tree is removed automatically. Anything holding work is kept for you or the main agent to review and merge.

Isolation only applies inside a git repository on the local terminal backend. In a non-git folder, on Docker, SSH, or Modal backends, or when worktree creation fails, Hermes quietly falls back to the shared workspace. Check git worktree list after the first batch to confirm it took effect.

For editing agents in live sessions, hermes -w starts a session in its own worktree and branch. The docs recommend one hermes -w per terminal for fully parallel editing, which is the one pattern in this guide that goes beyond a single window.

Run /review on its own, or add a focus. Hermes starts a background reviewer with the full subagent toolset, so it opens the pull request, reads the diff, and runs code instead of judging from a summary. It appears in the dock like any other worker, and its report re-enters your session where the main agent can act on it.

Give the reviewer a strong model even when your workers are cheap. The auxiliary.review setting pins it separately from delegation.model. Without it, the reviewer uses your main model.

Subagents and /bg sessions are not durable. Closing the session, /stop, or a process restart cancels or strands them. For work that runs for hours, waits on a human, or should go to a named specialist tomorrow, Hermes has a second model.

A profile is a fully separate Hermes agent with its own config, keys, memory, sessions, and skills. The Kanban board is a task queue shared by every profile on the machine, and a dispatcher inside the Hermes gateway starts each worker as its own hermes -p process. The docs put the difference in one line: delegate_task is a function call, and Kanban is a work queue.

You can still drive the board from one chat window, because every hermes kanban command also works as /kanban inside a session. One rule from the profiles guide: never point two running agents at the same profile. Both write memory, and each loads the other's writes at startup.