Should You Run an Autonomous Agent Fleet?

§0How to use this sheet

Fill every field before funding or dispatching. A field you cannot fill is itself a finding — write “cannot fill” and the reason, and count it against GO.

• Items tagged (ch14:N) restate a rule from Chapter 14 of Human Out of the Loop; line mapping in the source file ch14-field-worksheet-sources.tsv.
• No reported figure from the book is used as a decision criterion anywhere in this sheet. Where the chapter prints thresholds (volume, team size, budget, accuracy, factory break-even), the sheet asks you to measure a baseline, price the alternatives, and write your own pass/fail line before scoring.
• Untagged fill-in fields are worksheet structure added for this pack; they carry no claim from the book.

Why fill it in honestly: the framework’s first full run returned a verdict its own authors hated — it was designed to return a verdict (ch14:11). That is the point of the instrument.

§1Intended user, problem, and evidence for demand

Built for the technical leader deciding whether to fund one of these things (ch14:11) — not for choosing a model or a vendor. The decision this sheet forces is whether to run agents at all, how many, and under what stop rules.

Evidence for demand — receipts, not enthusiasm

Worksheet prompt: list what you can show today — tickets per month, hours spent, measured cost of the status quo, named people asking. If the list is empty, write “zero receipts” and treat Gate 1 accordingly.

The decision decomposes into four gates, in order (ch14:17–20): (1) agent at all, or deterministic software? (2) more than one agent? (3) factory or hand-built? (4) own or rent?

§2Gate 1 — Does this problem want an agent at all?

The dividing line is not “AI code” versus “human code”; it is deterministic execution paths versus stochastic decision points (ch14:32). Rule: confine the stochastic part to the smallest zone that pays for it, and let everything else stay software (ch14:32).

Agents earn their keep where specification is the bottleneck — underspecified requirements, cross-domain integration, one-off tasks, prototyping, runtime adaptation (ch14:28). Traditional architecture wins where execution is the bottleneck — high-volume low-latency paths, regulated and auditable domains, cost-sensitive scale, long-lived systems (ch14:30).

Answer before any model question: who can tell my agent it’s wrong, how fast, and at what cost? (ch14:34) If the answer is “a professional, slowly, with liability attached,” the bar is much higher — or the real project is building the verifier first (ch14:34).

Write the error price sentence (ch14:50)

One wrong answer costs us $ because

If you cannot write that sentence with a defensible number, you are not ready to choose an architecture (ch14:50).

§3Gate 2 — Does it want more than one agent?

The second gate of the four-gate decomposition (ch14:17–20). The chapter frames it with reported volume, team, budget and accuracy thresholds from a fleet-authored synthesis; this worksheet deliberately reproduces none of them. A threshold you did not measure and did not choose is not a gate — it is somebody else’s number. The gate opens on five of your own inputs: a measured baseline, priced alternatives, the incremental value of a fleet over the best alternative, the support capacity you can actually sustain, and pass/fail criteria you declare before scoring.

Governance artifacts to name at kickoff

Practice fields; the survey statistics the book attached to this list are provenance-flagged and omitted — the practices stand (ch14:48).

§4Gate 3 — Does it want a factory?

The third gate (ch14:17–20). The chapter’s rule of thumb is qualitative: if your realistic roster is a handful of agents, you do not need a factory — you need a few well-built agents and a good eval harness (ch14:46). The break-even roster count the chapter prints alongside that rule is a reported synthesis figure and is not reproduced here; price factory versus hand-built with your own numbers instead.

§5Gate 4 — If you run it: own vs rent

Own the identity layer, rent everything else (ch14:88). Own: the identity specification, the provenance/falsification machinery, governance, dispatch logic — the things that encode your judgment about your agents. Rent: inference, embeddings, vector storage, runtime/hosting, messaging, observability (ch14:88).

Operational test: if you can swap the vendor without your agents changing who they are, rent it (ch14:88). Build a protocol, not a platform (ch14:90). Sequence: substrate before factory — no new capabilities until existing ones are reliable (ch14:92).

§6Budget and time limits

Fund the fleet and the audit function as one budget item or you have funded neither (ch14:60). Budget the ops, not the generation: generation is the cheap part — generation scales cheaply with complexity while verification does not (ch14:58, ch14:112).

The dated maintenance-cliff figure the book carries is provenance-flagged and omitted here (ch14:161); the practice — fund review capacity up front — stands.

§7Success, failure, and stop criteria

Attach a falsifier with a date. The pattern is the fleet memo’s Recommendation 3: “Strategy without revenue is a hobby.” and “If yes, that’s the pitch deck. If no, we learn why before investing further.” (ch14:7). Name the program’s own falsifier — the receipt that would prove the whole thing is working, and the date by which its absence means it isn’t (ch14:143).

Track trends over snapshots — a single green number is noise (ch14:129).

The honest default, stated before the decision block: most organizations reading this should not run an autonomous fleet (ch14:98). A STOP on this sheet is a legitimate outcome, not a failure of the exercise.

§8Approval boundaries — before any unattended run

• Prompts are suggestions; policies are laws. Every money/send/delete/identity boundary enforced by code outside the agent’s reach (ch14:118).
• Each control layer enforced externally to the layer below: budget caps at infrastructure, spawn limits above the factory, tool permissions above the agent — an agent cannot be its own accountant (ch14:119).
• Approval gates where reversibility ends: auto-approve the undoable; mandatorily gate what survives the response (ch14:120).
• Never-automate list, by construction: agents cannot modify their own identity files, weaken their own gates, or grade their own work (ch14:121).
• Kill-switch drill: name every agent, kill one on demand, prove it stayed dead (ch14:122).
• Audit the composition as built, not as designed — the most dangerous control is correct code nothing calls; every gate verified in the live-fire path, on a schedule, by someone outside the fleet (ch14:123).
• Assume the tool layer is hostile until scanned (ch14:124).
• Two human posts that never close, at any autonomy level: a human ratifies self-modification, and a human audits the composition as built (ch14:100).

§9Evidence and release checklist — gate to first unattended dispatch

Check only with a receipt (document, date, path — “done” is not evidence).

§11Example use (synthetic — invented to show the form; not a customer, not evidence)

A platform team fills: bounded task = “triage the weekly infrastructure-audit findings”; verifier = linter + test suite + on-call acceptance; error price = “$150 per false positive paged to on-call” (their own on-call math, written as the §2 sentence). Volume they can state from the ticket system — but the single-agent baseline has never been run and no alternative’s cost is measured, so the pass/fail criterion they wrote for Gate 2 (“beat the scripted baseline on false-positive pages over a four-week window, at lower cost per finding”) cannot be scored. The sheet returns HOLD — measure the baseline and re-score, with a falsifier (“by [date], the agent closes low-severity findings with zero false-positive pages, measured against the ticket ledger”) and a stop rule attached. Every number in this example is invented to illustrate evidence-based selection; the sheet supplies no threshold — the team’s own unmet criterion, not a book figure, is what returns HOLD.