Working with Many Agents

The shape of the work

Three acts, and the eight patterns sit in them. A unit is a piece of work one agent can run to completion on its own; the split below divides one job into three of them. The person's role changes across the three acts, which is most of why this is hard: at the split they are deciding, in flight they are absent, and at the join they are reconciling work they did not watch.

On the entries that follow

Same template as OM-001, including the added field. A team is several agents working on one task for one person. Failure Signature earns its place harder here than it did there: a team failure is even further from its cause than a single-agent one, because the person was not present when it happened and is reading a report about it afterwards.

These eight are published in full here, and so is every other set in the catalogue. Rev. 1 of this document expected the reverse: that the entries would move to /patterns and this would become the argument for them, the way OM-001 had gone. OM-001 came back instead. The explorer now carries every set’s position and citations and no set’s prose, so the rule is one rule: the paper is canonical, the catalogue is the graph, and there is exactly one copy of each entry.

Also known as is omitted where no name is genuinely in circulation. These are new enough that inventing synonyms would be dressing.

The split · Pattern 1

Proposed Dispatch

Intent

Let the context that already holds the work propose the units, so the person approves a decomposition rather than authoring one from memory.

Motivation

A person has been working with an agent for an hour. That agent knows the codebase, what has been tried, which constraint bit last time, and what the person actually meant three messages ago. Then the person opens a fresh window and types a new prompt, reconstructing by hand a fraction of what the agent already holds, and doing the decomposition themselves, badly, because splitting work well requires knowing all of it.

The expensive part of fan-out is not running the agents. It is deciding what the units are. Doing that in the party with the least context is the defect.

Applicability

When work decomposes into units that can run independently; when a primary agent holds context the person would otherwise restate; when the person's judgement is better spent on which and whether than on how to phrase it.

Structure

Participants

Primary agent proposes and states each unit's scope. Person approves, edits or refuses. Units carry the proposal forward as their commission.

Collaborations

Takes its form from Constrained Choice (OM-001 · 6): enumerated units, not free text. Approving one is Approval Gate (10) applied to a decomposition rather than an action. What it hands to Authority at Dispatch (2) determines whether the unit can be dispatched unattended at all.

Consequences

• Gain: the decomposition is done by the party with the most context.
• Gain: the person's contribution becomes taste and direction, which is the part only they have.
• Cost: a proposal is easy to approve without reading, and approving without reading automates the wrong half of the job.
• Trap: the agent proposing the work is also the one least able to see what it does not know. A decomposition can be internally perfect and miss a unit entirely.

Implementation

Propose units, not prompts, and make each editable in place. State each unit's scope on the proposal, so approval is informed by what it will be allowed to do rather than only by what it intends. Never dispatch on proposal; the pause is the pattern. Offer refusal as a first-class outcome: a decomposition the person rejects wholesale is a useful result, not a failure of the interaction.

Sample interaction

Suggested task
  Rename the shell to the console, safely
  SHELL_ARCHITECTURE.md becomes CONSOLE_ARCHITECTURE.md and the
  crate stops calling itself a shell — while leaving untouched the…

  [ Start with worktree ▾ ]   Start locally · Send to cloud · Fix here

Failure signature

The person retypes context the agent already had, at the top of every dispatch. Or: dispatched units that overlap or leave a gap, because the person who split them could not see the whole.

Known uses

Suggested-task surfaces that offer a worktree, a local run or a cloud run. Agents that file their own issues for later work. A planning step whose output is a list of separable jobs rather than prose.

Related patterns

Authority at Dispatch (2), Constrained Choice (OM-001 · 6), Approval Gate (OM-001 · 10).

The split · Pattern 2

Authority at Dispatch

Intent

Grant a dispatched agent its authority once, at dispatch, in a form the environment enforces, because per-action approval does not survive more than one agent.

Motivation

Approval Gate (OM-001 · 10) is the strongest pattern in the first language, and it works because the person is there. Consent is per-action, specific, and given with the argument in front of them.

