I ran one hermes agent as researcher, writer, coder, and orchestrator for 14 days on a single claude-sonnet-4.6 profile before everything blurred into the same voice. Most operators blame the prompt when this happens, but it is not prompting and not the model - it is one agent carrying five roles on shared memory, and everyone says "better prompts" while nobody talks about the Hermes primitive that actually fixes it: isolated profiles.[@neoaiforecast](https://x.com/@neoaiforecast) posted the team build last week: orchestrator + alan + mira + turing, four roles, clean handoffs, 1,317 bookmarks in a day. The build is correct, but it stops at day one. This guide picks up at day two and takes you through the operator layer that keeps a 4-profile team coherent on day 30 -handoff contracts, memory-kpi per profile, policy gates per role, and the four failure modes nobody posts screenshots of.If you ignore the operator layer, your team collapses into a single blurry agent within a month.Below: the mental model, the 4-role team, the 7-step build, the operator runbook, the day-30 failures, and a copy-paste team-agents.md template.Save this to your bookmarks.The mental model — roles, not personas
The wrong mental model is: I need one genius AI that does everything.The better mental model is: I need a small team with distinct roles, clear handoffs, and less context pollution.Hermes profiles are the primitive that makes this real. They are not character skins. Each profile isolates seven pieces of state at once:- configuration
- sessions
- memory
- skills
- personality
- cron state
- gateway state
The 4-role team
Credit to [@neoaiforecast](https://x.com/@neoaiforecast) for naming the canonical split. Four profiles, mapped to real functional work:- Hermes — orchestrator. plans, decomposes, routes, synthesizes. the traffic controller, not the bottleneck.
- Alan — research specialist. source-first, skeptical, uncertainty-aware. protects the team from hallucinated confidence.
- Mira — narrative architect. clarity, structure, and audience awareness. turns validated material into communication.
- Turing — builder and debugger. implementation, logs, diffs, reproducibility. cares about tests, not narrative polish.
The 7-step build
The table-stakes sequence. If you have already run this from [@neoaiforecast](https://x.com/@neoaiforecast)'s post, skip to the operator layer.**Step 1 - start from a working Hermes**Make sure your base Hermes installation is healthy before cloning. Model provider configured, auth working, normal session usable. You clone from this base, so anything broken here breaks four times.**Step 2 - create the specialist profiles**hermes profile create alan --clone
hermes profile create mira --clone
hermes profile create turing --clone
hermes profile list
ls ~/.hermes/profiles/
- Hermes (orchestrator): planning, delegation, synthesis, final qa. sounds structured and decisive.
- Alan (research): evidence, verification, depth, uncertainty. sounds source-first and skeptical.
- Mira (writer): clarity, structure, audience. sounds clear and audience-aware.
- Turing (engineer): implementation, debugging, tests, reproducibility. sounds precise and test-oriented.
hermes -p alan
hermes -p mira
hermes -p turing
The operator layer - what Neo's guide stops at
This is where the guide stops being a setup post and starts being an ops runbook. Most multi-agent teams look great on day one and feel blurry by day 30. The operator layer is the difference.**handoff contracts between profiles**profiles specialize, which means they also have to hand work off cleanly. A handoff without a contract becomes "Alan dumped 40kb of raw research into Mira's session, and now Mira is also a researcher again."A handoff contract is one file per role pair, stored at~/.hermes/team/handoffs/<from>-to-<to>.md,
- Input shape: what the receiving profile expects (e.g., Alan → Mira: A ranked list of validated claims with source URLs, not raw excerpts)
- Output shape: what the receiving profile will return (Mira → Hermes: A drafted section with a change log, not a finished article)
- Failure action: what happens if the input is malformed (block, require-human-review, retry with adjusted prompt)
- Verification gate: one assertion that must be true before the handoff completes (for Alan → Mira: every claim carries a source URL; for Turing → Hermes: every fix has a passing test)
for p in alan mira turing; do
hermes -p $p memory-kpi --json | jq '.source_backed_pct, .stale_notes, .contradiction_notes'
done
- Alan (research): risk class safe. Can read web, read repo, write to research/ only. Cannot run shell commands. Cannot write outside its sandbox.
- Mira (writer): risk class safe. Can read research outputs, write to drafts/ only. Cannot read secrets, cannot execute code.
- Turing (engineer): risk class review. Can read repo, run sandboxed tests, write to a feature branch. Every commit to main requires explicit orchestrator approval.
- Hermes (orchestrator): risk class critical. The only profile that can approve Turing's commits, merge branches, or trigger paid api calls above a budget ceiling.
Gateway messaging for remote supervisionThe profile system is a local org chart. The gateway turns it into an operational system you can supervise from a phone.Wire each profile to its own messaging identity:No profile gets more permission than its role needs, and the orchestrator is the only one who can widen any other profile's scope.
- Alan posts research findings to a #research channel
- Mira drops drafts to a #writing channel
- Turing posts test results and pr links to #engineering
- Hermes synthesizes into #ops and asks for human approval on critical actions
Day 30 failure modes - the four things that break
Every 4-profile team I have watched in the past months hits at least one of these. All four are preventable.**Failure 1 - Profile drift**SOUL.md edits accumulate. A week ago, Mira was "clear and audience-aware." Today, Mira is "clear, audience-aware, technically precise, and willing to draft implementation notes." Congratulations - Mira is slowly becoming Turing.Patch: diff each SOUL.md weekly against its day-one version. Any new responsibility gets an explicit approval log entry, or it gets reverted.**Failure 2 - Handoff rot**The contract file exists, but nobody enforces it. Alan starts sending raw transcripts to Mira again. Mira starts asking Turing to "just check this one thing." Boundaries dissolve.Patch: Wire each handoff file into the harness. If the input does not match the declared shape, fail the handoff and require human review. The contract is only real if it can block.**Failure 3 - SOUL.md bloat**Each role grows edge cases. Turing gets a paragraph about "how we handle Python 2 legacy code." Alan gets three paragraphs about "when to skip peer-reviewed sources." Within a month, each SOUL.md is 2kb of special cases, and the agent loses the original identity in the noise.Patch: Cap SOUL.md at 400 words. Anything beyond that goes into AGENTS.md or a per-domain reference file. identity stays stable; context rotates.**Failure 4 - Cron collision**Profiles run cron jobs. Alan pulls a weekly research digest. Mira regenerates a weekly draft. Turing runs nightly test sweeps. Hermes runs a daily orchestration pass. By week four, two of them are colliding at 3 am because nobody coordinated the schedule.Patch: one shared ~/.hermes/team/cron.md file listing every scheduled task across every profile with its exact time, duration, and dependency. stagger collisions. Check the file before adding a new cron to any profile.The team reference file - copy-paste template
One file, one purpose: explain your team to yourself and anyone else using the system six months from now.# ~/.hermes/team-agents.md
## roster
- **hermes** (orchestrator): plans, routes, approves, synthesizes
- **alan** (research): source-first, skeptical, uncertainty-tagged
- **mira** (writer): clarity, structure, audience-aware
- **turing** (engineer): implementation, tests, reproducibility
## when to use which profile
- starting a new project → hermes (scopes and decomposes)
- validating a claim → alan (source check, uncertainty tag)
- drafting anything external-facing → mira (audience-first)
- writing or debugging code → turing (test-first)
## handoff rules
- alan → mira: ranked claims with source urls. no raw transcripts.
- mira → hermes: drafted section + change log. not a finished article.
- turing → hermes: feature branch + passing tests + diff summary. not a merge.
- hermes → any: scoped task with acceptance criteria and failure action.
## good output per profile
- alan: every claim has a source url and a confidence tag.
- mira: every section has a named audience and a clear thesis.
- turing: every change has a passing test and a reproducible diff.
- hermes: every synthesis names the contributors and the open questions.
## policy ceilings
- alan: read-only outside research/
- mira: read research/, write drafts/
- turing: read repo, write feature branch, run sandboxed tests
- hermes: only profile allowed to approve merges, widen permissions, or spend above budget
## cron schedule
(edit weekly; stagger to avoid 3am collisions)
- mon 6am — alan: weekly research digest
- tue 6am — mira: draft refresh from alan's digest
- wed 6am — turing: test sweep + flaky test report
- thu 6am — hermes: weekly synthesis + handoff audit
The agent extraction layer
- Objective: run a 4-profile Hermes team that stays coherent past day 30
- Inputs: working Hermes base, profile cli, SOUL.md + AGENTS.md split, handoff contracts, per-role policy, gateway messaging
- Process: build the 4 profiles with - clone, write a distinct SOUL.md per role, keep project context in AGENTS.md, encode handoff contracts at ~/.hermes/team/handoffs/ and per-role policy in each config.yaml run weekly memory-kpi per profile, diff each SOUL.md against day-one, stagger cron, enforce team-agents.md via commits
- Outputs: Four isolated profiles, per-role policy blocks, handoff contract files, staggered cron schedule, messaging routes, versioned team reference
- Guardrails: No SOUL.md edit without a logged reason - No handoff accepted without the declared input shape - No role widened without orchestrator approval - No cron added without checking the shared schedule