Chapter 26 — A 90-Day Adoption Plan

Ninety days does not buy Level 3. It buys the evidence with which to decide whether to fund it.

26.1 What a plan must earn

Ninety-day plans are the sixth-easiest thing in this book to write badly. So, as with Chapters 12, 14, 15, 17, and 21: the standard first.

1. Every gate is falsifiable. Not "the team feels more confident" but an artefact someone can go and look at. Chapter 15's maturity levels each had an artefact test; the gates here are the same instrument applied to a timeline.

2. Sequenced by dependency, not by comfort. The order must be forced. If steps could be permuted without consequence, it is a checklist with dates attached.

3. It says what to stop. Every plan lists additions. The subtractions are what actually free the capacity to do the additions, and Chapter 3 established that capacity is the binding constraint.

4. It does not consume the constraint. A plan that requires substantial review time to execute is competing with the thing it is trying to fix. This rules out most of what a consultancy would propose.

5. It survives the organisation not caring. This is the test most plans fail by assuming it away. Chapter 16 §16.2 showed the harness is a public good — no stream-aligned team will fund it against feature work and none should be asked to. So a plan whose first step requires central funding will not take its first step. The plan must reach value before it needs a budget.

Test 5 turns out to determine the entire ordering, and pleasantly, it does not conflict with test 2.

26.2 Not a context file

This book's own outline proposed starting with baseline measurement and a single context file. Chapter 15 makes that wrong, and correcting it is the most consequential decision in the chapter.

§15.5 argued that the conventional maturity ladder is sorted by cost of adoption rather than dependency: a hook that runs a type checker on every agent edit depends on an agent loop and a type checker, and does not consult AGENTS.md. The dependency does not exist. Which yields the conclusion that Level 1 is "the only level a single team can fully fund and fully capture" and also the only level that unlocks nothing.

So a context file is a fine thing to have and a bad thing to start with. It is the most visible move, the cheapest, the one that produces an artefact in a pull request — and it leaves you exactly where you were.

The first move is Chapter 15's questions 3 and 4: one blocking check inside the agent's edit cycle, and a trace store. Everything else in ninety days is downstream of those two.

Chapter 25 supplies the confirmation. Stripe describes sub-second blocking pre-push hooks as "the single biggest cost reducer at agent scale" [D], and Chapter 7 derived the same conclusion from a benchmark ablation two years earlier.

26.3 Days 1–30: instrument before you intervene

Why measurement first. Chapter 18 established that self-report is invalid as an instrument — METR's cohort was 19% slower and estimated 20% faster after living through it, and the general overestimation runs around forty percentage points [A]/[B]. If you change your practice before baselining, you will never know whether it worked, because the only remaining instrument is the one that does not work.

Four of Chapter 14's five starter metrics are computable from data you already have.

The fifth, time-to-control, needs failure-mode labels, which Chapter 14 conceded is the hard part. Measure it by hand on a sample of twenty incidents. A hand-computed median is enormously more informative than nothing.

Then two installations.

Trace capture. Chapter 15 §15.6 identified this as the prerequisite no maturity model lists: the outer loop's only inputs are the inner loop's artefacts, so Level 3 is unreachable without it regardless of how many controls exist. It prevents no defect on its own, which is why it loses every prioritisation argument — and why it goes first, before anyone has to argue for it. Traces not captured are gone.

One blocking check. The fastest deterministic check you have — format, syntax, types, in that order of speed — wired into the agent's edit cycle so that a failing edit is refused rather than reported. Chapter 7 §7.4's placement hierarchy: value falls sharply as you move from blocking to in-loop to out-of-loop, because each step spends more of the constraint.

26.4 Days 31–60: make one class of work verifiable

Now the highest-value component, and Chapter 24 §24.4 showed it is also among the cheapest to retrofit because it touches no existing code.

A held-out acceptance set, for one class of work. Chapter 8 §8.8's partition: acceptance criteria authored by a human, before generation, never shown to the agent, run only at the merge gate. The agent may write and iterate against its own in-loop tests indefinitely; only the held-out set licenses a merge.

This is the only mechanism in the book that addresses Chapter 8's Figure 8.5 — code and tests descending from one model of intent prove consistency, not correctness. Pick one class of work. Three human-written assertions are categorically different from none.

Run the first drill. Chapter 8 §8.9: deliberately produce the failure the blocking check exists to prevent, and verify it fires. Three outcomes, all actionable. The one people do not expect is the third — if you cannot produce the failure even with the control disabled, the deficit has closed and the control is retireable.

Drills cost agent time and almost no human time, which matters under test 4.

Score two or three classes of work. Chapter 13 §13.5's instrument: six harnessability questions summed, six blast-radius questions taking the maximum. Read the ceiling off Figure 13.2. Most teams discover they are simultaneously above ceiling on their severe-blast-radius work and far below it on trivial work — which is the reallocation the instrument exists to surface.