Now dispatch twelve agents. The person is present for at most one. The other eleven face a choice with no good branch: stop and wait for a human who is not coming, which destroys the reason for dispatching them; or proceed unapproved, which destroys the gate. No amount of prompt engineering resolves this, because it is not a phrasing problem. It is arithmetic.

So the gate moves. Authority is granted at the moment of dispatch, bounded to the unit, and enforced by something other than the agent's cooperation.

This is a real loss and should be stated as one. Dispatch-time authority is granted blind: a class of action is approved before any instance of it is seen. That is strictly less informed than Approval Gate. What buys it back is that the scope is narrow, mechanical, and cannot be talked out of.

Applicability

Whenever more than one agent runs without a human present. Also whenever a single agent runs long enough that the person will not be there for its middle.

Structure

Participants

Commission carries the scope. Environment enforces it. Unit acts freely inside it and cannot act outside it. Person grants once and is then absent.

Collaborations

Replaces Approval Gate (OM-001 · 10) for the common case and depends on it for the irreducible set. Its scope is usually realised by Isolation by Construction (3). Progressive Autonomy (OM-001 · 11) is how a scope widens over time, and is what stops this pattern being a permanent grant.

Consequences

• Gain: N agents run unattended without either stalling or running unbounded.
• Gain: the scope is inspectable before dispatch, which makes approval meaningful, not ceremonial.
• Cost: authority is granted before the action is known. This is the pattern's price and it is not recoverable by being clever.
• Cost: enforcement is real engineering. A scope nothing checks is a wish.
• Trap: a scope written in a prompt is not a scope. An instruction is a request to a system that is allowed to be wrong.

Implementation

Express scope as something the environment already enforces: a worktree, a branch, a directory, a token with narrow permissions, a container. Prefer scopes that make the dangerous action impossible to scopes that ask for restraint. Keep an irreducible set that no dispatch may pre-authorise: anything outward-facing, anything that publishes, anything that cannot be undone. Route those back to a live human even at the cost of the unit stalling. A unit stalled on a genuinely irreversible action is the system working.

Sample interaction

commission
  unit      fix the failing snapshot tests
  workspace .worktrees/snapshot-fix      (own branch, own checkout)
  may       read repo · write workspace · run tests
  may not   push · open PR · touch main · network
  escalate  anything outward-facing → back to a human

Failure signature

An agent sent to fix tests pushes to main. Or the mirror image, equally diagnostic: every dispatched agent is blocked on an approval nobody is present to give, and the team's throughput is zero while every unit reports itself healthy.

Known uses

CI job permissions and scoped tokens. sudoers. Container capabilities. Database roles. The narrowly-scoped deploy key that exists because nobody will be watching.

Related patterns

Isolation by Construction (3), Approval Gate (OM-001 · 10), Progressive Autonomy (OM-001 · 11).

The split · Pattern 3

Isolation by Construction

Intent

Give each unit a workspace in which collision is impossible, so parallelism does not depend on the units being careful.

Motivation

Two agents in one checkout. The first moves a file; the second writes to where it used to be. Or both edit the same function and the later write wins silently. Nothing errors, both report success, and the result is a tree neither of them describes. The failure is not that the agents were careless — it is that carefulness was load-bearing.

The remedy is structural and old: give each unit its own copy. A git worktree, a container, a branch, a scratch directory. Collisions stop being unlikely and start being unrepresentable.

The second effect matters as much as the first: isolation is what makes the scope in pattern 2 enforceable. “May write its workspace” means something only if the workspace has edges.

Applicability

Whenever two or more units may touch the same artifacts. Especially where the shared artifact is a working tree, a database, a device, or a service that permits one caller.

Structure

Participants

Workspace is the unit's own. Result leaves it as a durable artifact: a branch, an image, a file. Join is where results meet, and the only place they may.

Collaborations

Realises the boundary Authority at Dispatch (2) declares. Its artifact is what The Return Path (6) carries and what Gather (8) reconciles. The workspace boundary is also the before-state Recoverable Execution (OM-001 · 13) needs: discarding a unit is discarding its workspace.

