Orchestrator = judgment
The orchestrator owns the task framing, picks what to delegate, and decides what to trust. It is the one with the holistic view.
In Hermes, a minion is a separate helper session launched by an orchestrator agent. The orchestrator keeps the big picture, then spins up minions to research, inspect, click through pages, summarize, compare options, or handle repetitive work without cluttering the main thread.
Think of the setup as a tiny crew. A human or outside trigger asks for something. The orchestrator decides what matters, breaks the work into parts, and launches minions with tightly scoped instructions. Those minions do bounded work and return results. The orchestrator checks the output, merges the useful bits, and presents a coherent answer.
A minion is not just a mood. It is a separate conversation session created through delegate_task or a comparable orchestration path. It gets its own instructions, its own context bundle, and its own tool permissions.
The orchestrator owns the task framing, picks what to delegate, and decides what to trust. It is the one with the holistic view.
A minion sees only the packet it was given. That keeps side quests, irrelevant pages, and low-value noise out of the main context.
The orchestrator can pass files, URLs, error text, constraints, output format, and tool limits. If a minion needs something, it has to be handed over directly.
Cheap minions can do broad, repetitive, or low-risk work. Stronger models can be reserved for synthesis, debugging, or judgment-heavy decisions.
Minions do not invent their own mission. Their behavior comes from layered instructions, each with a different purpose.
| Layer | What it does |
|---|---|
| System prompt | Defines the broad role, safety boundaries, and tool behavior expectations. |
| Task goal | States what this minion is supposed to accomplish right now. |
| Context packet | Provides the relevant file paths, URLs, error messages, notes, or summaries. |
| Tool scope | Limits the minion to the specific toolsets needed for the job. |
| Return format | Tells the minion how to report back so the orchestrator can use the result cleanly. |
Owns the relationship with the user, holds the overall plan, and decides when to delegate.
Focused helpers that do one thing well: search, inspect, summarize, verify, click through a flow, or analyze a document.
Purpose-built variants for code review, QA, data collection, browser inspection, or research synthesis.
Instead of stuffing every URL, console log, and dead end into the main chat, the orchestrator gets back a compact answer.
Independent subtasks can be split across multiple minions instead of forcing one long serial chain.
Bulk reading, preliminary sorting, or repetitive scraping can run on lower-cost models while judgment stays with the main agent.
Because minion outputs come back as bounded reports, the orchestrator can check important claims before presenting them as truth.
A fun site deserves fun roles, but the roles should still map to useful behaviors. Here is a simple playbook for how a minion crew can be thought about.
Search widely, pull candidate sources, skim quickly, and bring back the shortlist worth deeper attention.
Run commands, inspect logs, test a page, or follow an interaction path while the orchestrator watches from above.
Summarize long docs, cluster notes, compare versions, and turn scattered material into a compact brief.
Challenge assumptions, verify claims, test edge cases, and catch places where the first pass sounds better than it is.
| Job shape | Good delegation choice |
|---|---|
| Read 40 pages and pull recurring themes | Cheap minion first, stronger orchestrator later for synthesis |
| Inspect a live page and list visible controls | Browser-capable minion with narrow scope |
| Judge whether a change is safe or a claim is trustworthy | Keep final judgment with the orchestrator |
| Break work into two unrelated research threads | Use parallel minions, then merge results |
Minions are useful, but they are still agents making claims. Treat their summaries as reports, not holy writ.
If a minion says it uploaded a file, changed a page, or created an artifact, check the returned path, URL, ID, or status.
Ask for screenshots, paths, excerpts, IDs, or structured summaries rather than vague "it worked" language.
A clean summary can hide shaky evidence. The orchestrator should still sanity-check what matters.
If a minion looks confused, the usual fix is not "smarter vibes." It is a better packet: better files, better constraints, better examples.
The main agent that owns the relationship, plans the task, and decides what to delegate.
A bounded helper session created to do a specific subtask with limited context and tools.
The files, URLs, notes, and instructions passed to a minion when it is launched.
A restricted toolset granted to the minion so it can do the job without unnecessary access.
The step where the orchestrator combines minion outputs into a final, user-facing result.
The practice of checking whether a minion's claims are backed by evidence before treating them as settled fact.