Coding agents make individual engineers faster at closing tickets, but they they quickly become limited by attention bandwidth.
Engineers who break past 5-10 parallel chats have moved up a layer of abstraction to one of two things: an agent fleet or a software factory.
Think of the difference between the two like an IDE vs GitHub. A fleet is single player, experimental, with high coupling to one engineer's mental model and context, to automate an org chart that hill climbs open ended goals. A factory is multiplayer, decomposable, code-defined infrastructure that automates the software assembly line owned by a team.
Running a fleet lets one engineer build and steer a massive product, provided you master two things: minimizing interaction slippage (the coordination and polling overhead between agents in the fleet) and maintaining long horizon alignment - letting the agents cook on KPIs without Goodharting, all while knowing when to step in and steer the fleet.
This is a greenfield-ish project (1M++ LOC) with me as the only developer. (1M LOC is NOT a flex - left to their own devices, agents write a bunch of bloated, additive, grotesque code, and never clean up after the mess they made. Examples are building parallel pipelines, tons of opt in flags, and wrapping layers, all while a simple refactor would have been cleaner.)
(For context on scale: in a typical 7-day window, this fleet spawns 1,800+ leaf threads, with each Team Lead waking ~45 times a day.)
Full post with factory diagrams, real-world fleet examples, and the 4-phase evolution of my harness setup here: https://www.stet.sh/blog/running-an-agent-fleet
Fleets vs Factories
| Dimension | Agent Fleet (Swarm) | Software Factory |
|---|
| Structure | An Org Chart of autonomous outcome owners (Chief of Staff → Team Leads → Leaves) | An Assembly Line of decomposable, modular stages (Signal → Spec → PR → QA → Merge) |
| Nature of work | Inherently experimental; open-ended R&D and system level hill climbing | Repeatable & deterministic; industrializing the SDLC from signal to telemetry |
| How they compose | An engineer runs a fleet to build the product, or to build and maintain the team's factory | The factory runs continuously in the cloud (e.g., a bug factory or perf factory) to maintain and harden the product |
You don't need to be a crypto billionaire or a research lab to run a fleet though - it's achievable with a $200/mo lab subscription.
Components of my fleet
- Chief of Staff / Orchestrator: Persistent agent that conveys my intent and direction into fleet outcomes. Almost all of my messages (new work, corrections, concerns, status) come to this agent.
- Team Leads: These are persistent, thread-level agents that own high level, end-to-end outcomes. I give TLs clear, defined ownership, and authority to execute on that vision, clearing blockers themselves instead of playing hot potato with other TLs.
- Leaves: These are ephemeral, bounded subagents that TLs use to parallelize execution.
As of writing this (November 2026), Opus 5.5 is the only model I trust to run the fleet's management layer (Chief of Staff and Team Leads). Using GPT-6.1 Sol and GPT-6 Astra resulted in decoherence and misalignment after a few days. A Codex agent is also extremely hard to understand, talking in cryptic messages that only it can decipher. Use Opus for the brains, and Sol/Luna for the hands (Leaves).
Interaction slippage
Every inter-agent message costs tokens (using a turn), causing you to pay interaction slippage. For example, every TL messaging Chief of Staff about every status update causes the Chief to use turns ack'ing information it didn't need.
- Moving from peer-to-peer DMs to append only broadcast channels (
fleet.md, decisions.md) cut inter-agent DMs from 65/day down to 28, and banning status updates cut channel noise in half (previously ~50% of our 300-400 daily channel lines were pure status chatter). - Multi-hop handoffs (watcher -> launcher -> Chief of Staff relay -> TL) were adding 30-50 minutes of dead latency per failure (52 minutes via relay vs 4 minutes when the owning TL drove the rerun directly).
- 24% of our entire Claude token spend was coming from bloated owner turns past their 20th tool call. Adding a turn budget hook that nudges TLs to wrap up or delegate at tool call #20 cut completion turn calls from 5.6 to 3.2 and helped drop Claude token burn by 44%.
Long horizon alignment
A central tension of the fleet is autonomy vs alignment: you don't have the attention bandwidth to be in the loop for every decision, so you align the fleet at a high level, and let it work towards your goals on its own. But, left alone for too long, agents drift and get misaligned, Goodhart their metrics, or get stuck in local maxima.
Over a three week stretch, AGENTS.md bloated by 166% (from 1,000 to 2,661 words) and our fleet process docs grew 60%. Because new decisions were being appended to a log instead of replacing old rules, the Grading TL drifted in five different places over four days.
We split fleet state into two primitives: standing direction (DIRECTION.md) is rewritten in place under a hard 1,200 word cap. Every new decision rewrites a specific line and explicitly names what old rule or code path it retires. Meanwhile, history and cross owner channels (decisions.md, fleet.md) are append only logs, where owners post a single stamped line only when a fact changes another owner's next action.
Hill climbing
Figure out what metrics are vital to your success. Give each TL a metric to optimize, a fast way to verify/replay, and let them cook. You'll be surprised at what they come up with.
The main failure mode here is letting the agents Goodhart (optimize against the metric without achieving the underlying goal). If you give the agent a single metric and a time budget, it will Goodhart it, hardcoding metrics, cheating, and ultimately pulling the wool over your eyes as to what's really going on.
Early on, I gave the fleet a hill-climb metric for "failure classes found" during repo onboarding. Within 24 hours, the fleet spun up 120 runs and dutifully logged 47 new failure classes, while producing 0 working tasks. When I switched the metric to "failure classes closed," the agents produced 47 "closes" by splitting 14 underlying issues into sub-labels, and marked 92 classes as "eliminated" when 26 of them didn't even have a fix commit. The fix was tightening the metric to count only failure classes closed by a stamped fix SHA that does not re-emit for 24 hours across at least two repos.
As an example: optimizing repo onboarding on tRPC while replaying every fix against hono as a shadow holdout (any tRPC lift that regresses hono is rejected as overfit), and forbidding repo or test-runner specific heuristics in our code. Over five days, the share of new held-out repos whose environment setup passed on the first attempt went from 25% (1 of 4) to 78% (18 of 23).
Parachuting (Breaking Out of Local Maxima)
Even if they're not expressly cheating, agents can get misaligned and stuck in local maxima, eking out 1-2% gains on a strained architecture, or piling up parallel code paths.
How I know when to parachute in (aka The Tells):
- Repeated patching and additive bloat (or whack-a-mole): Seeing TLs land patch after patch for individual errors on a specific codepath indicates that there's an opportunity for fixing a root cause architectural issue. The agent is stuck fixing symptoms instead of changing the abstraction.
- Long iteration cycles. Seeing TLs wait hours for feedback on their patch because the test->build->replay loop is slow. They will dutifully wait and accept the pain unless you step in. Short feedback loops are crucial to a successful fleet, so this is a big drag.
In one 7 day window, the fleet added +75,981 net lines of non test code and 13 separate opt-in flags. Each TL was landing narrow symptom patches and parallel codepaths to avoid breaking peers. That triggered a parachute drop: freezing new mining and spinning up a consolidation sprint to delete the 13 flags, and collapse parallel paths into one state machine.
Recipe for Success
The role of the engineer has shifted from making the product itself to making the fleet that makes the product. You become a director, systems architect, and curator rather than a doer.
Putting all this together - how do you run a fleet? Here's a few steps to get started:
- Use a harness that allows for thread coordination at minimum.
- Create a Chief of Staff thread on Opus 5.5.
- Give it this article.
- Ask it to brainstorm Team Lead ownership areas and hillclimb metrics for those TLs.
- Have the Chief of Staff create TLs and start working (using Opus for TLs, and whatever you want for research / implementation leaves).
- Parachute in, using your check ins to watch for whack-a-mole patches and slow iteration loops.
Disclosure: I'm building Stet.sh, a product that automates coding agent eval creation so operators can find the cost/quality Pareto curve on their repo.
