Part 3: Build the Orchestrator First — One Profile With a Brain
60-second video version of this part.
A tempting instinct when building a fleet is to start with the specialists — the researcher, the writer, the engineer — because they do the visible work. I get it. But the right first move is the opposite: stand up one orchestrator profile, alone, before any specialists exist. Here's why, and here's the real setup.
Why the orchestrator comes first
The orchestrator is the one that sees the whole picture. It decides what each specialist does, routes work, tracks the mission, and catches errors. If you build the specialists first, you have five isolated tools and nobody owning the mission. Build the brain first and everything else has somewhere to plug in.
There is also a dirt-simple practical reason: you need a control surface to run the specialists from. The orchestrator is that surface.
What a "profile" actually is
In Hermes, a profile is an independent instance with its own configuration, sessions, skills, and memory. It lives in its own directory and is deliberately isolated from every other profile. This is the unit of "one agent." Creating one is real:
# Real: create a named profile
hermes profile create orchestrator
You create more from it later (including clones of its config — that's how specialists inherit the same toolkit without reconfiguring from zero):
# Real: clone an existing profile's config into a new one
hermes profile create researcher --clone-from orchestrator
What a fresh profile looks like on disk
Every profile lives at ~/.hermes/profiles/<name>/ with the same layout. Here is the
real structure (verified on this machine):
~/.hermes/profiles/orchestrator/
├── config.yaml # settings: model, memory, terminal — NEVER secrets
├── SOUL.md # the profile's standing instructions / operating rules
├── .env # secrets ONLY, never in config.yaml
├── memories/
│ ├── MEMORY.md # persistent cross-session memory (declarative facts)
│ └── USER.md # who the user is
├── skills/ # the profile's installed skills
└── sessions/ # session transcripts / state
Configuration: real keys, generic models
Here is a trimmed config.yaml with the real keys Hermes actually uses. Per our fleet
naming decision, model names are generic — the orchestrator runs a frontier model for
complex reasoning and coordination, while specialists later run open-weight local
models (e.g. via local Ollama):
model:
default: <frontier model> # orchestrator: complex reasoning / coordination
provider: <your provider>
memory:
memory_enabled: true # load persistent memory at session start
user_profile_enabled: true
memory_char_limit: 2200
terminal:
backend: local
skills:
creation_nudge_interval: 15
agent:
max_turns: 90
You don't hand-edit this file — Hermes warns a stray indent can corrupt a live gateway. Use the real command instead:
# Real: set config by key, never by hand-editing
hermes config set memory.memory_enabled true
hermes config set terminal.backend local
The prompt-based path
Instead of running hermes profile create and the two config set calls yourself, you
can hand the whole setup to an AI coding assistant with a prompt like this:
Set up a new Hermes profile called "orchestrator" that will coordinate a
small fleet of specialist agents later. It needs persistent memory enabled
(it should read its memory files at the start of every session) and a local
terminal backend. Use a frontier-capable model for it, since it'll be doing
the hardest reasoning — routing work, resolving conflicts, judging
specialist output. Run the real Hermes commands, show me each one before
you run it, and don't hand-edit config.yaml directly.
Why this prompt reverse-engineers into the exact config above: every clause maps to a
specific command. "Set up a new profile called orchestrator" → hermes profile create
orchestrator. "Persistent memory enabled... reads memory files at session start" →
hermes config set memory.memory_enabled true (the same memory_enabled key shown in the
YAML). "Local terminal backend" → hermes config set terminal.backend local. "Frontier-
capable model... hardest reasoning" is the plain-English version of the comment next to
model.default in the YAML — it's the same design reasoning given in prose instead of as a
code comment. "Don't hand-edit config.yaml" is you asking the assistant to respect the same
rule the post states explicitly: use config set, never a raw file edit.
Why the orchestrator's profile gets the frontier model
The orchestrator does the hardest cognitive work in the fleet: parsing a vague mission, breaking it into steps, routing work, resolving conflicts, and judging when a specialist's output is good enough. That is exactly the kind of complex, multi-step reasoning where an open-weight local model often falls short and a frontier model earns its keep. So Part 3 rule one: spend your most capable model on the brain, not on the labour.
What Part 3 sets up
By the end of this part you have a single, isolated orchestrator profile with its own memory, its own model, and its own standing rules. Nothing else exists yet — that's correct. It's one lonely profile with a brain and no assistants.
That loneliness ends next time, when we clone this profile into specialists and give each one its own model, its own skills, and its own memory.