Consequences

• Gain: parallelism without coordination between units, which is the only kind that scales.
• Gain: a failed unit is discarded, not unwound.
• Cost: setup per unit, in time and disk. Real but small: a worktree costs a few hundred milliseconds and a copy of the tree.
• Cost: conflict is deferred, not removed, and arrives all at once at the join.
• Trap: isolation by convention. “The agents were told to work on different files” is not isolation; it is a hope with a schedule.

Implementation

Prefer the isolation the platform already has, because it is enforced, not simulated. Make the artifact the unit leaves a first-class thing with a name. A branch is better than a diff in a message, because it survives the conversation. Clean up automatically when a workspace is unchanged, or the mechanism accretes debris and people stop using it. And note the shared resources isolation does not cover: a port, a device, a bot token, a rate limit. Those need a mutex or a rule, and where no mutex exists the rule has to be stated, not assumed.

Failure signature

You are reluctant to run two agents at once, and cannot immediately say why. Or a change appears in the tree that no unit's report mentions.

Known uses

Git worktrees and branches. Containers. CI runners, one per job. Database transactions. Any build system with a per-target sandbox.

Related patterns

Authority at Dispatch (2), Gather (8), Recoverable Execution (OM-001 · 13).

In flight · Pattern 4

Fire and Forget

Intent

Make a dispatch complete at the moment it is made, so the person can turn immediately to the next thing rather than staying to shepherd the last one.

Motivation

This is the pattern that makes every other one worth having, and it is best stated as the behaviour it enables:

“Dispatch an agent, then immediately get back to doing something else and dispatch another agent. And the whole time, you are giving the thing that the agents need, which is the taste and the direction and the choices that make this thing you're building yours.”

Now suppose each dispatch asks one clarifying question thirty seconds in. Nothing is broken; each question is reasonable; the agent is being careful. But the person cannot leave, so they cannot dispatch the next one, and throughput is pinned at one agent no matter how many the system can run. A dispatch you have to watch is a dispatch that cannot be followed by another.

The arithmetic is unforgiving. A unit that is ninety-five per cent unattended is not unattended; the five per cent lands on a single serialised human.

Applicability

Whenever the intended working rhythm is many dispatches in a session. Not applicable where a single unit genuinely warrants supervision: a migration, a destructive operation, anything the person wants to watch. Those are supervised runs, and calling them dispatches is the mistake.

Structure

Participants

Commission carries everything the unit needs. Unit proceeds on stated assumptions instead of stopping. Person leaves and does not return until the join.

Collaborations

Puts the whole weight on Assume or Ask (OM-001 · 5): a unit that cannot ask must be very good at deciding when ambiguity actually changes the blast radius, and at proceeding under a stated assumption when it does not. Depends on Authority at Dispatch (2), which is what makes proceeding safe. Status Board (5) is what lets the person leave without anxiety.

Consequences

• Gain: throughput scales with the person's dispatch rate, not their attention span.
• Gain: the person's contribution concentrates on direction and taste, which is where it is scarce.
• Cost: a unit that cannot ask must guess, and some guesses are wrong in ways discovered only at the join.
• Cost: assumptions must be recorded, or the join cannot tell a decision from an accident.
• Trap: one blocking question per unit reintroduces full serialisation. The cost is not proportional to how often it happens; a single question at the wrong moment stops the rhythm.

Implementation

Everything the unit needs travels with it at dispatch; a question it must ask is a defect in the commission, not a virtue in the agent. Where it genuinely must ask, prefer asking and continuing on a stated assumption to asking and stopping, and put the assumption in the report so the join can audit it. Give questions somewhere to accumulate that is not an interrupt, so the person answers a batch when they choose rather than a stream when they do not.

Failure signature

The person dispatches, then sits watching that unit until it finishes. Or, at the team scale, N agents all halted on questions and one person working through them in series — which looks like diligence and is a stall.

Known uses

