One Goal, Many Hands

Part 1 left us with a clean foundation: one agent, one human, one shared coordination surface, all reachable from any browser. The foundation is enough to be useful. It is not yet what we mean by a swarm.

A swarm is what happens when you point multiple agents at the same problem and let them divide the work. Not “agent council with consensus voting” — that is part 4. Plain, useful, immediate parallelism: a goal you would otherwise hand to one agent for an afternoon, given instead to five agents for forty minutes. Most software-engineering tasks decompose this way. Test suites have N failing tests. Codebases have N functions to migrate. Bug backlogs have N tickets. Refactors have N call sites. The natural unit of work is plural.

This part of the series is about the topology that makes plural parallelism actually work — without the operator drowning in noise, without the agents stepping on each other’s commits, and without the swarm losing the thread of the goal halfway through.

The Topology, Plural

Add agents to the picture, and the substrate barely changes — but the shape of what flows through it changes a lot.

                  ┌─────────────────────────────────────────┐
                  │              YOUR CLOUD                 │
                  │                                         │
                  │              ┌─────────┐                │
                  │              │   Hub   │                │
                  │              └────┬────┘                │
                  │                   │                     │
                  │   ┌───────────────┼───────────────┐     │
                  │   ▼               ▼               ▼     │
                  │ ┌────┐  ┌────┐  ┌────┐  ┌────┐  ┌────┐  │
                  │ │ A₁ │  │ A₂ │  │ A₃ │  │ A₄ │  │ A₅ │  │
                  │ └─┬──┘  └─┬──┘  └─┬──┘  └─┬──┘  └─┬──┘  │
                  │   │       │       │       │       │     │
                  │   └───────┴───────┼───────┴───────┘     │
                  │                   ▼                     │
                  │           ┌──────────────┐              │
                  │           │  Scuttlebot  │              │
                  │           │  #goal-room  │              │
                  │           │  #agent-1..5 │              │
                  │           └──────────────┘              │
                  │                                         │
                  └─────────────────────────────────────────┘

Each agent (A₁ through A₅) is a clone of the part-1 agent: same image, same bootstrap, same runtime. The only thing that changes per agent is which slice of the work they own. Each one has its own scuttlebot channel for chatter; there is one shared channel — #goal-room — that they all listen to.

That shared channel is the coordination spine of the swarm. Everything that affects multiple agents — work allocation, status, blocking issues, the goal itself — flows through it. Per-agent channels are for noise (logs, decisions, dead-ends). The shared channel is signal.

Three Coordination Patterns

There are exactly three patterns that work in practice. Each fits a different shape of problem.

Pattern A — Static Split

The simplest pattern: divide the work before the swarm starts. Agent 1 gets directory X. Agent 2 gets directory Y. Each agent runs independently, reports to its own channel, posts a “done” message to #goal-room when finished. No agent talks to another mid-flight. The operator merges results at the end.

   ┌──────┐   ┌──────┐   ┌──────┐
   │  A₁  │   │  A₂  │   │  A₃  │
   │ dir/X│   │ dir/Y│   │ dir/Z│
   └──┬───┘   └──┬───┘   └──┬───┘
      │          │          │
      └──────────┼──────────┘
                 ▼
           #goal-room
        (final reports only)

When it works: the problem cleanly partitions. Migrate 200 files in 4 directories: split the directories, four agents, done in a fraction of the wall-clock.

When it fails: anything where one agent’s work depends on another’s. Cross-cutting refactors. Shared schemas. Anything that touches files in more than one of the static partitions.

Pattern B — Work-Stealing Queue

A queue of tasks (failing tests, tickets, call sites). Each agent reads #goal-room, claims the next available task by posting claiming task-N, works on it, reports back, claims the next. Agents do not coordinate with each other directly — they coordinate through the queue.

                   ┌────────────────────┐
                   │     #goal-room     │
                   │  task-7 unclaimed  │
                   │  task-8 unclaimed  │
                   │  task-9 unclaimed  │
                   └──────┬─────────────┘
                          │
            ┌─────────────┼─────────────┐
            ▼             ▼             ▼
         ┌────┐         ┌────┐        ┌────┐
         │ A₁ │claim 7  │ A₂ │claim 8 │ A₃ │claim 9
         └────┘         └────┘        └────┘

When it works: lots of small, similar, independent tasks. Fix N failing tests. Resolve N type errors. Update N deprecated API calls. Agents that finish fast take more tasks; agents that get stuck on a hard task do not block the others.

When it fails: tasks with hidden dependencies. Two agents claim two tests that fight over the same global state. Two agents claim two tickets that need the same migration applied first. Pattern B does not see those — the operator has to.

Pattern C — Leader-Followers

