Agent fleet management as discipline

Agent fleet management is the practice of treating multiple concurrent AI agents as a managed resource pool, applying the same operational discipline to agent orchestration that mature engineering organizations apply to infrastructure management. When a team runs 3-5 parallel agents per developer (Yegge Stage 6), the ad-hoc "start an agent and check back" approach breaks down. Agents need scheduling, monitoring, failure handling, resource allocation, and audit trails - the same operational concerns that any distributed system requires.

The fleet management discipline borrows concepts from infrastructure operations: capacity planning (how many agents can run concurrently given cost and compute constraints), health monitoring (which agents are stuck, spinning, or producing degraded output), failure recovery (what happens when an agent hits an unexpected error and how to resume safely), and audit logging (what did the agents do, in what order, with what outcomes). These concerns are not interesting when you have one agent running one task. They become critical when you have dozens of agents running concurrently across multiple teams.

The Gas Town metaphor is useful here. Gas Town, in the post-apocalyptic economies of fiction, is the infrastructure layer that enables everything else - the fuel distribution system that powers all the other machines. Agent fleet management is the Gas Town of AI-assisted development: the operational infrastructure that makes it possible to run agents at scale reliably. Organizations that skip fleet management discipline get the AI equivalent of unreliable fuel supply: agents that fail unpredictably, outputs that are lost because there was no logging, and developers who don't trust agent outputs because they've been burned by invisible failures.

At L4 (Optimized), fleet management is a discipline that engineers practice, not a product they buy. It involves patterns and conventions: how agents are started (with what context, what permissions, what constraints), how their output is captured (where logs go, how artifacts are stored), how failures are handled (retry policies, human escalation paths), and how costs are tracked (per-agent spend, cost-per-unit-of-output). These patterns may be implemented with existing tools (Claude Code, Cursor, custom orchestration scripts) rather than dedicated fleet management software.

• Reliability at scale requires operational discipline - individual agent runs that fail are an inconvenience; concurrent agent runs without failure handling create cascading problems where developers lose work, outputs are inconsistent, and trust in the system erodes
• Cost management becomes non-trivial - a single developer running 5 concurrent agents is spending significantly more on model inference than a developer running 1; at 50 developers, fleet management is the mechanism that prevents inference costs from becoming budget emergencies
• Audit and governance requirements don't disappear at L4 - many organizations have compliance requirements for what code can be generated how; fleet management provides the audit trail that makes compliance possible at agent scale
• Failure modes change at fleet scale - when agents work in parallel on related parts of a codebase, coordination failures (two agents modifying the same file, agent A depending on output that agent B hasn't produced yet) become common; fleet management patterns prevent or detect these failures
• Developer trust requires predictability - developers will delegate high-stakes work to agents only if they trust that agents behave predictably, failures are detected, and lost work is recoverable; fleet management builds that trust

1. Define your fleet management primitives - Before building tooling, define the concepts: what is an agent run (a bounded task with inputs, outputs, and a completion condition), what is a fleet (a set of concurrent agent runs with a shared goal), what is a failure (unrecoverable error vs. recoverable error vs. output quality issue). Having shared vocabulary is the prerequisite for shared practice.

2. Build logging before building orchestration - The first fleet management capability to build is comprehensive logging: every agent run produces a structured log of what context it received, what actions it took, and what output it produced. Logging first means you can debug problems with your first fleet runs; orchestration without logging produces invisible failures.

3. Implement cost tracking at the agent level - Instrument each agent run to capture the approximate token cost of the run. Aggregate this by team and by task type. The first time you run a report showing that 20% of agent runs consume 80% of the inference budget, you will immediately know where to focus optimization effort.

4. Define failure handling policies before you need them - For each class of agent failure (context limit exceeded, tool call error, output quality below threshold), define the policy in advance: automatic retry, human review queue, or silent drop. Defining policies reactively - after a fleet run fails in production - leads to inconsistent handling and lost work.

5. Create dashboards for fleet visibility - Developers running agent fleets need to be able to see, at a glance: how many agents are running, which are complete, which have failed, and what the cost so far is. A simple dashboard (even a shared terminal session showing agent status) changes fleet management from "check each agent individually" to "monitor the fleet collectively."

6. Run fleet retrospectives - After every significant fleet run (a multi-agent feature implementation, a large-scale refactor), run a short retrospective: what worked, what failed, what was unexpected, what would be done differently. These retrospectives are the mechanism for improving fleet management practice over time.

Running fleets without coordination mechanisms. When multiple agents work on related parts of the same codebase without coordination, they create conflicts - overlapping changes, inconsistent assumptions, coordination failures. Build explicit coordination: either serialize agents that touch the same code, or implement a shared state mechanism that lets them coordinate.

Treating every agent failure as a bug. Agents fail. Model outputs are sometimes wrong. Context is sometimes insufficient. Tool calls sometimes hit rate limits. A fleet management discipline that treats every failure as a defect to be fixed creates an unsustainable maintenance burden. Distinguish between systematic failures (always happening, need to be fixed) and stochastic failures (occasionally happening, need to be handled gracefully).

Not capturing the cost curve. The first few fleet runs of a new task type always reveal that the cost estimate was wrong - usually too low. Organizations that don't track per-run costs can't see this pattern and end up with budget surprises. Cost tracking is not optional at fleet scale; it is how you learn to estimate and manage inference spend.

Neglecting the human-in-the-fleet role. Fleet management is not about removing humans from the loop - it is about changing the human role from doing the work to supervising the fleet. A fleet management discipline that doesn't define when and how humans review agent output, approve continuations, and handle escalations creates a fleet that runs autonomously without oversight, which is a governance risk.

Premature optimization of the orchestration infrastructure. It is tempting to build sophisticated scheduling, priority queuing, and resource allocation systems before you have a clear picture of what your fleet workloads actually require. Start with simple conventions and build orchestration infrastructure as the gaps become clear from actual fleet operation.