Delegation patterns: a brain and a worker

The risk in handing work to a cheaper model is not that you get something obviously bad. It is that you get something plausible, nobody reads it, and a week later it is live. This is the split we actually run: one capable model that thinks, one cheap model that executes, and a verification step that is the whole reason it is safe. Plus the one-sentence test for what qualifies, and the list of things we refuse to delegate at all.

The problem: one model doing every job

Most people run every task through whichever model they trust most. That is a defensible default and it is also how you end up paying a reasoning model to swap a font family across six files, or to rename forty images to a consistent pattern. The work gets done. It costs more than it should, and it uses up the context of the session you actually needed for thinking.

The obvious fix, hand the cheap stuff to a cheap model, has an obvious failure mode: the cheap model does something slightly wrong, confidently, and you find out later. Both problems are real. The pattern below is what happens when you take both seriously.

The split: brain and worker

Two roles, and they never swap.

The brain is the capable model. It owns planning, architecture, judgment, debugging with reasoning, anything touching credentials or configuration, and every decision about what good looks like. It also owns the delegation decision itself and the verification afterward.

The worker is a cheaper or faster model running headless, with no memory of your project and no authority. It receives a scoped task, does exactly that, and returns.

The concrete version we run: a command inside the planning session hands a task to a headless worker. Bulk renames, a CSS class applied consistently, scaffolding a file from a spec, a font swap, formatting and lint passes. The brain writes the task, the worker does it, the brain reads every changed file before anything is considered done.

There is also a mode switch, which turns out to matter more than it sounds. Delegation is either on or off for a session. When it is on, mechanical work goes out by default and the brain has to justify keeping it. When it is off, the brain does everything itself. Without that switch, delegation is a thing you keep meaning to use and never do, because in the moment it is always faster to just do it. A default is what makes a pattern actually get used.

The one-sentence test

One rule filters most of it:

If you cannot describe the task in one sentence, you cannot delegate it.

Not one paragraph. One sentence, with the files named and a done-condition inside it. “Rename every file in assets/photos/ to YYYY-MM-DD-slug.jpg based on its EXIF date” passes. “Clean up the assets folder” fails, and it fails for the right reason: clean up is a judgment call you have not made yet, so the worker will make it for you and you will not like the version it picks.

The test works because the sentence is doing double duty. It is the instruction, and it is the proof that the thinking is already finished. If you find yourself writing “and then use your judgment about,” stop. That is the brain's job and you were about to give it away.

The refusal list

Some categories never go out, regardless of how neatly they fit in a sentence. Ours:

• Anything touching secrets. Environment files, API keys, credential stores, agent configuration directories, git configuration. A worker with no context is exactly the wrong thing to point at a file whose damage radius you cannot see.
• Architecture and refactors. These look mechanical and are not. “Extract this into a shared module” contains a hundred small decisions about boundaries.
• Debugging that needs reasoning. If the fix were known, it would be a one-sentence edit. If it is not known, the work is diagnosis, and diagnosis is the brain's job.
• Writes outside a clear project directory. Scope the blast radius before you scope the task.
• Copy, without a voice guide attached. A worker writing in your voice with no guide will write in the generic one. That is not a model failure, it is a missing input. See voice and tone.
• Anything already failed once. Retry a failed delegation at most once, with stricter instructions. Two failures in a row means the brain takes it back. Loops here quietly cost more than the task ever would have.

Write your version of this list down before your first delegation, not after your first bad one.

The handoff packet

The worker knows nothing about your project. Every gap you leave gets filled with a guess. Six things go in every handoff:

1. The one-sentence task, with the done-condition in it.
2. The exact files or directory. Named. Not “the styles.”
3. What not to touch. The explicit boundary, because a helpful worker will improve things you did not ask about.
4. The reference document to read first, if the task has a standard: the voice guide for copy, the design tokens for interface work, an existing file to pattern-match against.
5. The output format. Edit the files in place, or return a diff, or write a new file at this path. Ambiguity here produces the most annoying failures.
6. What to do when stuck. Return a question rather than improvising. A worker that guesses is worse than a worker that stops.

That packet takes ninety seconds to write, and it is the difference between delegation as a time saver and delegation as a slot machine.

Verification is the whole safety system

Everything above is setup. This is the part that makes it responsible.

The brain checks every delegation before it counts as done, and the checks are mechanical enough to be boring:

• Read every changed file. Not a summary of the changes. The changes.
• Syntax-check anything executable. For JavaScript, node --check on each touched file. A worker that produces a file that will not parse is a problem you want to find in ten seconds, not at deploy time.
• Check copy against the forbidden list. Searchable rules exist so that this pass is a search, not a judgment.
• Load the thing. If it renders, render it.

When the output has drifted, revert it. Do not patch a drifted result, because you will spend more fixing it than you saved. Revert, sharpen the sentence, retry once. Two drifts in a row and the brain does it directly.

There is one more discipline worth copying: log every delegation, one line, in the same daily note where the rest of the session gets recorded. What went out, what came back, whether it drifted. After ten entries you will know precisely which categories are worth delegating in your work, and that is information no general guide can give you.

The honest bar: if verifying the work takes longer than doing the work, do not delegate it. That single rule kills most bad delegations before they start.

The other pattern: parallel, not cheaper

There is a second delegation shape that people confuse with this one, and the difference matters.

Brain-and-worker splits on cost: cheap model, mechanical task. Parallel subagents split on breadth: the same capable model, run many times at once, one instance per item. Ten competitors, ten agents. Forty documents, forty summaries. The trigger phrase is “do this same thing for each of these,” and the gain is not price, it is that each agent keeps a small focused context instead of one agent losing details across forty long pages. That pattern is covered in research workflows.

Both patterns need the same closing move. Someone competent reads the result. Neither one is a way to have less oversight, only a way to spend it where it counts.

What breaks

Judgment dressed up as a chore

“Tidy this file,” “make the spacing consistent,” “simplify this function.” Each sounds mechanical and each contains a decision you have not made. If the worker has to choose the standard, the task is not delegable yet. Decide the standard, then delegate applying it.

Verification quietly stops happening

This is the real failure mode, and it arrives about two weeks in, when delegation has worked well enough that checking starts to feel like paperwork. That is exactly when a drifted result gets through. The fix is to keep the checks cheap and scripted so skipping them saves you almost nothing.

Context starvation

A sentence that is unambiguous to you can be ambiguous to something that has never seen your project. When a worker returns something odd, reread the sentence you sent as if you knew nothing. Usually the ambiguity is right there.

Optimizing the wrong cost

If a mistake in this task costs an afternoon, the model price is not the number that matters. Delegate to save time on work whose failure is cheap and visible. Keep everything whose failure is expensive or silent.

Your turn: find your first safe delegation

1. Look at last week. Write down three tasks you did that needed zero judgment: a rename, a format pass, a repeated find-and-replace, filling a template.
2. Write each as one sentence with the files named and the done-condition included. Any that resist the one sentence are not ready, and that is the test doing its job.
3. Build the packet for the best candidate: task, files, boundary, reference doc, output format, what to do when stuck.
4. Send it to a cheaper or faster model than your usual one.
5. Verify properly. Read the diff, syntax-check anything executable, search the copy for banned words.
6. Log one line about how it went. Ten of those lines tell you what is safe to delegate in your work, which is the only version of this answer that is worth anything.

Back to

All workflows

→