Adoption Was Never the Hard Part

88% of companies use AI. About 5% get anything out of it. We wrote a piece with that title a few weeks ago, and everything we have published since has been a closer look at one part of the gap: how it gets measured, how it gets built, how it gets bought, how it survives a model swap, how you stay sure of any of it.

What none of those pieces gives you is the procedure. So this is the assembly: five checks, run in order, stop at the first one that fails. That failure is where your value is stuck, and the fix for it is a precondition for everything downstream, so fix it before moving on.

Each check has three parts. Run this is the action, doable this week. What good looks like is the default, with its reasoning attached. Change it if is the condition that moves the default. If your team is past the basics, the third part is yours: every default here is a starting position with its reasoning shown, and a team that knows why a number sits where it does can move it deliberately. What you should not do is delete the check.

One thing this guide will not give you is an industry benchmark for healthy adoption. We went looking months ago. The circulating thresholds (“40 to 50% daily active use is healthy, under 30% is shelfware”) trace to vendor marketing with no study behind them, and they are in our do-not-use ledger with the rest of the numbers that died on inspection. Where no sourced number exists, we say so and give you our default instead, labeled.

Check 1: Can you name the outcome?

One sentence, one workflow, one number: “This deployment exists to move [metric] in [workflow].” If nobody on the team can complete that sentence without a meeting, stop here. This is the check most companies fail, and it is why BCG found 60% seeing minimal or no material value from AI they had already bought.

Run this. Pick the one workflow where a below-median performer costs you real money: support resolution, onboarding, first-draft anything. Write the sentence for that workflow only. The evidence for concentrating rather than spreading is consistent: Stanford’s Enterprise AI Playbook found successful deployers put a business owner on a specific workflow, and BCG’s 10-20-70 rule puts 70% of the work in people and process. That rule is a consulting prescription rather than a proof, but its direction agrees with the measured sources, and 70%-in-people-and-process does not parallelize across ten pilots.

What good looks like. One workflow, one named business owner who is not the technical lead, one metric that finance would recognize. Resolutions per hour. Cycle time. First-pass yield. Not “engagement,” not seats, not messages sent.

Change it if you have already scaled one workflow to production and can show the number it moved. Then a second workflow is expansion, not dilution. The failure mode this check exists to catch is running five pilots at once with none owned; 61% of successful deployments were preceded by a failed one, and the companies that got there treated the failure as tuition on one workflow rather than spreading the tuition across five.

Check 2: Do you measure it, or do you ask people?

The reason this check exists is one experiment. METR ran a randomized controlled trial: 16 experienced developers, 246 real tasks in repositories they knew well, AI allowed on half. The developers predicted AI would make them 24% faster. They were 19% slower with it. Afterward, having lived through the slowdown, they estimated it had made them 20% faster. Perception did not just miss the truth. It pointed the wrong way.

So every self-reported adoption number in your company is suspect, including the enthusiastic ones. Especially the enthusiastic ones.

Run this. Baseline the workflow from check 1 before the tool touches it, then instrument the return path. Your outcome data mostly already exists, disconnected: it sits in the ticketing system, the CRM activity log, the QA queue. Join it to the system producing the outputs, and record what a human changed about each output, not just whether they accepted it. Acceptance tells you people clicked. Diffs tell you what was wrong. Autodesk just paid $3.6 billion to acquire exactly this kind of return-path data; your version is a join, not an acquisition.

What good looks like. A pre-AI baseline, and an eval. The eval is smaller than you think: Anthropic’s guidance is that 20 to 50 tasks drawn from real failures is a good start, and the test for whether a task is real is that two domain experts would independently reach the same pass-or-fail verdict. Track the failure rate alongside the throughput. DORA’s is the only large-scale measurement tying adoption to outcomes, and across two waves its one stable finding is that AI adoption degrades delivery stability. Throughput without the failure rate is half a measurement, and it is the half that flatters you.

Change it if your volume is low or your risk is high. Our default is to read the edit diffs weekly: below that you lose the thread of what the model is getting wrong, above it you are reacting to noise. That is our cadence, not a measured optimum. Under roughly 50 outputs a week, go monthly. In a safety-critical workflow, go daily and gate releases on the eval.

Two weeks of baseline before the tool goes in is also our default, for the same honest reason: nobody has published a sourced answer, and two weeks is the shortest window we trust to catch a weekly cycle. A seasonal business should stretch it.

Check 3: Is the model inside the work, or beside it?

A tool that produces outputs someone then carries into the real workflow by hand is a productivity boost for one person. It is not adoption. MIT NANDA’s pilot research finds the same mechanism pilots keep rediscovering: brittle workflows, no feedback loop, a tool that stays a personal productivity boost and never becomes a change to how the work gets done. That research is a non-peer-reviewed working paper we treat as the pessimistic bound, but on this mechanism the sturdier sources point the same way. The fix is structural, and cheaper than the industry assumes.

