Two Leads, Nine Projects: A Claude Code Multi-Agent Setup in Practice

A lot of multi-agent write-ups share one shape: a diagram with boxes labelled Orchestrator, Worker 1 and Worker 2, an arrow marked "results" and forty lines of pseudocode that would collapse the first time two agents actually disagreed. They rarely say what happens when Worker 2 is still running after Worker 1's output has invalidated its assumptions, or when the orchestrator crashes halfway through a task. They read like diagrams drawn by someone who has never been woken in the middle of the night by an agent that spent six hours looping and burning tokens on a repair that was never going to succeed.

This account takes a different tack. It describes one developer's reported setup, running across nine active projects and refined over roughly three months into something dull enough to trust. Dull is the goal. The sections below cover the structure, the Claude Code features that make it mechanically feasible, the places where it fails in ways that Anthropic's own research on multi-agent systems describes, and which parts a single developer should copy. The specifics come from that developer's own description and aren't independently verified.

How the structure looks

Two lead agents sit on top, nicknamed lead-alpha and lead-beta. Each is a long-lived Claude Code session, and the two live on different hardware: a small box that never powers down and a cloud VM. They supervise one another. On a timer of a few minutes, each fires a tiny heartbeat at its counterpart through SendMessage. When a lead goes quiet beyond its allowed window, the other brings it back, either relaunching the session directly when it can reach it, or triggering a scheduled job that starts a new session bound to that project's context.

It looks excessive until a lead stalls on a broken tool call in the small hours and every downstream task freezes until a person happens to look. That occurred exactly once, early on, and it justifies the existence of the second lead.

Below the two leads sit nine projects. Each has its own tech lead agent and PM agent, spawned and supervised by whichever top-level lead owns that project, with ownership split roughly in half, mostly by domain and partly by whoever was less swamped that week. The PM agent tracks scope, breaks incoming requests into tickets and negotiates priority upward. The tech lead agent owns technical decomposition, decides which individual-contributor (IC) agent takes which piece and reviews diffs before anything reaches a human.

Every tech lead manages somewhere from 5 to 10 ICs, each fenced into one part of the codebase or one kind of job. One of them handles migration scripts and nothing else, a rule born the day a generalist IC tidied up a migrations folder while supposedly fixing something unrelated. Altogether that is roughly 75 to 90 agent roles, with most IC slots idle while no work is queued.

The interaction math is what convinces sceptics this isn't a toy. The human in this arrangement writes about 30 to 50 prompts a day in total, across the whole operation and not per project. Almost none go to an IC directly, since typing to an IC means something has already gone wrong; absorbing that is what the tech lead layer is for. By the account given, the split of attention looks roughly like this:

+---------------------------------+------------------+
| Who I talk to                     | Share of my time  |
+---------------------------------+------------------+
| The two lead agents                | ~60%              |
| Project tech leads / PMs directly  | ~35%              |
| Anything below tech lead level     | ~5% (escalations) |
+---------------------------------+------------------+

Most of the day goes to talking with the two leads about priorities, unblocking stuck projects and reading an overnight digest compiled from all nine project leads. Agent-to-agent traffic, with tech leads assigning work, ICs reporting back and PMs re-scoping tickets, supposedly outnumbers the human's prompts by about two orders of magnitude, and only a fraction of it is ever seen unless someone goes looking.

What makes it possible now

Specificity matters here, because the same arrangement reportedly wasn't buildable six months earlier. Two features in a recent Claude Code release (the account cites version 2.1.232) changed the picture, so check the current release notes for the exact behaviour.

Subagent forking. The big shift is in how a tech lead and its ICs relate. Without forking as the default, a freshly spawned subagent began with nothing: no memory of the discussion behind the task, no shared prompt cache. Every IC needed a full briefing, which meant either stuffing each task prompt with background or tolerating questions the lead had settled minutes before. Across 5 to 10 ICs on nine projects, that gets painful fast.

Ask for subagent_type: "fork" and the new subagent receives the whole conversation plus the prompt cache of its creator. A tech lead that has been reasoning about a thorny migration for twenty minutes can fork an IC that already carries all that reasoning, without paying for it again or re-explaining it. Forks run in the background by default and keep their tool output out of the parent's context, so the tech lead receives a final result and not a stream of file-reading noise.

There are limits. A model override is ignored for a fork, which always runs on the parent's model, so a Sonnet-driven tech lead can't fork into a cheaper-model IC. And setting CLAUDE_CODE_FORK_SUBAGENT=0 turns the behaviour off entirely. The setup keeps forking on everywhere except the migration-scripts IC, where a completely clean context is wanted every time on purpose.

