Building an Autonomous Coding-Agent Fleet

Most teams using AI to write code still work one prompt at a time: a developer in the loop, an assistant in a side panel, a single thread of work. That is useful, and it caps output at one person’s attention.

The next step up is a fleet. Several agents work in parallel, each owning a scoped task, coordinated by an orchestrator, with a human reviewing outcomes instead of keystrokes. I built an autonomous Claude Code agent fleet that files bugs, dedups them and self-merges test-driven fixes, coordinated by a Postgres-backed orchestrator running on Vercel and ECS Fargate. This post covers what mattered most.

A fleet is an orchestration problem

The temptation is to treat this as a model problem: get a smarter model and let it run longer. In practice the model is rarely the bottleneck. The bottleneck is everything around it: how work is split up, how agents stay out of each other’s way, and how you know the output is correct without reading every line.

A workable fleet has three layers.

• An orchestrator that breaks a goal into independent units of work and hands each one to a worker. It holds the plan and none of the implementation detail.
• Worker agents that each take one scoped task, such as a file, a feature or a migration target, and run it to completion in isolation.
• A verification layer that checks each result before it is allowed to land.

Keep the orchestrator thin. The more of the control flow you put in deterministic code, including what to fan out, what to retry and what to merge, the more predictable the whole system is. Let the agents do the open-ended judgment, and let ordinary code decide who runs next.

Using Postgres as the bus

The orchestrator needs somewhere to keep the queue of work, the state of each task and the results. A database you already run does this well. A common pattern is a tasks table that workers claim rows from with SELECT ... FOR UPDATE SKIP LOCKED, so two workers never take the same task, plus a status column and a results column.

-- A worker claims one pending task without blocking other workers
UPDATE tasks SET status = 'running', claimed_by = $1, claimed_at = now()
WHERE id = (
  SELECT id FROM tasks WHERE status = 'pending'
  ORDER BY created_at LIMIT 1
  FOR UPDATE SKIP LOCKED
)
RETURNING *;

This gives you durable state, an audit trail you can query, and one fewer piece of infrastructure to operate than a dedicated message broker.

Isolation makes parallelism safe

The first thing that breaks when agents run in parallel is shared state. Two agents edit the same files, overwrite each other’s changes and produce a merge conflict that neither understands.

The fix is plain and necessary: give each agent its own workspace, meaning a separate git worktree and branch plus a separate scratch directory. An agent should be able to fail, loop or produce garbage without touching any other agent’s work. When it finishes, you integrate on purpose. Agents do not merge themselves into a shared tree.

This costs a little setup per agent and pays for itself immediately. Parallelism without isolation is slower than serial work, because you spend the saved time untangling the results.

The verification layer is the part everyone underbuilds

A confident, well-written, wrong answer is the default failure of an AI agent. How plausible the output looks grows faster than how correct it is. So the question that decides whether a fleet is useful or dangerous is how work gets verified before it lands.

Three patterns hold up.

• Adversarial verification. Ask a separate agent to refute the change, with rejection as the default when it is unsure. A claim that survives a skeptic is worth more than one that survives its own author.
• Different lenses. When a change can fail in several ways, give each verifier its own angle: correctness, security, whether it runs at all. Running the same check three times finds the same bugs three times.
• Deterministic gates. Tests, type checks and builds are required. An agent’s report that everything passes is a hypothesis, and the CI result is the evidence.

The rule that keeps coming up: an agent’s output is a proposal until something other than the agent that produced it has confirmed it.

This is also why test-driven work suits agents so well. A failing test written first gives the agent a precise definition of done, and gives the harness something objective to check afterward.

Knowing when not to fan out

A fleet fits work that splits cleanly into independent pieces: auditing a large codebase, migrating dozens of call sites, reviewing one change from several angles, sweeping for a class of bug. The gains there are large.

It is the wrong tool for one tightly coupled change in which every part depends on every other part. Splitting that across agents adds coordination overhead and integration risk, and one capable agent or one capable person is faster. Part of the engineering judgment is recognizing which kind of problem you have before you start ten agents on a one-agent task.

Controls to add before you scale up

Before you let a fleet run unattended, put hard limits in place.

• A budget per task and per day, in time and in spend, with the run stopping when it is reached.
• A narrow set of permissions, so an agent that goes wrong can only touch the repository and tools it was given.
• A kill switch that stops all workers from one place.
• A log of every action and decision, because you will want to know why something merged.

Where this is going

The teams getting real value from AI are the ones that have built the system around the model: the decomposition, the isolation and the verification. That lets them trust the output enough to stop reviewing every line and start reviewing results. It is a meaningful amount of infrastructure, and a lot of near-term engineering value will come from getting it right.

If you are working out where agents fit into your team’s workflow, or you have tried and hit the correctness wall, that is the kind of problem Twill Software works through with teams. The first consultation is free: get in touch.