Then enforce one ceiling by capability. Chapter 13 §13.3: an autonomy level enforced by instruction is not an autonomy level; it is a hope with a number attached. Pick the class with the highest blast radius and remove a capability — merge permission, a credential in the environment, network egress. One revocation, actually implemented.

   GATE, DAY 60

   ▸ Is there a class of work with human-written
     acceptance criteria the agent has never seen?   yes / no
   ▸ Did a drill produce evidence a control fired?   yes / no
   ▸ Is one autonomy ceiling enforced by a REVOKED
     CAPABILITY rather than by an instruction?       yes / no

26.5 Days 61–90: close the outer loop once

The first two stages built the inner loop and the instruments. This stage runs the outer loop a single time, end to end, which is the thing that distinguishes Level 2 from Level 3.

Detect one recurrence and install a control for it. Chapter 8 §8.1's trigger is "whenever an issue happens multiple times." You now have traces, so recurrence is visible. Find one failure mode that has occurred at least twice, and install the cheapest deterministic control that detects it — Chapter 8's ordering rule.

Record, on the control: the date, the named failure mode, and a retirement criterion. Chapter 12's fourth prohibition, and the thing whose absence Chapter 21 identified as the early warning for Harness Theatre.

Retire one control. This is the step everyone skips and it is Chapter 15's Level 3 artefact test: a control that was removed, with a reason. Chapter 8 §8.2 showed a loop that only adds terminates in theatre, and Chapter 15 called the deleted control the rarest artefact in the entire maturity model. Use a drill to find one: disable a control, attempt its failure, and if the failure can no longer be produced, remove it.

Name a harness owner. Chapter 16 §16.3: accountable for harness coverage against drills, the retirement arm, the autonomy policy and its review date. Not accountable for individual diffs. This is the first step in the plan that requires a manager to allocate a fraction of a role, and it is deliberately last.

Run the crossing scan. Chapter 23 §23.5 showed all four crossing signals are mechanically detectable from artefacts you already have — a dependency-graph query, git log, secret scanning, a config scan. It is cheap, it runs unattended, and it will find artefacts nobody knew were in production. Chapter 23 §23.6 gives the five-step response, including the option most discussions omit: retire is frequently the correct answer.

   GATE, DAY 90 — this is Chapter 15's L3 test

   ▸ Can you point to a control installed in response
     to a RECURRENCE, with the prior incidents named?   yes / no
   ▸ Can you point to a control you REMOVED,
     with a stated reason?                              yes / no
   ▸ Does someone's job description contain the
     harness?                                           yes / no

26.6 What to stop

More important than the additions, because these free the capacity that pays for them.

The first two are the ones that will be resisted, and they are the ones that matter most. An organisation that keeps a throughput mandate running while executing this plan is applying Chapter 3's valve 2 and valve 3 — reviewing less and batching more — with better instrumentation to watch it happen.

26.7 The seductive substitute

The plan will be attacked by the same force that produced the field's distribution, and it is worth naming in advance.

Chapter 7 §7.7 identified a cost gradient operating on harness authors: markdown costs an afternoon; a wired check costs a quarter and an owner. Both are "harness work"; one produces a visible artefact immediately. Chapter 16 §16.2 added the economic layer.

That gradient will act on this plan, at every gate, offering a cheaper and more visible substitute for the thing the gate actually requires.

This is why the gates are phrased as artefact tests with a yes/no. "We improved our documentation" passes no gate here. "A drill produced evidence this control fired" either happened or did not.

26.8 What ninety days cannot buy

The honest close, and it changes what the plan is for.

It does not buy Level 3. Chapter 15 priced L3 as a standing role — someone who owns the harness, runs drills, and decides what to retire. That is a rhythm, not a project. Ninety days lets you traverse the outer loop once, which demonstrates the loop is possible in your organisation. It does not establish it.

And Chapter 15 §15.7 warned specifically: "L3 funded as a project decays back to L2 with a larger pile of controls than it started with." A ninety-day programme that ends without a funding decision produces exactly that.

So the plan's output is not a capability. It is evidence with which to make a funding argument — which is the argument Chapter 16 said must be made centrally, because the harness is a public good and no stream team will fund it.

By day 90 you have what that argument requires: a baseline and a re-measurement on four metrics; demonstrated blocking sensors with drill evidence; one class of work with real acceptance criteria; one traversal of the steering loop with a control installed and a control retired; and a crossing scan telling you what is already in production unowned.

And one adjustment by starting position, from Chapter 24 §24.8. This plan is written for the common case — low harnessability, whatever the age of the code. If your H-score is already high, days 1–60 will be faster and the constraint is organisational rather than technical, so start at §26.5 and at Chapter 16. If your codebase is new and low-scoring — Chapter 24's top-left quadrant, the one nobody warns about — add types now, because Figure 24.3 showed the window for cheap banking closes while it still feels unnecessary.

Finally, the six-item table from Chapter 23 §23.7 explains why this plan treats things together that look separate. Trace capture, drift detection, drills, retirement, crossing scans, and harness ownership are not six initiatives. They are six instances of work with no triggering event, and the remedy for that category is singular: a standing mandate, a named owner, and funding that does not compete with delivery. Day 61's harness owner and the crossing scan's schedule are that remedy, applied once, so that on day 91 there is something to point at.