The handoff graph · 11 teams wired · 5 start cold · 5 converge

Nobody wrote the run order down.

Ask how this system decides what runs next and the honest answer disappoints anyone hoping for a flowchart. There isn't one. Every team declares exactly two things: what it consumes and what it produces. The conductor reads those eleven declarations and infers a sensible order from them, live, every time it runs. No team owns step two. No team is hardcoded to run after another.

The order isn't written anywhere. It's inferred, every run, from what each team says it needs and what it hands back.

teams.yaml the conductor IDEATION discovery & brief CONSUMES: NULL MARKET research CONSUMES: NULL RAILS ENG engineering CONSUMES: NULL GO ENG engineering CONSUMES: NULL TAURI ENG engineering CONSUMES: NULL A BRIEF: FILE OR TEXT, FROM ANYWHERE DESIGN NOT WIRED TO ONE PRODUCER RAILS QA FROM: RAILS ENG RAILS SECURITY FROM: RAILS ENG COPYWRITING FROM: ANY OF THE THREE TAURI SECURITY FROM: TAURI ENG TAURI QA FROM: TAURI ENG market research has no downstream wiring today. nothing in the graph forces it to feed anything. SAME FILE. FIVE POSSIBLE READERS.

Solid edges are declared consumer relationships. Dashed edges are inferred confirmation, or a source left deliberately open.

11
Teams wired into the graph
5
Start cold, consumes: null
5
Converge on one shared artifact
1
Accepts a brief from anywhere

What this isn't

The model people assume, and the one that's actually running

Most descriptions of a multi-agent system reach for a numbered list, because numbered lists are easy to draw. This system doesn't have one. Here's the model people bring to it, next to the one that's real.

Assumed model

STEP 1 — IDEATION RUNS

STEP 2 — RESEARCH RUNS

STEP 3 — DESIGN RUNS

STEP 4 — ENGINEERING RUNS

STEP 5 — QA, THEN SECURITY, THEN COPY

Actual model

Eleven teams, each with a consumes field and a produces field. Nothing else determines when a team is allowed to run.

Five of them have consumes: null. They start the moment they're called, in any order, at the same time as each other.

Five of them share one consumer relationship: whichever engineering team actually finishes, its matching output unblocks all five at once.

The eleven declarations

What each team says it needs, and what it hands back

This is the entire contract the conductor reads. Not a stage number, not a position in a sequence. Two fields, per team, and the graph falls out of how those fields line up.

Starts cold

Rails Engineering

Consumes

null

Produces

{FEATURE_DIR}/{NNN}-summary.md

Starts cold

Go Engineering

Consumes

null

Produces

{FEATURE_DIR}/{NNN}-summary.md

Starts cold

Tauri Engineering

Consumes

null

Produces

{FEATURE_DIR}/{NNN}-summary.md

Starts cold

Market Research

Consumes

null

Produces

docs/market-research/{NNN}-{product-name}/{NNN}-market-research-summary.md

Starts cold

Ideation & Discovery

Consumes

null

Produces

docs/product-briefs/{NNN}-{product-name}/{NNN}-APPROVED.md

Unconstrained input

Design

Consumes

a brief: file path or raw description, from anywhere

Produces

docs/design-concepts/{NNN}-{concept-name}/{NNN}-summary.md

Converges, family: rails

Rails QA

Consumes

{FEATURE_DIR}/{NNN}-summary.md

Produces

QA synthesis artifact

Converges, family: tauri

Tauri QA

Consumes

{FEATURE_DIR}/{NNN}-summary.md

Produces

QA synthesis artifact

Converges, family: rails

Rails Security

Consumes

{FEATURE_DIR}/{NNN}-summary.md

Produces

Security synthesis artifact

Converges, family: tauri

Tauri Security

Consumes

{FEATURE_DIR}/{NNN}-summary.md

Produces

Security synthesis artifact

Converges, no family

Copywriting

Consumes

{FEATURE_DIR}/{NNN}-summary.md

Produces

{NNN}-copywriting-summary.md

