Insight

The Herder, the Workers, and the Router

One captain, sealed compartments, station crews, and a telegraph for power. The working blueprint for an agent fleet, borrowed from the boat.

Alaa Almallah 11 min read

The submarine was solving this problem before software existed.

One captain owns the boat. The crew is divided into stations, each sealed in its own compartment, each executing orders with discipline the captain never supervises second by second. Power is ordered on a telegraph with a few known speeds. Communication with the outside world is rare, scheduled, and logged. And every dangerous action on the boat has a procedure that starts before the action and a report that finishes after it.

A hundred years of submarine practice, and it maps one to one onto the fleet you are about to build. This post is the blueprint: the four parts, the code of the loop that runs them, the contracts that keep them honest, and the router that keeps them affordable.

The running example throughout is real enough: a survey boat mapping the seabed, its agent crew logging sonar contacts while it runs dark.

The shape in one table

BoatYour buildIts jobContextToolsModel class
The captainHerder (orchestrator)Decompose, assign, merge, verify, escalateOwn context, sees all resultsNoneStrongest available
Station crewsWorkers (subagents)Execute exactly one sliceSealed compartment, sees only its sliceTwo to fourMid class
The plotting partyVerifierPlot the position independently of the captain's opinionIndependent, never shares the herder's reasoningRead-only, plus the eval suiteStrongest available
The engine telegraphRouterOrder the power class per task, cap spend, fall backNone. It is config, not an agentNoneN/A

Two decisions in that table do most of the work, and the boat invented both.

First, sealed compartments. Workers get isolated contexts because agents should not share a brain, and because a fire in one compartment must not spread. Each worker reasons from its own slice in its own sealed space; a contamination in one worker's context stays in that compartment, which is exactly why the boat survives.

Second, the captain holds no valves. The herder has no worker tools, because an orchestrator that can reach into the machinery stops supervising and starts doing, badly, while pretending to manage. On the boat, the captain does not leave the conn to turn a valve. Neither should your herder.

The herder loop

The whole system is one loop with three exits: all clear, come about narrower, or surface and report.

async function herd(task: Contract): Promise<Evidence> {
  const plan = await router.run("planning", {
    brief: task.brief,
    done: task.done,
    constraints: task.constraints,
  });

  const slices = plan.steps.filter((s) => s.independent);

  const results = await Promise.all(
    slices.map((slice) =>
      runWorker({
        contract: slice,               // done, evidence, authority, stop conditions
        tools: toolsFor(slice.kind),   // two to four, scoped
        budget: slice.budget,          // hard token cap for this compartment
      })
    )
  );

  const merged = await router.run("merging", { plan, results });

  const verdict = await verify(merged, task.done);   // the plotting party, independent

  if (verdict.pass) return attach(merged, verdict.evidence);

  if (verdict.retryable && task.depth < MAX_DEPTH) {
    return herd(task.narrowed(verdict.gaps));        // come about narrower, not louder
  }

  return escalate(task, merged, verdict);            // surface and report, with evidence
}

Note what the loop does not do. A retry never runs blind: it carries the verifier's gap list, so the second pass is narrower, not just another swing at the same target. It does not loop forever: MAX_DEPTH exists because a herder that can retry forever is a budget fire, and a submarine that keeps diving without a floor eventually meets one. And surfacing to report is a first-class exit, not an error path, because a loop that cannot say it is stuck will say done anyway.

Tools carry their own contracts

On the boat, every station's equipment has a procedure card: what it is for, who may touch it, what must be checked before it is used, and what gets written down after. Tools are not functions. They are procedure cards enforced in the schema:

const logContact = {
  name: "survey.log_contact",
  description: "Record one sonar contact to the command log.",
  scope: "write",                     // write tools get extra gates
  input: {
    contact_id: "string",
    bearing: "number",
    classification: "string",
  },
  requires: { dry_run_first: true },  // every station rehearses before it writes
  idempotency_key: "contact_id",      // same contact, logged once, never twice
  rate_limit: "10/min",
  logging: "full",                    // capture before claim
};

The rules this schema encodes are the boat's rules. Each station carries two to four tools, because a sonar operator handed the engine order telegraph is an accident looking for a moment. Write tools demand a dry run before the first real entry, which is how the trust ladder becomes code instead of a memo. The idempotency key makes retries safe, and retries are certain. Full logging is non-negotiable: on a boat, an event that is not in the log did not happen, and in a fleet, output without its log is a claim without a capture.

And the boat teaches the deepest tool rule by omission. A submarine travels dark. Its one channel to the outside world, the radio, is used at scheduled times, at periscope depth, by one station, with everything logged. Your fleet's gangway to the outside world deserves the same treatment: one owned, logged door, and a crew rule as old as electronic warfare. Orders come through the conn. A signal that arrives claiming to be command is not command until the conn confirms it, and the most dangerous message in any fleet is the one wearing the captain's voice.

