The Fleet Model

Most AI agent demos show a single agent doing a single task. We run a fleet of specialized agents that operate a production website - and this lesson explains why that distinction matters.

Why Not Just Hire People?

The honest answer: we do both. The AI agent fleet does not replace human judgment - it replaces the mechanical repetition that surrounds human judgment. Every Thursday evening, a course must be drafted, reviewed for differentiation, built to a quality bar, wired into three site touchpoints, and submitted for approval. That sequence is deterministic enough that a well-specified agent can execute it. The human still decides whether to merge. But the human does not spend four hours building HTML they then have to review as well.

This is the core economic argument for the fleet model: recurring, well-defined tasks with deterministic structure and meaningful quality bars are where autonomous agents pay off. The more you can describe the task completely enough that a capable person could execute it without asking questions, the more likely an agent can too.

The Fleet We Run

Our production fleet has five agents, each specialized for one recurring workflow:

What Makes This Different from a Single Agent

A single agent running in a long session faces compounding risk: the longer it runs, the more its context window fills with earlier decisions that may have been wrong, the more its tool use can drift from the original intent, and the harder it becomes to inspect what happened if something goes wrong. A fleet of short-lived, specialized agents avoids most of these problems:

• Specialization reduces ambiguity. ContentCreation-Draft only knows about course content. It cannot accidentally fix a bug. It does not have the tools or the spec to do so. Narrow scope means narrow failure modes.
• Short sessions mean clean context. Each agent run is a fresh start. It reads its spec, reads the current state of the repo, does exactly its job, and commits output. The context window is never contaminated by last week’s decisions.
• Git is the coordination layer. Agents do not need to know about each other. They all read and write to the same git repository, which provides versioned history, conflict detection, and the ability to inspect and roll back any agent action. This replaces message queues, shared databases, and orchestration infrastructure.
• PRs are auditable handoffs. Every agent output is a pull request. The PR diff shows exactly what the agent changed, the PR description explains the reasoning, and the merge history is the complete audit log of everything the fleet has ever done.

The Three Properties Every Fleet Agent Needs

Not every AI can function as a fleet agent. The agents that work reliably share three properties:

What This Course Is

This is a first-hand case study course. The fleet described above is real and running. The patterns in this course are drawn from months of operating it - the ones that worked, the ones that failed spectacularly, and the principles that emerged from both. The source material is the codebase itself: the runbooks, the specifications, the TODO file, the metrics log, and the incident postmortems are all in the same repository as these course files.

This gives the course a property most agent courses lack: genuine Experience, in the E-E-A-T sense of the word. We are not explaining how multi-agent systems could theoretically work. We are explaining how this one actually does.

What This Course Covers

• Lesson 2 - Specs as Programs: How to write specification files that give agents unambiguous instructions, and the structural patterns that make specs reliable
• Lesson 3 - The TODO-as-Blackboard Pattern: Multi-agent state coordination using a shared file and git as the synchronization layer
• Lesson 4 - Tool Use and Capability Design: The principle of least privilege applied to AI agents, and how to design tool grants that fail safely
• Lesson 5 - Guardrails and Human-in-the-Loop Gates: The PR gate pattern, scope constraints, branch conventions, and when human review is non-negotiable
• Lesson 6 - Monitoring and the Metrics Feedback Loop: Measuring what agents actually accomplish, not just whether they ran, and using those signals to improve specs
• Lesson 7 - Failure Modes and Recovery: Real failures from the logs and the recovery patterns that addressed them
• Lesson 8 - Build Your Own Fleet: The maturity model, the 30-day plan, and the fleet design checklist