Run this. Write the fixed path. Map the workflow’s actual steps and hardcode every step you can already specify, reserving model judgment for the steps you genuinely cannot. This is the opposite of deploying an autonomous agent and hoping. The evidence is Agentless: four researchers took the agent out entirely, ran a fixed three-phase pipeline, and outscored every open-source agent framework it was measured against on SWE-bench Lite, at about 70 cents a task. OpenAI evaluated it independently and adopted it as the approach behind their own SWE-bench numbers. Structure did the work everyone attributed to agency.

What good looks like. Single-threaded writes: one component owns changes to any system of record, and a second model, if you add one, advises rather than acts. Berkeley’s catalogue of multi-agent failures and Anthropic’s own accounting of roughly 15x token cost for multi-agent systems both point the same direction. And price the run, not just the result: if a fancier architecture is better, it has to be better per dollar.

Change it if you can demonstrate, on your own eval from check 2, that added autonomy improves the outcome per dollar. That is the entire test. Berkeley’s finding was not that multi-agent systems never work; it was that the gains are often minimal while the coordination costs are certain. The burden of proof sits with the complexity.

Check 4: Does it survive a model swap?

Models drift, get deprecated, and change behavior inside a version you thought was pinned. Stanford and Berkeley measured the same model name behaving differently across releases. Vendors publish deprecation policies, and their own postmortems document quality shifting under stable APIs. If your workflow’s correctness depends on one model staying put, it is built on ground that moves.

Run this. Three moves, in order of leverage: pin model versions explicitly rather than riding “latest”; put a thin adapter between your workflow and the provider so the provider is a configuration detail; and build a golden regression set from representative prompts and, critically, from prior incidents, so a bug you already paid for cannot silently come back. The full 30/60/90 sequence is in our model-agnostic piece; the first 30 days carry most of the value.

What good looks like. The dependency that makes the ordering here real: your eval from check 2 is the instrument that makes this check passable. A team with an eval can assess a new model, tune, and upgrade in days. A team without one faces weeks of manual testing every time the ground moves, which in practice means they do not test, which means the swap happens to them rather than by them. Design for it and a model update is a Tuesday. Do not, and it is an incident.

Change it if you are genuinely single-vendor by policy, with your board’s eyes open. Then the adapter is lower priority, but the golden set is not: the drift studies are about versions within a vendor, not just across vendors. Nobody gets to skip the regression set.

Check 5: Is what you believe about it still true?

Everything above produces beliefs: this workflow is worth it, this architecture is right, this model is good enough. Every one of those was verified on a date, against a model version and a workload, and all three of those things move. We caught our own workspace confidently believing things that had stopped being true, and the fix we adopted is small enough to run anywhere.

Run this. Turn every load-bearing assertion in your internal docs into a dated claim with a re-verification command: verified on this date, check it again by doing this. The convention takes an afternoon. Rung one of this ladder comes from Van Clief and McDermott’s ICM paper, a preprint we have credited and caveated before; the extension to operational beliefs is ours.

What good looks like. Beliefs get demoted on failure, not defended. Our rule is two strikes: the first contradiction flags a belief for re-verification, the second demotes it back to a question. That two-strike threshold is our default, not a finding. Re-verify load-bearing beliefs quarterly, or immediately on any model or vendor change, whichever comes first.

Change it if your stack is stable and your beliefs are cheap to check: then check them more often, not less, because the check costs minutes. The expensive failure is the quiet one, a decision made this quarter on a number that was true last quarter. Kohavi’s base rate says about a third of well-designed changes succeed, a third do nothing, and a third make things worse, so most of what your team believed at deployment time was partly wrong on arrival, before anything even drifted. The teams that stay confident are not the ones that verify once and hard; they are the ones that re-verify on a schedule.

The order is the argument

Run them in sequence because each one is load-bearing for the next. You cannot measure an outcome you cannot name, so 1 gates 2. The eval you build in 2 is the instrument that makes 3’s per-dollar test and 4’s model swap possible. And 5 is what keeps the other four true after you stop paying attention.

One warning from the evidence, for the team whose check just failed: Staw’s escalation studies found people commit the most additional resources to a failing course of action precisely when they were personally responsible for starting it. So the person who championed the deployment must not be the person who decides at the gate whether it lives. Set the criterion before the work, and hand the kill decision to someone with no authorship in it.

Adoption was never the hard part. 88% of companies cleared that bar. These five checks are the other thing, the part the 5% did: they changed the work to fit the tool, measured what happened, and kept checking. None of it needs a bigger model. All of it needs the loop.