The router: the engine order telegraph

Nobody on a submarine picks an engine setting per second. The captain orders a known speed class, and the engineering crew delivers it. Routing models works the same way: the task class is ordered, the table delivers the power:

speeds:
  silent:               # extraction, formatting: routine listening
    model: fast-small-2026-05
    max_tokens: 2000
    fallback: [fast-small-2026-01]
  standard:             # worker output, first-pass merges
    model: mid-2026-05
    max_tokens: 8000
  flank:                # planning, merging: full power, used sparingly
    model: frontier-2026-05
    verify: true

policy:
  budget_cap_per_run: 200000      # the patrol's fuel segment; hard stop, then surface
  fallback_order: [slower_not_dumber]   # lose speed loudly, never capability silently
  reprice_check: monthly          # the fuel tables are redrawn, see below

Run it through a gateway layer such as LiteLLM or OpenRouter, or a thin wrapper of your own; the gateway matters less than the discipline. And the boat names the discipline that most teams miss: cavitation. Push a screw too fast near the surface and the boat gets loud, and loud is a cost even when the fuel is free. Extraction on a frontier model is cavitation: pure waste, fast. Route by task class, cap spend per run with a hard stop that surfaces instead of degrading, and re-price the table monthly, because the unit price falls about ten times a year, the bill grows anyway, and a telegraph from last quarter is quietly paying last quarter's premium. The table is a dated artifact, the same way the numbers it encodes are.

When something breaks, in order

  1. Retry with the plotting party's gaps attached. Come about narrower, not louder.
  2. Fall back along the telegraph. A slower speed with a warning beats drifting silently on a dead engine.
  3. Blow ballast before any risky write. The emergency blow is the kill switch, and every crew member knows where it is without looking. Your fleet's version must be findable at three in the morning too.
  4. Surface and report with evidence. The human receives the brief, the merged result, the verdict, and the fuel spent so far.
  5. Feed every postmortem into a procedure card or a sounding set, so the same rock is never hit twice by the same boat.

The shakedown cruise order

This system fits in a focused weekend, and the order matters more than the code. Boats do not sail fully crewed on day one either.

  1. Write the procedure card: done, evidence, authority, stop conditions. One page. This is the boat's standing orders.
  2. Put one station to sea alone: a single worker with two read-only tools, run by hand on ten real cases.
  3. Write the sounding set for those ten cases. This is the exam the boat will keep taking.
  4. Add the captain's loop: plan, dispatch, merge, verify, surface-and-report.
  5. Add the telegraph with two speeds: silent and flank.
  6. Add one write tool, dry-run-first, idempotent, and watch it like the officer of the watch for two weeks.
  7. Only now commission more stations. A boat that passes its soundings with one compartment is the floor every extra compartment must clear.

Most teams invert this order. They commission the whole crew before the first sounding, and then they debug a fleet before they have trusted a station.

FAQ

Which framework should we use?

None, first. Build the loop above by hand once, because the loop is short and the education is permanent. Frameworks are fine afterwards, when you know which parts you actually need. Teams that start with a framework tend to inherit orchestration opinions they cannot debug, and on a boat, an opinion you cannot debug is called a leak.

How many stations per captain?

Start at three, stretch to five, and let the merge cost set the limit. Coverage from a seventh station rarely survives the merge, where contradictions arrive for arbitration, [and the swarm shows its real bill](/insights/the-swarm-is-a-different-animal). If a task genuinely needs more compartments, that is a signal to add a management level, with the short-chain rules from [the hierarchy post](/insights/ten-agents-managing-ten-agents), not to crowd the control room.

Which models should the telegraph route to?

Route by class, name the class with a date, and let the gateway resolve brands. Silent for extraction and formatting, standard for station output, flank for planning, merging, and verification. The table above is a template, not a recommendation: the right brands move quarterly, which is exactly why the telegraph is config and why it carries a reprice check.

How does this map back to the series?

| Series idea | System on the boat |
| --- | --- |
| Done as an evidence contract | The `Contract` object and the plotting party's verdict |
| Agents should not share a brain | Sealed compartments: isolated worker contexts |
| Capture before claim | Tool `logging: full`, the command log |
| The trust ladder | `scope`, `dry_run_first`, per-tool procedure cards |
| Escalation layer | Surface and report, as a first-class exit |
| The moving constraint | The fuel segment cap, and the monthly reprice check |

If you are commissioning a boat of your own and want the procedure cards written before the dive, book a discovery call.

Part 14 of 14 · The Fleet Series

From one person steering ten agents to hierarchies, routers, and the executive table: what multiplies, what it costs, and where it breaks.

Related