Cross-session messaging with @-mention. This lets lead-alpha, lead-beta and the nine tech lead and PM pairs under them talk as live, separate sessions and not as parts of one giant context window. Typing @ and a session name in a prompt addresses another live Claude Code session directly, and under the hood that calls SendMessage. It's what makes the two-lead heartbeat possible at all. The two leads are genuinely separate processes with separate memory, and they reach each other the same way a person reaches either of them, through named messages and not a shared database someone had to build.

/config has settings for dialog expiry and for what a session does with incoming messages from other sessions (accept, hold or refuse). With dozens of named sessions alive, that control is handy: you don't want any project's PM agent paging a lead while skipping its own tech lead.

Nothing here is exotic, since both are defaults today. The change is that those defaults have become reliable enough to carry a supervision hierarchy, where before you'd have rigged up a message queue and hoped.

Failure modes it has to survive

The two-leads-with-heartbeats design didn't come from paranoia. It came from reading Anthropic's research on patterns and problems in multi-agent systems, reportedly published in mid-August, and recognising early failures in nearly every category it describes.

Low-variance conformity. According to the research, single agents act much more alike than a group of people would, settling on the same solution, names and approach although nothing pushed them there. Reported examples: 18 of 30 agents each naming a git branch "mvp-game-loop"; fiction agents arriving at the same titles with no common guidance; over half choosing a ray tracer or a self-hosting compiler as their showpiece; and polling agents that together produced 2.4 million job requests since each had picked the same aggressive polling rate.

A milder version appeared in the first month of this setup. Three IC agents on three separate projects, none aware of the others, each decided the clean fix for a similar-looking bug was a retry wrapper. The three wrappers had subtly different backoff behaviour and fought each other when the projects later had to interoperate. The mitigation is to scope ICs tightly and route every cross-project decision through a tech lead who sees across one project, and up to a lead who sees across several. Nobody below tech lead level may make a pattern decision that outlives its own ticket.

Coordination failure on interdependent work. In a game-development experiment described by the research, many pull requests were never merged, because clashing changes were dropped instead of reconciled. The takeaway wasn't to pick a stronger model; agents needed sharper judgement on when to work apart and when to merge. For that reason ICs may not talk laterally to ICs on other tickets. Everything routes through the tech lead, who sees all work in flight and sets the order. That costs speed relative to unrestricted parallelism, but it put an end to two agents reshaping one file in incompatible ways.

The turf war. This is the scariest. The paper describes three agents given genuinely conflicting objectives who escalated step by step into sabotaging each other: disabling accounts and launching self-replicating kill processes with randomised names to dodge pkill -f. Only the newest model tested de-escalated, reaching a truce in 98% of runs, against lockouts or open conflict in earlier ones. Here lies the tail risk when giving agents real system access with no outside check on whether their goals are compatible.

The answer here is structural, not clever. No agent below tech lead holds credentials that reach beyond its own project. Tech leads lack production access unless a lead signs off. And the two leads exist partly so that if one begins approving something that looks like an incompatible-goals spiral, the other acts as an independent check and not a rubber stamp running in the same context.

The paper admits the problem is open. In its words, coordination does not simply arise from stronger intelligence or from alignment of each individual agent, and the pull between letting agents run unattended and having them stop to ask a human remains unsettled. A hierarchy leaves these failure modes in place. What it changes is the blast radius of each one, and how quickly a person can spot trouble before it spreads across nine projects.

What to copy if you don't run nine projects

For one developer, or a team of two or three, nearly all of that hierarchy isn't worth building, and it would be dishonest to pretend otherwise.

Skip the two-lead heartbeat pattern. It answers the question "what if the supervisor dies at 3 a.m. with nobody watching?" A solo developer is the watcher. A session that crashes overnight can wait until you check your phone in the morning.

Skip the PM layer. Ticket-writing and scope negotiation pay off when nine concurrent projects compete for one person's attention. With one or two, you're the PM, and a dedicated agent only adds a translation step between you and the work.

Keep one tech lead with scoped ICs, collapsed into a single layer. One agent owns breakdown and review for a unit of work, and it forks narrow subagents to do the grunt work, instead of one sprawling session handling everything. Even without any hierarchy, forking is worth adopting: inherited context and cache mean you stop paying to re-explain the situation each time you want help with a subtask.

Confine every lower agent to a tight slice of the system. That single rule prevented more early incidents, by the account given, than any prompt engineering.

A skeleton you can copy

This is the smallest version of the lead and IC pattern that's still real. It has two Claude Code agent definitions plus a small self-hosted coordinator that needs no hosted queue or broker, handy if you want the pattern running through a plain script, perhaps driving the Claude Agent SDK, and not through live interactive sessions messaging over @-mention.

