Chapter 10

Multiple Agents and Subagents

In Chapter 3, you defined two profiles: an SEO manager and a research specialist. In Chapter 8, you saw the research specialist run through the agent loop to find keywords. In Chapter 9, you wrote skills for both roles — a keyword research skill and a content brief skill — with clear output contracts and judgment gates between them.

Two profiles, two skills, one handoff. That is a functional starting point. But most real workflows need more than two agents doing two things. You need a SERP analyst to examine the top-ranking pages. You need a writer to draft the article. You need a reviewer to catch gaps before anything publishes. And you need these agents to work in the right order, on the right files, without overwriting each other's output.

This chapter answers three questions: when should you create a new profile versus spawning a temporary subagent? How do you coordinate multiple agents so they do not step on each other? And how does this work in practice for your SEO workflow?

Two kinds of agents

versus

A profile is a durable identity. It has its own system prompt, its own memory, its own skills, and its own session history. It persists across sessions — when you start a new session with the research specialist profile, it loads the memory, skills, and preferences from all prior sessions. Profiles are your permanent team members.

A subagent is a temporary worker. It starts with fresh context — no prior session history, no accumulated memory from previous runs. It has access to the same tools as the parent profile that spawned it. It does its task, returns the results, and then disappears. Subagents are your one-off contractors.

Use a profile when

  • The role will repeat across sessions — keyword research, content briefs, SERP analysis, writing
  • The agent needs to carry forward memory and skills — your style rules, prior findings, learned preferences
  • The agent needs its own toolset configuration — web search for the researcher, file tools only for the writer
  • You want the agent to accumulate expertise over time — better filtering, sharper output, fewer corrections needed

Use a subagent when

  • The task is a one-off — run a single search, check a single page, verify a single fact
  • You want parallel execution — two research tasks at the same time, each in its own isolated context
  • The task needs fresh context — no risk of contamination from the parent agent's accumulated conversation
  • The result feeds back into a profile — the subagent does the work, the profile stores the learning

The practical difference comes down to persistence. Profiles compound: they get sharper over time because they carry forward memory, skills, and corrections. Subagents are disposable: they do clean work because they start with no baggage, but they also start with no accumulated knowledge. For recurring roles in your workflow, profiles are the right choice. For parallel or isolated tasks, subagents are the right choice.

Coordination

: a shared board for multiple workers

When you have multiple profiles running tasks — a researcher, a writer, a reviewer — you need a way to coordinate them. The simplest approach is direct handoff: the research specialist saves a file, and the SEO manager reads it. That works for two agents. It breaks down at three or more.

Kanban is the coordination system. It provides a shared task board where each task has an assignee, a status, and a heartbeat. The board lives in a SQLite database — durable and independent of any single agent process. Multiple profiles can read from and write to the same board without stepping on each other.

Here is how kanban works in practice:

Create a task

You (or a profile) create a task on the board with a description and an assigned profile. The task starts in a ready state, waiting to be claimed.

Claim and start

The dispatcher — a long-lived process that runs alongside the gateway — picks up ready tasks and spawns the assigned profile to work on them. The profile claims the task atomically: no two agents can claim the same task.

Heartbeat

While working, the agent sends regular heartbeats to the board. These signals tell the dispatcher that the agent is still active. If heartbeats stop, the task is considered stalled.

Reclaim stalled tasks

If an agent stops responding (a "zombie"), the dispatcher detects the missing heartbeats and reclaims the task. It unassigns the stalled agent and puts the task back in the ready state for another agent to pick up. This prevents tasks from sitting permanently unclaimed.

Complete or block

When the agent finishes, it marks the task as complete. If the agent hits a problem it cannot solve, it marks the task as blocked — with a comment explaining why. Blocked tasks stay visible until a human or another agent resolves the blocker.

Hand off

A completed task can be linked to the next task in the workflow. The SERP analyst finishes analyzing results, and the next task — write the article — is automatically promoted to ready. The chain continues without manual coordination.

Your SEO workflow

From two agents to a coordinated team

