Part 4: The Workforce — Four Specialists, Each With Its Own Brain
60-second video version of this part.
In Part 3 we stood up a single orchestrator profile with a frontier model and its own rules. Now we put people around it. The trick: each specialist is a full profile, not a chat tab — its own model, its own skills, its own memory, its own rules. Clone the orchestrator's config so they share the same base toolkit, then customise each one for its job.
Clone once, customise four times
Creating a specialist from the orchestrator's config is a real, one-line operation:
# Real: clone the orchestrator's profile config into each specialist
hermes profile create researcher --clone-from orchestrator
hermes profile create writer --clone-from orchestrator
hermes profile create growth --clone-from orchestrator
hermes profile create dev --clone-from orchestrator
Now you have four isolated profiles that inherit the orchestrator's base setup. But a generic clone doesn't know how to research, write, grow, or build. That's the customisation step — and this is where each specialist stops being a copy and becomes a specialist.
Give each specialist its own model
The orchestration logic I gave on Part 3 (frontier model for coordination) is reversed for specialists: most specialist work benefits from an open-weight local model (e.g. via local Ollama) — it's fast and cheap for its narrow lane — while the orchestrator keeps the frontier model for the hard reasoning. On the clone, set the specialist's default model:
# Real: point the specialist's default at an open-weight local model
hermes config set model.default "<open-weight local model, e.g. via local Ollama>"
hermes config set model.provider "custom:local-ollama" # conceptual: your local provider name
(The provider name above is conceptual/illustrative — the real value is your own local Ollama endpoint's provider name. The config keys are real.)
Give each specialist its own skills
Skills are the profile's procedural memory — reusable procedures that load into its sessions. A researcher wants search and extraction skills; a writer wants drafting and editing skills; growth wants distribution and campaign skills; dev wants coding and testing skills. Install skills per profile:
# Real: run as the target profile so the skill lands in ITS directory
hermes -p researcher skills install <skill-id>
hermes -p writer skills install <skill-id>
The -p <profile> flag is the whole game here. It makes every command run as that
profile — so its skills, memory, and config are what get touched, not the global default.
Give each specialist its own memory — and its own rules
Each clone already has its own memories/MEMORY.md and USER.md. That's deliberate: the
writer's memory should hold voice and style notes, the growth agent's memory should hold
channel and campaign lessons, the dev's memory should hold architectural facts. They should
not share the same memory file — they're different people with different jobs, and
they'll each build their own body of durable facts.
Each profile also gets its own SOUL.md — its standing operating rules, the "here's how
you behave and what you must remember to do" file. This is where a specialist adopts the
rules that make it useful and compatible with the rest of the fleet.
Run something as a specialist
The real way to invoke a specialist so it uses that profile's model, skills, and memory is
-p <profile> — and for anything with follow-up steps, in a named continuing session rather
than a stateless one-shot:
# Real: run a one-shot query AS the writer profile
hermes -p writer chat -q "Draft a 400-word intro about solar energy"
# Real: run as the writer in a named continuing session (keeps memory across calls)
hermes -p writer chat --continue writer-session --create-if-missing
The prompt-based path
The four profile create --clone-from commands plus the per-profile model/skills/memory
customisation can be handed to an assistant in one go. Here's the prompt:
Build four specialist profiles in Hermes by cloning the "orchestrator"
profile: researcher, writer, growth, dev. Each should run a cheap
open-weight local model via Ollama instead of the orchestrator's frontier
model — they're doing narrow, repeatable work, not complex coordination.
Install search/extraction skills for researcher, drafting/editing skills for
writer, distribution/campaign skills for growth, and coding/testing skills
for dev. Keep each profile's memory and SOUL.md separate — don't let them
share state. Show me each command before running it.
Why this prompt reverse-engineers into the setup above: "cloning the orchestrator
profile" is literally the --clone-from orchestrator flag, run once per name. "Cheap
open-weight local model... narrow, repeatable work" is the plain-English justification for
the model.default override shown in the CLI block — the assistant doesn't need you to
specify the Ollama provider string, just the intent, and it fills in model.provider the
same conceptual way the post marks it. The per-specialist skill list maps one-to-one onto
four hermes -p <profile> skills install <skill-id> calls. "Don't let them share state" is
you stating, in plain language, the exact rule this section makes explicit: each profile
keeps its own memories/MEMORY.md and SOUL.md.
The mistake Part 4 exposes
Here's what bites most people: building four profiles but never giving them their own memory and rules, then wondering why they all "sound the same" and forget their lane. Specialisation isn't just a name on a profile. It's owning different model, different skills, different memory, different rules — otherwise you've made four copies, not four specialists.
The punchline for Part 4: a specialist is a profile, fully. Clone the config, then give each one its own model, its own skills, its own memory, its own rules. Four isolated brains, each good at one job, all ready to be run under an orchestrator.
Next problem: they all still forget across sessions — unless we build the shared memory layer they read and write together.