The autonomous dispatch method
How I run five to ten autonomous coding agents at once, safely, cheaply, and on repeat.
By Andrew J. Pyle
I run five to ten autonomous coding agents at once. They write features, fix bugs, add tests, and ship real work while I am away. This is the exact method that makes it safe, cheap, and repeatable.
This is the version I wish I had when I started. One operator sets the priorities. A fleet of agents does the work. Nothing is sent, paid, or deleted without a yes.
01ONE JOB PER AGENT
The core idea
One operator can run many autonomous coding agents at once. The method is simple. Each agent gets one clear job, the right model for it, and its own isolated workspace.
One thread is one independent unit of work. It carries its own model, its own autonomy level, and its own git worktree when it writes files. I paste one self-contained prompt into a fresh session. The agent runs to a clear Definition of Done. Then it merges or opens a pull request.
The planning step produces a kit of paste-ready prompts. I spin up the threads. The agents do the work. I review on return.
02WHAT NOT TO AUTOMATE
Before you dispatch
The fastest way to waste a day is to dispatch the wrong work. Before a unit of work becomes a thread, it has to pass three questions.
- Is the job bounded? One repo, one concern, a clear finish line. If the scope is fuzzy, an agent will wander.
- Is the end state safe or reversible? If a mistake would touch production data, money, or a live send, the thread stops at a pull request, never a merge.
- Can the whole job fit in one self-contained prompt? If it needs me to steer it mid-run, it is not ready to dispatch.
Some work never gets dispatched autonomously at all. I keep a short do-not list, and it stays on the human side of the line.
- Anything that needs my hands: secrets, logins, arming a live system.
- Irreversible or outward-facing sends: email, social posts, deletes, without a per-run yes.
- A decision only I should make. An agent that hits one files a task and stops.
03NON-NEGOTIABLE
The five rules
Five rules make a fleet of agents safe, cheap, and repeatable. Every prompt carries them inline.
- Isolate every file-writing thread in a fresh git worktree off the main branch. Parallel agents in one checkout corrupt each other. Read-only threads can share one checkout.
- Right-size the model for the task. Never pay top-tier rates for simple work. This is how many parallel threads stay inside a tight budget.
- Match autonomy to blast radius. Safe, reversible work merges on green tests. Production data, money, deploys, and security stop at a pull request.
- Write self-contained prompts. Each prompt carries its own context, guardrails, and Definition of Done. It never depends on anything outside the block.
- When blocked or unsure, file a task and stop. An autonomous agent never guesses on a decision the operator owns.
04THE BUDGET LEVER
Right-size the model
The model choice is the budget lever. I set it per thread, never mid-session. The rule is to pick the cheapest model that clears the bar.
| Work type | Model tier | Why |
|---|---|---|
| Mechanical edits, formatting, data entry, known commands, triage scans | Fast | Cheap and enough. |
| Default worker: features, bug fixes, tests, most builds | Mid | Best capability per token. |
| Hard debugging, architecture, adversarial review, high-risk design | Top | Reserved. Most capable and most costly. |
Token discipline does the rest. I scope each unit tight. I keep work read-only by default and mutate only where the unit needs it. I reuse an existing tool instead of building a new one. I never fan out a team of agents for a single-fact lookup.
The cheapest model that clears the bar is the right model. Paying top-tier rates for simple work is how a fleet gets expensive fast.
05WHO MERGES
Match autonomy to blast radius
Autonomy is not all-or-nothing. It is matched to how much damage a mistake could do. Most work is safe and reversible, so most work merges on its own. The risky minority waits for a human.
| Posture | When | End state |
|---|---|---|
| Merge on green | Tests, docs, read-only proposals, low-risk reversible edits | Merge once tests pass. File a verify task. Stop. |
| Stop at a pull request | Production data, money, deploy config, security fixes, a new public repo, client work | Open the pull request. Request approval. The operator merges. |
The agent decides which posture a unit falls under from the rule above, not from its own judgment in the moment. That is what keeps the line in a fixed place.
06A WORKED EXAMPLE
One thread, start to finish
Here is a real shape of one thread: raise the test coverage on a module. It is safe, reversible, and bounded, so it merges on green. The whole job fits in one prompt.
# Thread: raise test coverage on <module>
# Model: mid tier Autonomy: merge on green
Context: <what the module does, where it lives>.
Task: raise coverage to <target>. If you find a real bug,
fix the product, never write a test that asserts the bug.
Guardrails:
- fresh worktree off main
- secret-scan the diff before any push
- no production writes
Definition of done: tests pass locally and in CI,
coverage is up, PR merged on green.
If blocked or unsure: file a task and stop.The agent spins up its own worktree, writes the tests, runs them, pushes, and merges once CI is green. It files a follow-up task for anything it noticed but was not asked to do. I never touched it.
07THE UNGLAMOROUS 70 PERCENT
The part nobody talks about
Spinning up ten agents is the easy, fun part. It is a small fraction of the work. Most of the effort is before and after: writing prompts tight enough to run unattended, and reviewing what comes back.
Agents are not deterministic. Two runs of the same prompt can land differently. So the real skill is not prompting, it is review. I read the pull requests, I read the filed tasks, and I merge the work that waited for a human.
The operator is the bottleneck, and that is correct. The method does not try to remove the human from the decisions that matter. It removes the human from the typing.
08HOW A SESSION RUNS
The run loop
- Generate the kit. Planning writes a dated file of paste-ready prompts, ordered by priority.
- Keep the machine awake. A sleeping machine kills long-running workers mid-task.
- Spin up each thread. Open a terminal, set the model, paste the prompt. Repeat for as many threads as the budget allows.
- Let them run. Each thread ends at merge-on-green or an open pull request, and files its follow-ups as tasks.
- Review on return. Read the open pull requests and the filed tasks. Merge the work that waited for a human.
09COLLISION AND ISOLATION
Why it does not break
Many agents in one codebase sounds like a recipe for chaos. It is not, because isolation is the default.
- Different repositories never collide. No special handling is needed.
- Multiple threads in the same repository each get their own worktree.
- Read-only threads write to notes or a portal, not the repo, so they share one checkout safely.
- Numbers that auto-increment across branches, like migrations and ticket ids, get re-checked against the main branch right before merge.
10NEXT STEPS
Start small
You do not start with ten agents. You start with one, prove the loop, then widen it.
- Pick one bounded, reversible job you have done by hand more than once.
- Write it as a self-contained prompt with its own guardrails and Definition of Done.
- Run it read-only first. Have the agent propose a diff, not merge it.
- Once you trust the loop, let safe work merge on green and add a second thread.
- Keep a do-not list. The point is leverage, not removing yourself from the decisions that matter.
One operator sets direction. A fleet of agents ships the work. Nothing irreversible happens without a human saying yes.