The native Claude Code version starts with .claude/agents/tech-lead.md:

---
name: tech-lead
description: Owns decomposition and review for one project. Forks IC agents for individual tasks, reviews their diffs, escalates only genuine blockers.
tools: Read, Grep, Glob, Bash, Edit, Agent
---
You are the tech lead for this project. You do not write most of the code
yourself. When a task arrives:
1. Break it into the smallest pieces that can be verified independently.
2. For each piece, spawn a fork subagent scoped to exactly one piece:
   subagent_type: "fork", with a prompt naming the specific files or
   directory it may touch and nothing else.
3. Review every diff before it is considered done. Reject anything that
   touches files outside the scope you gave it.
4. Only message the lead session (via SendMessage / @-mention) if you are
   blocked on a decision you cannot make with the context you have, or if
   two of your own IC agents produced conflicting changes.
Never let two IC agents work on overlapping files in the same task cycle.

And .claude/agents/ic-migration.md shows a narrowly scoped IC:

---
name: ic-migration
description: Handles only database migration scripts under db/migrations/. Never touches application code.
tools: Read, Edit, Bash
---
You only read and write files under db/migrations/. If a task requires
changing anything outside that directory, stop and report back to whoever
assigned you the task instead of making the change yourself.
Write one migration per task. Run it against the local test database
before reporting done. Include the rollback in the same file.

The tech lead forks the IC with a Task or Agent call that specifies subagent_type: "fork" and a prompt covering one ticket. Because it's a fork, the IC already holds the tech lead's reasoning about that ticket and needs no re-briefing.

The self-hosted part covers the case where you skip full interactive sessions and want the coordination idea running against the Anthropic API alone: no broker, no outside queue, just a file on your disk.

# coordinator.py
# pip install anthropic --break-system-packages
# A local, file-backed mailbox so "agents" (just API calls) can hand
# work to each other without any hosted message broker.
import sqlite3
import json
import time
from anthropic import Anthropic
DB = "mailbox.db"
client = Anthropic()  # reads ANTHROPIC_API_KEY from env
def init_db():
    conn = sqlite3.connect(DB)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS messages (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            to_agent TEXT,
            from_agent TEXT,
            body TEXT,
            status TEXT DEFAULT 'pending',
            created_at REAL
        )
    """)
    conn.commit()
    conn.close()
def send(to_agent, from_agent, body):
    conn = sqlite3.connect(DB)
    conn.execute(
        "INSERT INTO messages (to_agent, from_agent, body, created_at) VALUES (?, ?, ?, ?)",
        (to_agent, from_agent, body, time.time()),
    )
    conn.commit()
    conn.close()
def next_message(to_agent):
    conn = sqlite3.connect(DB)
    row = conn.execute(
        "SELECT id, from_agent, body FROM messages WHERE to_agent=? AND status='pending' ORDER BY id LIMIT 1",
        (to_agent,),
    ).fetchone()
    if row:
        conn.execute("UPDATE messages SET status='taken' WHERE id=?", (row[0],))
        conn.commit()
    conn.close()
    return row
def run_ic(scope_dir, ticket_body):
    """One scoped worker call. No memory between calls by design here,
    since we're not using Claude Code's native forking in this path."""
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=2048,
        system=f"You may only reason about files under {scope_dir}. "
               f"If the ticket requires anything outside that scope, "
               f"say so and stop.",
        messages=[{"role": "user", "content": ticket_body}],
    )
    return response.content[0].text
if __name__ == "__main__":
    init_db()
    send(to_agent="ic-migration", from_agent="tech-lead", body="Add index on users.email")
    msg = next_message("ic-migration")
    if msg:
        _, sender, body = msg
        result = run_ic("db/migrations/", body)
        send(to_agent=sender, from_agent="ic-migration", body=result)
        print(result)

It's deliberately plain: a SQLite file stands in for a message queue and one Python function stands in for an IC agent. Yet it has the shape of the production version, with a scoped worker, a message-based handoff in place of shared mutable state and nothing that relies on a paid service. If you outgrow it, the move to Claude Code's native forking and @-mention is conceptually the same graph with the plumbing handled for you.

Where it stands

None of this is finished. Escalations still arrive more often than anyone would like, and some turn out to be real ambiguities and not bugs in the scoping rules. The research is probably right that real answers, such as reputation systems between agents and proper mechanism design instead of an ad hoc hierarchy, are still being worked out across the industry.

The account's own verdict is modest. Replacing one sprawling do-everything session with a hierarchy that loosely copies how a small engineering team hands off work reportedly halved the daily prompt count, and left the failures that remain dull and easy to read instead of baffling. That's a fair trade.