Batch jobs with all inputs supplied up front. make -j. Anything designed to be run overnight, where asking is not an option and the design absorbed that constraint.

Related patterns

Status Board (5), Assume or Ask (OM-001 · 5), Authority at Dispatch (2).

In flight · Pattern 5

Status Board

Intent

Show every unit's state on one surface, at the granularity the channel actually carries, and never at a granularity it does not.

Motivation

A dispatch card in a console sat on running for eight to sixteen minutes and then produced a wall of text. The events had been arriving the entire time and were being dropped on the floor. One reading covered every state from “just started” to “nearly done”, which is Honest Gauge (OM-001 · 12) at team scale: a gauge whose single value spans the range you needed it to distinguish.

Fixing it surfaced the harder half. The harness never forwards token-level deltas from a subagent. A dispatched agent's work arrives as completed bursts, and the gaps between them are real gaps, not rendering latency. So the honest surface reports counts, completed steps, the last tool, and elapsed time. It must not imply a liveness that does not exist. A blinking cursor there would be a lie the data cannot support, and it is exactly the lie a designer reaches for.

The third finding is a correlation trap worth stating because it fails silently: the lifecycle events key on task_id, not tool_use_id, and two of the five carry no tool_use_id at all. Keying on the obvious field drops every status transition while the surface continues to look like it is working.

Applicability

Any time more than about two units are in flight. Especially where units are long-running, where the person is deliberately absent, and where the only alternative is opening each session in turn to find out what happened.

Structure

Participants

Units emit whatever the harness forwards. Status Board aggregates without inventing. Person reads it at a glance and decides whether to intervene.

Collaborations

A direct application of Honest Gauge (OM-001 · 12); every rule there applies unchanged and matters more, because there are N of them. Ambient Activity Channel (OM-001 · 9) is how this reaches a person who is not looking at the screen. It is what makes Fire and Forget (4) psychologically possible.

Consequences

• Gain: the person dispatches more, because they can see more.
• Gain: a stuck unit is visible as stuck, not as slow.
• Cost: a second rendering surface that must be kept true as the team's shape changes.
• Cost: aggregate views hide individual detail by design, and sometimes the detail was the point.
• Trap: implying liveness the channel cannot support. This is the specific dishonesty available here, and it is attractive because the honest version looks less alive.

Implementation

Report exactly what the channel carries and label it as what it is: elapsed since the last event is not elapsed since the last work, and saying so costs one word. Verify the correlation key by measurement instead of by its name; the obvious field is sometimes absent from the events that matter most. Distinguish “no news” from “no progress”, because they look identical and mean opposite things. And prefer a surface that shows all units badly to one that shows one unit well, since the question being asked is nearly always about the set.

Sample interaction

team · 4 units
  01  snapshot-fix     running   7 steps   last Bash        4m12s
  02  docs-rename      running   3 steps   last Edit       11m03s   ← quiet 9m
  03  theme-extract    done      12 steps  branch ready     6m48s
  04  bench-sweep      halted    2 steps   awaiting a human  0m31s

Failure signature

“Is it still going?” asked about a team. Or a person opening each session in turn to find out what finished: the manual scan a status board exists to make unnecessary.

Known uses

CI dashboards. jobs and process supervisors. Build farm views. A console's subagent cards folded onto the card that spawned them.

Related patterns

Honest Gauge (OM-001 · 12), Ambient Activity Channel (OM-001 · 9), Fire and Forget (4).

The join · Pattern 6

The Return Path

Intent

Route a completed unit's result back to the context that commissioned it, so no human has to carry it there.

Motivation

Four agents were dispatched overnight. In the morning all four had finished, each on its own branch. What happened next is the pattern's whole case:

“I gave them that prompt. And then I took all of the replies and pasted them in series back to the agent that dispatched them.”

A person performed message routing, by hand, with a clipboard. Every unit had succeeded. Every result existed. Nothing errored, and no system reported a problem, because from each unit's point of view there was none — the work returned, but it returned to the wrong place, and a human carried the last hop.