One agent is the leader. It plans, decomposes the goal, posts sub-tasks. The followers each take one sub-task, work, post results. The leader reviews, integrates, and either declares the goal complete or posts a new round of sub-tasks. This is the closest of the three patterns to “agent council” and the most expensive in coordination cost — but the only one that handles deeply interdependent work.

                  ┌──────┐
                  │ A₁   │  Leader: plans, decomposes,
                  │      │  reviews, integrates
                  └──┬───┘
                     │
           ┌─────────┼─────────┬─────────┐
           ▼         ▼         ▼         ▼
        ┌────┐    ┌────┐    ┌────┐    ┌────┐
        │ A₂ │    │ A₃ │    │ A₄ │    │ A₅ │
        │ sub│    │ sub│    │ sub│    │ sub│
        └────┘    └────┘    └────┘    └────┘

When it works: a complex refactor that needs a coherent plan first. A multi-step migration where step 3 needs step 2 to land. A feature add that touches three subsystems.

When it fails: when the goal is so big that the leader can not hold the whole thing in context. At that point, escalate to a multi-level hierarchy (part 4) or fall back to splitting the goal in half manually.

The Operator Cost Curve

Done well, a fleet should be approximately as easy to operate as a single agent. The visual:

            operator
            attention
                 │
                 │    ╱──── bad (linear)
                 │   ╱
                 │  ╱
                 │ ╱
                 │╱_____ good (flat-ish)
                 │
                 └─────────────────── fleet size
                  1   2   4   8   16

If your operator attention rises linearly with fleet size, you have built a coordination problem, not a swarm. The fix is almost always less noise in the shared channel. The shared channel should carry only:

• Task claims and releases.
• Status transitions (a task moved from “in progress” to “done” or “blocked”).
• Decisions that affect more than one agent.
• The final report when an agent finishes.

Everything else — model calls, tool invocations, intermediate reasoning, dead-ends, retries — belongs in the agent’s own channel. The operator can drill into it when something looks off. They should not be reading it ambiently.

The Conflict Problem

Multiple agents working on the same codebase will eventually try to write to the same file. There are three reasonable strategies:

   Strategy 1 — Per-agent worktree:
       ┌────────┐    ┌──────────────┐    ┌────────────┐
       │ A₁     │───▶│ branch/A₁    │───▶│ merge-bot  │
       │ A₂     │───▶│ branch/A₂    │───▶│            │
       │ A₃     │───▶│ branch/A₃    │───▶│            │
       └────────┘    └──────────────┘    └────────────┘
                  each agent has its own branch;
                  a merge step consolidates at the end.

   Strategy 2 — File ownership map:
       Pattern A's variant. Agent N can only touch files in
       its allocated set. Conflicts impossible by construction.

   Strategy 3 — Optimistic with rebase:
       All agents work on the same branch. When two commits
       collide, the latter rebases and retries. Works only
       if the work is genuinely independent at the line level.

For coding-agent swarms in 2026, Strategy 1 (per-agent worktree) is the default we recommend. Every modern git platform handles per-branch isolation. The merge step is itself an opportunity to apply the swarm’s policies — run the test suite, run the policy simulator, gate on approval — before anything lands on main.

Where the Cost Goes

Running a five-agent fleet against a single problem is roughly 5× the API cost of one agent, minus the redundant work an agent would have done sequentially, plus some coordination overhead. For most coding problems that decompose well, the wall-clock saving is 3–4× even though the cost multiplier is 5×. Whether that trade is worth it is a function of:

• How urgent the goal is (a critical hotfix is worth 5× cost for 4× speedup).
• How expensive a developer’s time is (almost always more expensive than 5× model calls).
• Whether the model provider has burstable rate limits (Anthropic, OpenAI, and Bedrock all do, in 2026).

The cost lives in the same place all your other agent costs live — the governance and observability layer (Zentinelle or your equivalent). Per-agent cost, per-team cost, per-task cost, live, in motion.

The Pattern, Repeated

Once one fleet exists, a second fleet is mechanically the same setup. Different shared channel, different scope, different agents. The operator surface stays the same. The mental model stays the same.

That is the bridge to part 3: many fleets, many problems, one operator view. A single pane of glass where one human watches dozens of swarms across dozens of repos, drilling into any of them when something interesting happens, otherwise letting them work.

Where to Go Next

The repos and docs for this part of the journey:

• calliope-agents — agent images and bootstrap. The relay process is what makes parallel agents addressable from one scuttlebot.

• calliope-scuttlebot — channel model, persistence, web UI. The #goal-room and per-agent-channel pattern is the convention; nothing in scuttlebot enforces it, you adopt it by configuration.

• junohub — how the hub spawns N agents from one template, with per-spawn identity and isolated worktrees.

• docs.calliope.ai — current guides on fleet patterns, worktree strategies, and merge workflows.

Next in this series — Part 3: Many Problems, One Pane. Running multiple fleets in parallel against unrelated goals, and the operator surface that makes them all watchable from one place.