Delegation, and what a unit owner decides without asking

Two shapes of work exist here. Flat: the coordinator dispatches an agent per step, verifies it, merges it. Two-tier: the coordinator dispatches one unit owner, which dispatches its own agents, integrates and verifies their work, and reports one result up.

Two-tier exists because the coordinator's context is the scarce resource, not tokens. An owner plus three agents probably costs more tokens than the coordinator doing the same unit. What it buys is that the coordinator stays short and can therefore keep running.

The rule that makes the layer worth having

The owner's authority was the owner's own objection to this design, on 2026-09-16:

if for every question the actual implementing agent asks his owner, and the owner needs to reach back to you, then we're just paying more tokens, not less.

He is right, and it is decisive. A middleman that forwards questions is pure overhead - it adds a context, a round trip and a summary, and removes nothing. So:

Reversible and inside the unit: decide. Irreversible or outside the unit: ask.

That is the same test adr-008 and adr-013 use one level down, and it resolves nearly everything. The default is decide and record the decision in the commit message, not ask. An owner that escalates a reversible choice has failed at its job in the direction that costs the most.

What a unit owner decides alone

Everything on this list, without asking, including when it is unsure:

• Every implementation choice. Naming, structure, which function carries the logic, what the tests assert, which fixtures exist.
• Its own fleet. How many agents, what each brief says, when to stop dispatching. And whether a returned result is acceptable - rejecting work and re-dispatching is the owner's call and needs no permission.
• Conflicts inside its unit, including conflicts with main in files its unit touches.
• Scope it drops. An owner may cut a sub-task, and then it must say which and why in its report. Silently narrowing is the failure; deciding to narrow is not.
• Strengthening anything. A wider test, a new gate, a stricter fixture, a known-bad input. Never needs asking.
• Filing tickets for what it finds and will not fix.
• Anything the repository's own rules already settle. The rules are in CLAUDE.md, docs/PROCESS.md and each directory's CLAUDE.md. An owner reads them; it does not ask the coordinator to interpret them.

What a unit owner must escalate

Short on purpose. Each of these is irreversible, outside the unit, or a decision somebody with more context has to make:

• An architectural decision - a new ADR, or anything that contradicts one.
• Anything that spends money or touches production. A deploy, a tofu apply, a DNS record, a paid API call.
• A Tier 1 shared resource per adr-013: the database, credentials, the merchant account, the sending identity.
• A rule change. Editing CLAUDE.md, docs/PROCESS.md, or a gate's subject. Fixing a gate is the owner's; changing what a gate is for is not.
• A red gate it cannot turn green honestly. Never narrow the gate. Stop and say so - that is a finding, not a blocker.
• Anything needing the human: a credential, a billing decision, a legal choice, a name only he can pick.

How to escalate without wasting the round trip

An escalation costs a stop, a notification, a reply and a resume. So it must carry its weight:

1. Do everything that does not depend on the answer first. Then ask.
2. Ask once, with everything. Four questions in one stop cost one round trip. Four stops cost four.
3. State your recommendation and what you will do absent an answer. A question with a default attached can be answered with one word, and can sometimes be left unanswered entirely.
4. Say what you already did, so the answer lands on a known state rather than on an imagined one.

The mechanism: the owner stops and its report carries the question. The coordinator answers with SendMessage to the same agent, which resumes with its context intact. There is no live interrupt, so a stop is a real cost and step 1 is the one that matters.

What the coordinator owes the owner

Delegation fails from above as often as from below.

• A brief that names what it is unsure of. On 2026-09-16 every one of nine agents corrected something in its brief - a count, a premise, a claim about what had never been run. All nine corrections came from briefs that said "verify this rather than trust it". A brief written as though it were complete gets confirmed rather than corrected.
• The map, not the treasure hunt. An owner that has to locate the declarations before it can work pays the coordinator's orientation cost again, once per unit. That is what docs/ORIENTATION.md is for.
• A compound branch. The owner merges its agents to atomic/<unit>/<step> and then to compound/<unit>. The coordinator merges compound to main. Nobody else touches main, which is also the owner's standing rule.

What the coordinator must not delegate

Verification of the claim it is about to repeat.

Every agent report on 2026-09-16 contained at least one error about its own work - six commits reported as nine, one conflict as two, 25 self-tests that were 26, two survivors that were artefacts of a narrow selection. None of it dishonest; a report is written from memory of intent while the branch is a record of what happened.

A unit owner reviewing its own agents inherits that blindness one level up. The coordinator reading the owner's summary of their summaries is what docs/GLOSSARY.md calls vacuous corroboration, and OPS-124 is the ticket.

So the owner's report is claims with commands, and the coordinator runs a sample of them against the artifact. One or two turns. On 2026-09-16 that habit caught every one of the errors above.