That is why this one is easy to miss for a long time. There is no error state, no red light, and no moment at which anything is obviously wrong. The entire cost is denominated in somebody's morning, and it scales linearly with the team.

A second, subtler failure hides underneath: the branch is not the report. A branch says where the work is. A report says what was done, what was assumed, what was refused, and what the next context needs to know. A team that leaves branches and no reports has produced artifacts nobody can act on without reading diffs.

Applicability

Whenever a unit's result must inform a context other than the person's own attention, which is nearly always, once a primary agent is doing the decomposition.

Structure

Participants

Commission carries the return address. Report is the account, distinct from the artifact. Artifact is the durable work. Commissioning context receives both without a human relay.

Collaborations

Feeds Gather (8), which cannot happen at all without it. Carries what Nested Attribution (7) requires. It is Plan, Approve, Execute, Receipt (OM-001 · 7)'s receipt, arriving from an actor who was itself an agent, which is the precise question OM-001 §17 said it could not answer.

Consequences

• Gain: the commissioning context can reconcile without the person acting as a bus.
• Gain: reports accumulate somewhere durable instead of in a session that will be closed.
• Cost: a return path is a channel, and channels need addressing, ordering, and a story for what happens when delivery fails.
• Cost: writing a real report is work the unit must do at the end, when it is most tempted to stop.
• Trap: mistaking the artifact for the report. A branch is where the work is, not what happened.

Implementation

Put the return address in the commission, so a unit never has to work out where to send anything. Prefer a durable artifact plus a routed notification to either alone: the artifact survives, the notification arrives. Specify what a report must contain (what was done, what was assumed, what was refused, and what the next context needs), because leaving it to each unit's discretion means the reports will not be comparable at the join. And make the missing case loud: a unit that finished without reporting should be visible as such, since silent success and silent failure look identical from outside.

Sample interaction

report · unit 02 · docs-rename
  status     done
  artifact   branch console/docs-rename  (12 files, +340 −295)
  assumed    "shell" in IPC namespaces is load-bearing; left untouched
  refused    did not rename the cargo feature — out of commission scope
  for next   SHELL_ARCHITECTURE.md still names the crate; unit 03 overlaps here
  → routed to: the session that commissioned this unit

Failure signature

The person copies text from one agent into another. Or results that exist, are correct, and were never read by the context that needed them.

Known uses

Exit codes and stdout. Callbacks and reply-to addresses on a message queue. A pull request that closes the issue that commissioned it. Distributed tracing, where a span reports to its parent by construction.

Related patterns

Gather (8), Nested Attribution (7), Plan, Approve, Execute, Receipt (OM-001 · 7).

The join · Pattern 7

Nested Attribution

Intent

Make every result name who produced it and how far down, so no context ever reports another's work in its own voice.

Motivation

An agent dispatches an agent, which dispatches another. The console rendering this had one progress value per card and nowhere to record a depth, so merging a depth-2 agent's activity into its grandparent's card was available and would have looked fine. It was declined, and the reason is the pattern:

Merging “would put the grandchild's work in the parent's voice.”

The consequence of getting this wrong is not cosmetic. A receipt is the basis for acting on work you did not watch. If it says an agent did something and a different agent did it, every judgement built on that receipt is built on a misattribution, including the judgement of whether to trust that agent with more next time, which is what Progressive Autonomy (OM-001 · 11) runs on.

This is the question OM-001 asked and declined to answer: what a receipt means when the actor was itself an agent. The answer is that a receipt must carry its actor and its depth, and that a surface which cannot show depth must count rather than merge.

Applicability

Any delegation more than one level deep. Also at one level, whenever a result will be summarised by something other than the thing that produced it.

Structure

Participants

Actor is who did it. Depth is how far from the person's own commission. Receipt carries both. Surface shows them, or counts what it cannot show.

Collaborations

Extends Tool-Call Transparency (OM-001 · 8) with the dimension a team adds. It is what makes The Return Path (6)'s reports safe to combine. Without it, Progressive Autonomy (OM-001 · 11) adjusts trust against the wrong agent.

