If you already scope integrations or operate AI applications, the difficult handover is familiar: you need to tell the next person what the system may do, what proves it worked, and where their attention is still required. An agent adds uncertainty about which actions it will take to reach the requested result.
Use this article to choose one bounded task for unattended work. The output is a short operating contract: allowed effects, acceptance checks, recovery path, budget and a named reviewer. The grid below helps structure that decision; it cannot make the decision from a green test alone.
A measurement that needs its date
METR's July 2025 randomised trial studied experienced open-source developers on real issues in their own repositories, with early-2025 AI tools allowed on a randomly selected subset of tasks.
They took 19% longer on the assisted tasks.
And afterwards, they believed the tools had made them about 20% faster.
The perceived and measured changes differ by roughly thirty-nine percentage points in that study.
This is a result for that study population and tooling, not a forecast for your team. METR's February 2026 update reports that selection effects and measurement difficulties make its later estimates unreliable as a measure of current productivity. The authors consider greater speedup plausible but do not establish its size.
Treat your own impression as a hypothesis. Compare it with observed completion time, accepted work and review effort before you use it to justify a delivery commitment.
Two questions to start the delegation decision
Model capability matters, and so do tool access, data sensitivity and dependencies. Start with two properties of this task before choosing the operating mode:
Can a machine check the outcome that matters? A test suite, build, schema check or fixture comparison can establish a specific property. Name that property and its blind spots. A screenshot comparison can detect changes while still missing broken interaction or an accessibility problem; a plausible screenshot does not approve the whole experience.
How cheaply can it be undone? A checkpoint, a worktree, a branch, a committed baseline. Not "will it go wrong" but "what does wrong cost."
Use those axes to propose a starting mode, then test whether its assumptions hold.
| Hard to reverse | Cheap to reverse | |
|---|---|---|
| No mechanical check | supervised, step by step, you in the loop | timeboxed autonomous attempts — accept or restart |
| Relevant mechanical check exists | bounded work with a separate release decision | consider a budgeted unattended run after checking effects and dependencies |
The grid is a practical heuristic used here, not a validated predictor of successful delegation. In a handover, record why the task belongs in the selected cell and what new evidence would move it.
The ladder, and why you climb it slowly
These six operating modes name where supervision happens. Higher numbers add coordination obligations; they do not establish greater competence.
The model writes; a human runs every command and owns every effect. Slow, and the right starting point when the environment itself is unfamiliar.
The harness acts. You approve each step and read the diffs. This is where you learn what it gets wrong, which you cannot skip.
Plan approved up front, edits auto-accepted, you review at checkpoints rather than per action.
A separate acceptance check determines whether the result may advance. A Stop hook can request more work, but it is not a durable release gate: hook behavior and overrides depend on the runtime. Keep the acceptance state and evidence outside the model's own completion message.
Headless runs, background sessions, loops. You see records and gate results. This rung adds a new failure mode: nobody was watching.
Parallel isolated workers plus orchestration. Test for duplicated work, collisions, lost state and cost growth. A task that works in one session has not yet demonstrated those coordination properties.
Change modes after representative checks support the change. Familiarity alone is insufficient.
Each mode changes the failure cases you must cover. Before switching, test the new unattended or coordination behavior on a bounded task and record what would force a return to closer supervision.
A well-tested, low-stakes task may be a candidate for unattended work. That does not establish that a fleet is useful or that another task deserves the same mode. For core business logic, inspect whether the checks catch the actual failure and whether recovery is possible. Familiarity with the tools does not answer either question.
Mastery is rung-matching, not rung-climbing. The skilled operator is the one who correctly puts a task on rung 1 when it belongs there.
Allocate review capacity before adding workers
Review can become the bottleneck even when generation is fast. Measure the time to inspect findings, resolve disagreements and integrate accepted changes.
Ten sessions can consume substantially more tokens and produce more material to inspect. The multiplier depends on their work, context and retries; there is no fixed tenfold relationship between workers, cost and review effort.
Increase parallel work only when you can name the capacity to review and integrate it. Fresh-context reviewers or writer/reviewer pairs may help, but their findings also need validation. Measure whether they detect useful defects and how much false-positive work they create.
An operator who cannot say where the review capacity for a fleet comes from has not designed a fleet. They have designed a backlog.
Decomposition has to survive the failure modes, not just describe the work
The documented ways delegated work goes wrong are stable across sources: stopping at looks done; drifting out of scope; duplicating a sibling's work when the brief was vague; degrading as context fills; writing placeholder implementations under loop pressure.
Decomposition that survives them:
- One task per dispatch. Not one theme, one task.
- Disjoint file ownership per worker. The agent-teams documentation is blunt: two teammates editing the same file leads to overwrites, so break the work so each owns a different set of files.
- The brief carries objective, output format, tool guidance and boundaries — not just the request.
- The check rides with the task. Either in the prompt or as a gate outside it, but attached.
- Scope fences in the reviewer's brief: nothing outside the task's scope changed.
This carries a familiar delivery skill into agent work: assign responsibility, expose dependencies and define the receiving interface. Model-specific failure modes still need their own tests.
Failure modes to test before handover
The cheapest failure-mode education available
Read the version-gated notes in the documentation as scar tissue.
Use release notes to identify behavior that needs a regression check: permission handling, worker shutdown, path boundaries or resumed task state. Bind the observation to the version installed in your environment. A documented fix suggests a case to test; it is not evidence that your combination of configuration, tools and services reproduces the fix.
What to do on Monday
Take the three tasks you were about to delegate. For each, answer only two questions:
Can the machine check it? If no, you are supervising, and no amount of prompt care changes that.
What does wrong cost? If the answer is "a repeat," experiment freely. If it is "a customer finds out in March," you are on rung 1 regardless of how well it has been going.
The grid's blind spot becomes visible in a task like "clean up this customer list" looks cheap to reverse (it's a copy, you kept the original) and mechanically checkable (row count, duplicate count). A quick reading of the grid suggests unattended work. But "clean up this customer list" that silently also merges two records that were never actually the same customer is a check that passed and an outcome that's wrong, because the check you wrote (row count changed correctly) isn't the check that would have caught the actual failure (two Alexes both named Alex Rivera collapsed into one). The grid tells you the task is checkable. It doesn't tell you whether the check you actually wrote is checking the right thing. Include a fixture with two distinct people sharing a name, then verify they remain separate. That concrete counterexample is more useful than treating the grid's “yes” as acceptance.
Then meter one task: wall-clock time, reported usage, review effort and whether the acceptance checks passed first time. These observations start a local baseline. Keep the task and tool versions with the result so a receiving team can judge whether the comparison applies to its own work.
Rot register
Sources reviewed 2026-09-08. Documentation supports the described contracts; it is not a receipt that every operating mode was executed here. Re-check the installed version before transferring a command or permission assumption.
| Claim | Re-check at |
|---|---|
| Subagent defaults and background behaviour | code.claude.com/docs/en/sub-agents |
| Headless contract and the bare flag | code.claude.com/docs/en/headless |
| Goal-condition evaluator behaviour | code.claude.com/docs/en/goal |
| Agent teams status, limits and token cost | code.claude.com/docs/en/agent-teams |
| Worktree isolation boundaries | code.claude.com/docs/en/worktrees |
| Productivity evidence | July 2025 trial and February 2026 measurement update |
Measure model use, review and integration for the work you actually accept. The next article explains which cost records to keep and how to compare a change in operating mode.