Copywriting doesn't care which stack built the feature. It carries no family value, so it's never a same-job choice the conductor has to resolve.

One real path, traced

Watch the same graph move. This is one path through it, not the only one.

Scroll here and the diagram plays a real session: ideation and market research starting cold, design accepting a brief from nowhere in particular, one engineering team finishing, and three teams reading its output at the same moment instead of standing in a queue.

teams.yaml the conductor IDEATION CONSUMES: NULL MARKET RESEARCH CONSUMES: NULL A BRIEF, FROM ANYWHERE DESIGN NOT WIRED TO ONE SOURCE RAILS ENGINEERING CONSUMES: NULL GO ENG TAURI ENG RAILS QA RAILS SECURITY COPYWRITING

The conductor reads one file, teams.yaml, and nothing else.

Ideation and market research both start cold. Neither one waits on the other.

Design accepts a brief from anywhere. It isn't wired to ideation, even though that's the common path.

Rails Engineering starts cold too, and finishes.

Three teams read {NNN}-summary.md at the same instant. Not a queue. A fan-out.

Copywriting would have taken this file from Go or Tauri Engineering too. It doesn't care which stack built the feature.

Inside each node

Five real shapes run inside these eleven boxes

The graph above is the shape between teams. Inside any one team, the shape is different again, and it's one of exactly five patterns across the whole roster, verified this session across every team that exists.

Shape 1

Parallel panel

No staging, no queue. Every specialist starts the instant the team starts.

Rails/Tauri QA: 6 at once · Market Research: 11 researchers + 1 script, at once

Shape 2

Staged pipeline

brainstorm discovery brief

Each stage waits, because each stage needs exactly what the last one wrote.

Ideation's own internal chain, nested inside shape 5 below

Shape 3

Staged, then parallel, then staged

Some stages wait. Some don't. Both live in the same team.

Copywriting: plan → angle → [landing page + email at once] → humor pass

Shape 4

Gated pipeline, bounded retry

human, after 3x

The most common shape in the whole roster. A real finding sends the engineer back; the same finding surviving three rounds escalates instead of trying a fourth.

All three engineering teams: discovery → architect → design → engineer, gated by quality + security + performance at once

Shape 5

Interactive, with a required human checkpoint

human approve send back reject

No timeout. Three real outcomes, not a yes-or-no. Ideation runs live interview stages, then blocks here completely.

Ideation: full branching checkpoint · Design: a lighter, single-checkpoint version

The learning loop, second tier

One team's log-analyst sees a third of the evidence. This one sees all of it.

The within-team version of this loop is already documented in full on the depth gauge: each team's own log-analyst mines its own accumulated runs, proposes changes, a human approves, skill-builder executes. That's tier one, and it's already closed twice in a real production codebase. Tier two is new this session, and it lives somewhere no single team's log-analyst can reach.

Tier 1 · within-team

Each team's own log-analyst reads its own runs. Real, closed twice, downstream. Full detail on the depth gauge.

Tier 2 · cross-team, new

handoff-analyst lives inside the conductor, the one place every team's log already meets, because the conductor is wired to all eleven.

Why tier 1 can't see it

If QA, security, and copywriting each independently notice the same upstream thinness, each one only holds a third of the evidence, and none of them can fix another team's file anyway.

QA LOGS GAP SECURITY LOGS GAP COPYWRITING LOGS GAP handoff- analyst classifies, then aggregates ONE REPORT organized by producing team not by whoever noticed first human approves each item never auto-edits

handoff-analyst never edits anything. It writes one report, organized by whoever produced the thin artifact, so the fix lands with the team that can actually make it.

How it weighs its own evidence

Every finding gets classified within-team, already covered by that team's own log-analyst, or genuinely cross-team, something only visible by comparing across teams. Cross-team findings get a confidence tier: High when two or more downstream teams corroborate it, or when three or more features from one upstream team show the same gap; Medium at two occurrences; Low means watch it, don't propose anything yet. Same propose-only, human-approval discipline as every other mechanism in this loop, arguably more important here, since the fix lands in a different team's repository than the one that found the problem.

