Run many coding agents without drowning in their output.

Sixteen lessons and five labs on the operational layer of running several coding agents at once: what to isolate, where to run them, how to tell which one is stuck, how much a merged change really costs, how N branches become one main, and what you do when an unattended run fails at two in the morning.

Take this course first

  • Harness Engineering. Fleets multiply whatever one run does. This course assumes a single agent already works reliably inside a harness: rules it reads, gates it cannot skip, and a handoff that survives a restart.
Lessons
16
Project labs
5
Modules
5
Reading
~7h

You finish holding something.

You leave with a Fleet Kit you can run tomorrow: a topology decision, an isolation launcher that stops port and database collisions, a permission and credential policy, a venue off your laptop, a supervision protocol that pages you for the blocked agent, a landing pipeline with gates that survive parallel runs, an audit trail, and an on-call runbook.

The artifact

A Fleet Kit in your own repository: topology and cost model, isolation launcher, permission and access policy, venue comparison, supervision protocol, gates, merge policy, audit records, runbook and rollback rule.

The loop you learn

Scope → Isolate → Supervise → Land

Every lesson has the same shape.

You know what you are buying before you buy it.

01The failure

A specific fleet that broke, with the symptom and what it cost, before any term is introduced.

02The rule

One conditional rule you can apply on Monday, with the observable condition that tells you when it applies.

03The build

The scripts, configs and policies in full, added to the Fleet Kit in your own repository.

04The proof

The check that shows the piece works under concurrency, not just once.

Why it is built this way.

Three decisions that shaped every lesson.

Move one axis at a time

A fleet has four independent axes: concurrency, isolation, verification and locus of control. Every lesson moves one of them deliberately, so you always know which change caused which result.

Containment beats instruction

An agent does what the environment permits, not what the prompt requests. Every safety claim in this course is enforced by a boundary you can point at, never by a sentence the model agreed to.

Count what you can accept, not what you can generate

Generation stopped being the bottleneck the moment you ran a second agent. Throughput is measured in merged changes, and every decision here is priced against that number.

5 modules, 21 entries.

The whole path is public. Nothing is hidden until you pay — only the bodies are gated.

MOD 01Frame the fleet

Before you add a second agent, decide what you are actually scaling. Four axes, a test for which work is fleet-shaped, and a cost model that settles the argument.

MOD 02Contain the blast radius

Worktrees are not isolation. Pick the tier that actually contains the agent, wire the permission policy to match it, and keep the credentials out of reach.

MOD 03Move it off the laptop

Put the fleet somewhere that survives a closed lid, choose the venue on measurements rather than fashion, and make the fleet tell you which agent needs you.

MOD 04Land the work

Generation was never the bottleneck. Measure what you can accept, build gates that survive being run many times at once, and reconcile the branches in a deliberate order.

MOD 05Operate the fleet

Unattended agents need what unattended systems have always needed: a record, a pager, a runbook, and a way back.

Start with the free lesson.

Engineers who already run one coding agent reliably and now want several at once, on and off their own machine.

  • One-time price, lifetime updates
  • Every course included — this one and the next
  • 30-day money-back guarantee
  • No card required to start