Multi-agent systems are not automatically deeper.

Most of the time they are just more places for the same confusion to hide. Two agents that share a flawed premise will produce twice as much flawed output, and now you have a board meeting where you used to have a bug. Three of them will write a charter.

The earlier posts in this series built up a single-agent loop with tools, project context, filesystem state, verification, and hooks. This one is about the moment that loop branches — and the much more common moment when it shouldn't.

Two cloned investigation branches compare a minimal patch and tokenizer refactor, then converge on evidence-based decision criteria.

When branching earns its keep

There's a specific shape of decision where two parallel investigations beat one sequential one: when the evidence to pick between approaches is cheap to gather and expensive to gather sequentially.

The tiny-ledger example I keep using: you're considering two approaches to handling split tax lines. One is a minimal patch — extend the existing regex, add a couple of conditionals. The other is a small grammar refactor — pull out a tiny tokenizer that makes future cases easier. Both could work. Both will look defensible in prose. The thing that decides between them is what the actual diff looks like — file count, test clarity, special-case footprint.

Sequentially: explore option A, get attached to it, find a wart, half-heartedly explore option B, end up picking A because you've already invested in it. Classic anchoring.

In parallel:

/fork
Investigate the smallest patch for supporting split tax lines. Do not edit yet. Return evidence and a proposed diff shape.

/clone
Explore whether a tiny tokenizer would make this less fragile. Keep it under 60 lines or reject the idea.

Now you have two diffs, two test plans, two estimated footprints. The decision becomes evidence vs evidence instead of "which one did I write first."

That's the primitive worth keeping: branching preserves competing hypotheses long enough that the evidence picks the winner instead of the order of operations.

Session branching as the useful primitive

Pi has two relevant moves here:

  • /fork — branch the current session into a side investigation. Same starting context.
  • /clone — like /fork, but with a separate working directory or worktree, so the branches can't step on each other's files.

For the parallel investigation case, /clone is usually the one you want. Each branch can edit files freely without contaminating the other. When you merge — meaning, when you decide — you pick one branch's diff and let the other one go.

The decision checklist that works for me:

  • Which branch touched fewer files?
  • Which branch made the test easier to understand?
  • Which branch reduced special cases instead of hiding them?
  • Which branch can be reverted cleanly?

Those four questions usually pick the winner without a third meeting. If they tie, the work probably wasn't worth branching for.

When subagents are process cosplay

A surprising amount of multi-agent framing is just turning a single decision into a committee. The shape: one orchestrator agent assigns a "planner agent," "implementer agent," "reviewer agent," and "critic agent" to the same task. Each one writes prose. None of them produce more evidence than a single agent reading the same files would.

The tell: every "agent" in the system is reading the same context and producing more text. No new tools, no new files, no new tests, no new disagreement that resolves. The diagram looks like collaboration. The output is a longer monologue.

Real subagent value comes from one of three things:

  1. Disagreement that resolves into evidence. Two agents propose different patches; the verifier runs both tests; the winner is picked by npm test, not by vibes.
  2. Parallelism that saves wall time. One agent investigates the database migration while another writes the corresponding API change. They merge once both are ready.
  3. Asymmetric trust. A bounded, sandboxed agent does the risky thing (proposes a refactor, runs a destructive script in a clone); a more trusted agent reviews the diff.

If your multi-agent setup isn't doing one of those three, you've just added latency and tokens to a single-agent workflow.

Avoid the meeting

The temptation when subagents exist is to use them for everything. Don't. Each fork has costs:

  • Context split — you now have two sessions to keep in your head.
  • Merge decision — somebody has to pick the winner, and that somebody is usually you.
  • Token spend — two investigations cost ~2x what one would.
  • False sense of rigor — "we considered both approaches" sounds responsible even when neither investigation was deep.

The single-session version is fine for most work. Branch when the evidence to choose between approaches is genuinely cheap. Don't branch because the workflow diagram has room for a second box.

Branching for review, not for invention

One specific case that does keep earning its keep: forking a session to review what the main session just did. The main agent edits, runs tests, claims done. A forked agent — clean context, just the diff and the tests — reviews the change as if it had no prior commitment to the approach. This is a cheap second opinion that catches things the main agent rationalized past.

This connects to the orchestrator projections argument from my memory series. The reviewer wants a different projection than the implementer. Forking with a narrower context window is one way to enforce that boundary.

Exercise

For tiny-ledger:

  1. Pick a small open task. Run it in a single session. Note the time and the token spend.
  2. Run the same task with /fork into two competing approaches. Apply the decision checklist; pick a winner.
  3. Compare the diffs and the test changes. Was the forked version meaningfully better, or did you spend 2x for 1.1x quality?

The honest answer for most everyday tasks is "the single session was fine." Save the fork for the cases where the evidence won't be obvious from one approach alone.

Next primitive

The next post is about the unglamorous half of the harness: sessions, compaction, and getting the agent back on track after it gets lost. The harness's most important property is whether you can recover after the model wanders, and recovery is where the black-box recording starts paying off.