What the graph shape buys

Teams with nothing between them don't wait for each other

This is the direct payoff of every team's run order coming from declarations instead of a fixed position. Two teams with no dependency between them run at the same time, not one after the other with a human in between deciding which comes first.

Two cold starts, two different opportunities

Market research on one product idea runs next to ideation on a completely different one, at the same time, because neither team's consumes field names anything the other one produces.

QA and security, released together

The moment an engineering team finishes, its matching QA and security teams both start. They're reading the same artifact at the same instant, not standing in a queue for it.

Nothing here waits out of habit. It waits only when something it actually needs hasn't been produced yet.

Where this claim actually comes from

Months before this system existed, two coordination approaches for exactly this problem were already worked out. One was a durable, file-based mailbox: agents write to an outbox, a router delivers to inboxes, and nothing has to be running at the same time as anything else. The other was a live coordination hub, a real server handling agent registration and message routing over a socket, a session state machine, and a browser UI with live updates. It was built in a single session and it still sits in a real repo today.

That hub's own source code has two pieces its author left as stubs. Their own comment marks them as a phased plan that was never finished. One of those stubs is named almost on the nose for the mailbox pattern designed alongside it. The concurrent execution this section describes isn't a hopeful feature request. It's the second of those two approaches, already prototyped earlier this year, waiting to be pulled in.

Adding a twelfth team means wiring two fields. That's the whole argument.

A pipeline has to be rewritten every time it grows, because growth means finding the right numbered slot to insert a new step into, and renumbering everything after it. This system doesn't have slots. It has eleven declarations, and the conductor's whole job is reading what each one consumes against what every other one produces. A twelfth team joins by declaring the same two fields as the other eleven. Nobody touches the ten that already exist.

That's also the honest answer to why five teams can start cold, why design takes a brief from anywhere instead of one wired producer, and why copywriting can read a Rails feature or a Go feature or a Tauri feature without anyone hardcoding which. None of it is generosity. It's what falls out of building the run order from declarations instead of assuming one.

If adding a team to a system means rewriting how the other teams run, it was never architecture. It was a script that happened to work eleven times.

Questions worth answering directly

Is this really a graph, or is "graph" just a nicer word for a pipeline?

It's a graph. A pipeline has one fixed position per team. Here, five of eleven teams have no upstream dependency and can start the moment they're called. One team accepts input from anywhere. Five teams share a consumer relationship where any of three possible upstream teams can satisfy it. None of that is a numbered list.

What actually happens to a team with no upstream dependency?

Its consumes field is null. The conductor's own rule: a team with consumes: null can always start fresh. Five teams qualify today, the three engineering teams, market research, and ideation. Nothing blocks them, because nothing is declared as required first.

How does the conductor decide what runs next?

It reads one file, teams.yaml, and nothing else. It infers a sensible order from what each team consumes versus what it produces, not a fixed pipeline position. A team whose consumes field names an artifact stays blocked until that artifact exists. It never opens a team's internal agent or skill files to make this call.

Can two teams actually run at the same time, not just two specialists inside one team?

Yes. Two teams with no dependency between them don't wait on each other. Market research on one opportunity runs alongside ideation on a different one. The moment an engineering team finishes, its matching QA and security teams both start, reading the same artifact at once instead of standing in line for it.

This graph is one view of a larger system.

The headcount

The Roster

101 agents, 11 teams, one conductor. The full count this graph's eleven nodes are built from.

See the roster →

The boundary

The Depth Gauge

What the conductor is allowed to see inside each team, and the tier-one learning loop this page's tier two builds on.

Sound the depth →

The rule

The Conductor Pattern

Why the conductor trusts a team's contract completely and never reads its internal files.

Read the pattern →

The discipline

The Memory Ladder

Files, database, RAG, graph. The same earn-it-through-failure logic this system's own tier-two loop was built under.

Climb the ladder →

The architect

robertrevans.com

Twenty years of production systems, now designing AI architectures. See the work, or bring Robert yours.

Visit the site →