Consequences

• Gain: a receipt you can act on, including acting on the actor.
• Gain: misbehaviour is traceable to a level rather than to a team.
• Cost: another dimension every surface, log line and report must carry.
• Trap: flattening for legibility. The flattened version is easier to read, which is exactly why it gets built.

Implementation

Carry actor and depth on every event from the moment it is emitted; they cannot be reconstructed later. Where a surface holds one value per element, count the levels below instead of folding them in, and say that is what you are doing. Prefer “3 steps, 2 of them by a dispatched agent” to a list of five. When summarising, keep the summariser's identity distinct from the summarised: a parent describing a child's work should read as description, never as a first-person account.

Failure signature

A summary nobody can trace. The question “which agent actually did this?” with no way to answer it. Or a parent's report describing work in a voice that turns out not to be its own.

Known uses

Stack traces. git blame and commit authorship separate from committer. Distributed tracing spans with parent ids. Court records, which never merge a witness's account into the judge's.

Related patterns

The Return Path (6), Tool-Call Transparency (OM-001 · 8), Progressive Autonomy (OM-001 · 11).

The join · Pattern 8

Gather

Intent

Reconcile N reports into one account, surfacing where they disagree rather than letting the disagreement land in the artifact.

Motivation

Four reports arrive. Read in series, each is internally coherent and each says its unit succeeded. Two of them touched the same file. One proceeded on an assumption that another's work contradicts. Read one after another, the reports hide that contradiction: nothing in any single one is wrong, and the conflict exists only between them.

This is where fan-out either pays off or quietly produces a mess with several confident authors. The failure has a distinctive shape: a merge conflict that is not textual. The files merge cleanly and the system does not work, because two units made compatible edits under incompatible assumptions.

The temptation is concatenation, and it is strong because it looks like the job is being done. Pasting four reports in series is not a gather; it is a pile with a covering note.

Applicability

Every fan-out with more than one unit. The cost scales worse than linearly with team size, because what must be checked is the pairs.

Structure

Participants

Reports arrive with their assumptions declared. Gatherer holds the original decomposition and so knows where units were expected to meet. Account is one narrative. Disagreements are a first-class output, not a footnote.

Collaborations

Consumes The Return Path (6) and is impossible without it. Relies on Nested Attribution (7) so a conflict can be traced to an actor. The assumptions it reconciles are the ones Fire and Forget (4) required units to make and record.

Consequences

• Gain: one account, at the cost of one context's attention, not the person's.
• Gain: semantic conflicts surface before they reach the artifact.
• Cost: real work that cannot be skipped, and it grows with the square of the team.
• Cost: the gatherer needs enough context to judge, which means it cannot be a fresh agent handed four documents.
• Trap: concatenation dressed as synthesis. If the output's length is roughly the sum of the inputs, no gathering happened.

Implementation

Gather in the context that produced the decomposition. It alone knows where units were expected to overlap, which is where to look first. Compare pairwise on the axes conflicts actually travel: the same file, the same claim, contradicting assumptions, and work one unit refused that another assumed was done. Report disagreements explicitly and early; a gather that hides them has made the team less trustworthy than a single agent would have been. And treat “no conflicts found” as a claim requiring evidence, not as the default.

Failure signature

A clean textual merge that produces a system which does not work. Four reports that each say the work is done, and a result that is not. Or a synthesis whose length is the sum of its inputs.

Known uses

Map-reduce's reduce step. Editorial synthesis of several drafts. Code review across parallel branches. Meta-analysis, whose entire discipline is reconciling studies that each concluded something.

Related patterns

The Return Path (6), Nested Attribution (7), Isolation by Construction (3).

What this does not cover

A pattern language that pretends to completeness is its own dishonest gauge.