In Chapter 3, you started with two profiles: an SEO manager and a research specialist. In Chapter 9, you gave each a skill and an output contract. Now it is time to expand the team. Your SEO workflow needs four distinct roles — and each one should be a separate profile, not a subagent, because all four roles repeat every week and each accumulates expertise over time.

Research specialist

Finds keyword ideas using web search. Has the keyword research skill from Chapter 9. Writes results to keywords.md. Accumulates knowledge about which sources work best for your niche. Toolsets: web search, file read/write.

Toolsets: Web search, file read/write

SERP analyst

Reads the keyword file from the research specialist, then examines the top-ranking pages for each target keyword. Reports on what the top results cover, what gaps exist, and what formats rank well (listicle, how-to, comparison). Writes findings to serp-analysis.md. Toolsets: web search, file read/write.

Toolsets: Web search, file read/write

Content writer

Reads the SERP analysis and keyword file. Drafts the article following the content brief skill (adapted from the SEO manager's brief skill in Chapter 9). Writes the draft to draft.md. Does not publish — waits for review. Toolsets: file read/write, web search (for fact-checking).

Toolsets: File read/write, web search

SEO manager

The orchestrator. Reviews the draft, checks it against your brand voice and style rules stored in memory, and either approves for publishing or sends it back for revision. Manages the kanban board: creates tasks, assigns them, and reviews completed work. This is your judgment gate — nothing publishes without the manager's sign-off. Toolsets: file read/write, kanban.

Toolsets: File read/write, kanban

Notice the shift from Chapter 3. The SEO manager is no longer both the strategist and the drafter. It is now purely the orchestrator and reviewer — the role that holds your judgment. The content writer handles drafting. The SERP analyst handles competitive analysis. The research specialist handles keyword discovery. Each profile has one job, one set of tools, and one output contract.

This separation matters because it prevents context pollution. If one agent both researches keywords and drafts articles, the keyword search results fill up its context window — leaving less room for the writing task. Split roles keep each agent's context focused on its own work.

Task flow

How the kanban board coordinates your team

Here is how the four roles work together through the kanban board, week after week:

Step 1 — The SEO manager creates tasks

You tell the SEO manager: "Start this week's content cycle." The manager creates four linked tasks on the kanban board: (1) keyword research, (2) SERP analysis, (3) content writing, (4) draft review. Tasks 2–4 are blocked until the previous task completes.

Step 2 — Research specialist claims the first task

The dispatcher picks up the ready task and spawns the research specialist. The specialist runs its keyword research skill, saves results to keywords.md, and marks the task complete. Heartbeats confirm the agent is working throughout.

Step 3 — SERP analyst picks up the next task

Task 1 is complete, so task 2 (SERP analysis) becomes ready. The dispatcher spawns the SERP analyst. It reads keywords.md, analyzes the top results for each keyword, writes findings to serp-analysis.md, and marks the task complete.

Step 4 — Content writer drafts the article

Task 2 is complete, so task 3 (content writing) becomes ready. The writer reads the keyword file and SERP analysis, drafts the article in draft.md, and marks the task complete. The writer's skill includes the judgment gate: do not publish, wait for review.

Step 5 — SEO manager reviews and approves

Task 3 is complete, so task 4 (draft review) becomes ready. The SEO manager reads the draft, checks it against your style rules in memory, and either approves or blocks the task with revision notes. If approved, the content is ready for publishing — but only you decide when to actually publish.

If the research specialist stalls — say, a web search tool fails repeatedly — the heartbeats stop. The dispatcher detects the stall, reclaims the task, and puts it back in the ready state. Another run of the research specialist picks it up. No manual intervention needed.

If the SEO manager blocks the draft review task, it stays visible on the board with the manager's comments. You see the blocker, address it, and unblock the task. The writer picks up where it left off.

bashVerified
$ hermes kanban list

  #1  keyword-research    [complete]  research-specialist
  #2  serp-analysis       [complete]  serp-analyst
  #3  content-writing     [complete]  content-writer
  #4  draft-review        [in_progress]  seo-manager

$ hermes kanban show 4

  Task #4: Draft Review
  Assignee: seo-manager
  Status: in_progress
  Comments: (none yet)
  Heartbeat: 12s ago

The kanban CLI lets you check the board status, see which tasks are in progress, and inspect comments from agents. You do not need to monitor constantly — the dispatcher handles the coordination. But you can check in at any point.

When to use subagents

Subagents for parallel one-off work

The four profiles handle the recurring weekly cycle. But sometimes you need work that does not fit the cycle — a one-off fact check, a parallel search for two different topics at once, or a quick verification that a published article is still ranking. These are subagent tasks.

For example: the research specialist needs to research two different topic clusters at the same time. Instead of running them sequentially (which takes twice as long), the specialist can spawn two subagents in parallel — each with its own isolated context, each searching for a different topic, each returning results independently. The specialist collects both sets of results and merges them into a single keyword file.

Another example: you ask the SEO manager to verify three existing articles against current SERP data. The manager spawns a subagent for each article. Each subagent searches for the article's target keyword, checks the top results, and returns a brief status report. The manager reviews the three reports and decides which articles need updating.

Subagents are not part of the kanban flow. They are synchronous — the parent profile waits for the result before continuing. They do not get their own kanban tasks, because they are not independent workers on the board. They are extensions of the parent: extra hands for a single job, gone when the job is done.

Practical safeguards

Keeping agents from stepping on each other

Even with kanban coordinating task assignment, you still need file conventions that prevent conflicts. Here are three practical rules for your SEO team:

Rule 1 — Separate output files per role

Each profile writes to its own file. The research specialist writes to keywords.md. The SERP analyst writes to serp-analysis.md. The content writer writes to draft.md. The SEO manager reads all files but writes only review notes to review.md. No two profiles write to the same file.

Rule 2 — Read-only for upstream data

The SERP analyst reads keywords.md but never modifies it. The content writer reads both keywords.md and serp-analysis.md but never modifies either. Each profile treats upstream files as read-only inputs. This prevents a downstream agent from accidentally changing the data an upstream agent produced.

Rule 3 — Kanban gates the read

A profile does not read the upstream file until the kanban board says the upstream task is complete. The SERP analyst does not try to read keywords.md while the research specialist is still writing to it. The board ensures sequential access — not through file locks, but through task status.

These three rules — separate output files, read-only upstream data, kanban-gated reads — are sufficient for most multi-agent workflows. You do not need file locking or database transactions. The coordination comes from the kanban board, and the file conventions make conflicts structurally impossible rather than merely unlikely.

Takeaway

Designing for scale without losing control

Expanding from two agents to four (or more) changes the problem from "how do I make each agent sharp?" to "how do I make the team work together?" The answer is a combination of the patterns you have already learned:

Profiles for durable roles

Every recurring role gets its own profile — its own memory, skills, and toolsets. The research specialist, SERP analyst, content writer, and SEO manager are all profiles because they all repeat weekly and all accumulate expertise.

Skills with output contracts

Each profile's skill defines what it produces and in what format. The output contract makes handoffs clean: the SERP analyst knows exactly what the research specialist will return, and the writer knows exactly what the SERP analyst will return. No ambiguity, no parsing errors.

Kanban for coordination

The board tracks task status, prevents concurrent access to the same work, and recovers from stalled agents automatically. You do not need to manually assign tasks or check whether an agent is still working — the dispatcher handles it.

Subagents for one-off parallel work

When a profile needs to run two searches at once or verify three articles in parallel, subagents provide the extra throughput without creating new profiles. They start clean, finish fast, and disappear.

File conventions as a safety net

Separate output files, read-only upstream data, and kanban-gated reads make file conflicts impossible by design. The board coordinates task access; the file conventions coordinate data access.

The model inside each profile is the same engine. The profiles, skills, and toolsets make each agent sharp at its own job. The kanban board and file conventions make the team work together without collisions. And the SEO manager — holding your judgment — sits at the top of the chain, reviewing every draft before it goes anywhere.

You need to add a weekly performance review to your SEO team: an agent that checks whether your published articles are ranking for their target keywords and reports any drops. Should this be a new profile on the kanban board, or a subagent spawned by the SEO manager? Why?