Day 7: Multi-Agent Is Division of Labor, Not Group Chat

Do not use multi-agent because it sounds cool

Multi-agent orchestration is the easiest topic to turn into science fiction: a researcher, writer, reviewer, and operator all working at once. It sounds powerful. The first-principles question is simpler: does it reduce the total cost of finishing the task?

If not, it only splits one confusing problem into several confusing problems.

When the split is worth it

A task is a good candidate when:

1. Subtasks are genuinely independent.
2. Each subtask has clear input and output.
3. A final owner must synthesize the result, not paste it together.

Good examples:

1. Competitive analysis: one agent researches sources, one compares features, one reviews risk.
2. Code review: one reads the diff, one runs tests, one checks security.
3. Content production: one gathers material, one drafts, one checks facts and tone.
4. Incident review: one reads logs, one checks deployments, one builds a timeline.

Bad examples:

1. The goal is still vague.
2. The next step depends on the previous result.
3. Every agent is doing the same work.
4. Nobody owns the final decision.

The host agent has a real job

The host is not a clipboard. It must:

1. assign responsibilities;
2. give every worker an output contract;
3. compare conflicts;
4. decide what to accept, reject, or investigate.

The human remains the final owner. Sending messages, changing files, deploying services, and spending money should not be delegated to a sub-agent without approval.

A three-agent template

goal: "evaluate whether the Day 1 tutorial is beginner-friendly"
agents:
  researcher:
    job: "read tutorial and source material, list user questions"
    output: "bullets with evidence"
  operator:
    job: "follow the tutorial commands and record friction"
    output: "steps passed / failed"
  reviewer:
    job: "check privacy, permissions, dead links, and misleading language"
    output: "risks with severity"
host:
  job: "merge conflicts and produce final edits"
human_approval:
  - publish
  - delete files
  - push changes

The important part is that every agent has a different responsibility and comparable output.

Common failures

1. Giving the same prompt to three agents and receiving three duplicate answers.
2. Not requiring evidence or assumptions.
3. Letting sub-agents execute high-risk actions.
4. Host agent pastes instead of judges.
5. Parallelism creates more waiting and coordination than it removes.

Ship this artifact

Create hermes-day-7-orchestration.md:

task: "your real multi-step task"
split_reason: "parallel research / independent checks / separate expertise"
roles:
  - researcher
  - operator
  - reviewer
handoff_format:
  - findings
  - evidence
  - assumptions
  - open_questions
final_owner: "human"
do_not_delegate:
  - publish
  - spend money
  - delete files

The seven-day path now has a product loop: run Hermes, give it durable context, put it where requests happen, process real material, capture repeatable workflows, schedule stable work, and finally split complex work across specialists.

Next step

1. Top 10 Hermes Skills - extend Hermes with low-risk Skills first.
2. Hermes vs OpenClaw - understand the positioning difference.

Beginner Walkthrough: Your First Multi-Agent Split

Multi-agent work is not opening many chats. For the first run, use three roles: one researches, one simulates execution, one reviews risk, and you decide.

Step 1: Define the goal first

Goal: check whether the Day 1 tutorial works for a complete command-line beginner.
Final artifact: suggested edits only, no automatic file changes.

Step 2: Split three roles

researcher:
  job: "list confusing terms"
  output: "questions + section"
operator:
  job: "simulate the steps and record friction"
  output: "passed / failed / needs image"
reviewer:
  job: "check permissions, secrets, and risky actions"
  output: "severity + suggested fix"
owner: "human"

Step 3: Use one handoff format

Findings:
- what is wrong

Evidence:
- section or step

Suggested change:
- proposed edit

Confidence:
- high / medium / low

Step 4: Isolate with a separate home when experimenting

HERMES_HOME=~/.hermes-day7-research hermes

If you are not sure, keep it as text-only delegation in the main session and do not change configuration.

Step 5: Human merges

Merge researcher/operator/reviewer results.
Do not edit files yet.
Return three lists: must change, should change, do not change yet.

Common Day 7 problems

1. Every agent does the same task: roles are unclear.
2. Output is long but unusable: no shared handoff format.
3. Sub-agent edits files directly: risky actions were not reserved for the human.
4. Parallelism is slower: tasks actually depend on each other.

Leave this file behind

task: "review beginner tutorial"
roles:
  - researcher
  - operator
  - reviewer
handoff_format:
  - findings
  - evidence
  - suggested_change
  - confidence
human_approval_required:
  - edit files
  - publish
  - push to GitHub