• Depth beyond two. Agents dispatching agents dispatching agents. Pattern 7 says what a receipt must carry; it does not say how a person reasons about a tree they never see. The console declined depth-2 rendering for a concrete reason, and nothing here has been tested at depth 3.
• Heterogeneous fleets. Every unit here is the same kind of agent. Dispatching to different harnesses, with different capabilities and different report shapes, is a real case and is not addressed.
• Cost. N agents cost roughly N times as much, and none of these patterns help a person decide whether a fan-out was worth it. There is no pattern here for when not to dispatch, which is probably the most valuable one missing.
• Contention for things that cannot be isolated. A port, a device, an API token with one permitted caller, a rate limit. Pattern 3 explicitly does not cover these, and the honest remedy (a mutex where one exists, a stated rule where none does) is not a pattern so much as an admission.
• Failure of a unit that never reports. Pattern 6 says make it visible. It does not say what the commissioning context should do, and “retry” is not obviously right when the unit may have half-finished something.
• Evaluation. Still. There is no accepted measure of whether a team outperformed one agent on the same work, and until there is, every claim here, including the claim that any of this is worth doing, is argued rather than demonstrated.

Where the argument went

Rev. 1 of this document opened by making the case for a second language: the gap it fills, the evidence behind it, and the forces its eight entries trade off. Rev. 5 moved all three to OM-005 · On the First Four Papers, unchanged, so that this document could be what it is called: eight patterns for working with many agents, presented.

Each id published here is kept and lands on its own line below. A published fragment is owed forever, and moving text is not a reason to break a link someone else wrote. The rule is mechanical: /om-002#x became /om-005#om-002-x.

• The gap this fills is one we namedWhy one turn does not survive being multiplied, and why this is a second language rather than an extension of the first. OM-005 §8.
• The evidenceOne morning’s practice, what it establishes and what it cannot. OM-005 §9, retitled The evidence for Many Agents, all three papers having had a section by the old name.
• Forces that recurThe tensions the eight entries trade off against each other. OM-005 §10, retitled Forces that recur in Many Agents, for the same reason.

The sources list stayed. Its adjacent traditions are prior art for these patterns, the ones this document still carries, rather than apparatus for the case, which is the line the split was drawn on. #sources-and-lineage resolves here as it always did.

Sources and lineage

Directly ancestral

• OM-001, Conversational Agent Control Surfaces — the template, the vocabulary, the Failure Signature field, and the gap this document fills. Its preface carries the debt to Alexander and to the Gang of Four, which this document inherits without restating.
• Gamma, Helm, Johnson & Vlissides, Design Patterns (1994) — the form.
• Alexander, The Origins of Pattern Theory…, OOPSLA 1996 keynote — the standard the form is held to, and the reason Failure Signature exists at all.

Adjacent traditions

• Distributed systems: fan-out/fan-in, work queues with reply-to addressing, tracing spans with parent identity. Patterns 6 and 7 are that literature with a person at the reply-to address rather than a scheduler.
• Build systems and CI: per-job isolation, scoped tokens, dashboards over N runners. Pattern 3 and pattern 5 have direct ancestors there, and the difference is that a build job cannot decide to do something else.
• Operations and delegation practice: commission, scope, report. The vocabulary is deliberately older than software, because the problem is.

Primary material

Patterns 5 and 7 are drawn from measurements made while building a console that renders dispatched agents: the eight-to-sixteen-minute dead card, the absence of token-level deltas from a subagent, the task_id correlation trap, and the declined depth-2 merge. Patterns 1, 4 and 6 are drawn from one person's working practice over several days in August 2026, including the morning of four dispatched agents that produced pattern 6 entire.

What is claimed

Less than OM-001 claimed, and OM-001 was already careful. That document had fourteen patterns, four of them measured, and said plainly that one machine establishes existence rather than frequency. This one has eight, two of them measured, and rests on a practice that is weeks old, not years. It is published now because the failures are real and legible, and because a language argued in public gets corrected faster than one held back until it is safe.

Corrections and counter-examples: hello@organon.art. A pattern shown not to exist in other people's fleets is a useful result and will be recorded as one.