The same consultants, using the same model, improved on one set of tasks and became less accurate on another.
The same model, two opposite results
In one controlled field experiment, consultants using GPT-4 did more work, moved faster, and produced higher-quality output on tasks inside the model’s capability frontier.
Then the task changed.
On work outside that frontier, the same kind of consultants using the same system became materially less likely to reach the correct answer. One instrument. Two opposite effects.
Now answer the familiar executive question: was that organization AI-ready?
Yes would hide the failure. No would erase the gains. The contradiction is not in the people or the technology. It is in the unit of measurement. The company is too large a unit to describe what happened.
The unit has to shrink. Not to the department. To the task: the specific work the system will support, where it will run, and the people who know what a good result and an unacceptable failure look like. NIST’s risk framework starts in the same place. Define the task and method first. Measure them in their deployment context with input from domain users.
You can still see the company. You just see a spread of tasks in different states: private experiments, repeated team habits, named work, working machinery, dependable routines. Add dated evidence and you can see whether that spread is moving. What you cannot honestly say is, “We are level 3.”
What leaders should measure instead: task position, not company posture
Replace the maturity slide with a task ledger. For every important task, look for five things: a name, working machinery, a dated receipt, an exact command, and a standing trigger.
A dated receipt is not “the team likes it.” It is a result with a date beside it: value created, time removed, reliability demonstrated. A trigger is not “people know when to use it.” It is the event that causes the work to run. The five artifacts show what exists now. The task’s intended resting state says which of them should exist when the work is operating as designed.
A high-variance judgment task may be mature without becoming autonomous. A routine sweep can remain immature even when people use AI on it every day, because somebody still has to remember to start it. Maturity is not maximum automation. It is evidence that matches the way the task should operate.
Here is the internal operating model I would use. Follow one task through its artifacts. Personal means one person has a private way of doing it. Pocketed means a few people repeat it, but it still lives in local habit. Named means the task boundary is explicit enough to point to. Wired means working machinery and an exact command connect it to a workflow. Standing means a trigger causes it to run as a dependable routine. The zones are not claims about technical glamour. They record how established the task has become inside the organization.
Take invoice routing. A finance manager begins with a private prompt: personal. Two teammates copy it: pocketed. The company defines the task and its boundary: named. A callable workflow now performs it: wired. An incoming invoice starts that workflow without anyone remembering: standing.
Same task. Different evidence.
Once tasks are positioned this way, the aggregate answer becomes usable again. You can count how many important tasks are merely named, how many have machinery, how many carry dated receipts of value or reliability, how many are at rest, and whether those counts are advancing or stalling. That is a real company-level measure. It is a distribution with motion, not a badge.
Why one axis is still not enough
A standing task can still be built with too little control. A named task can be wrapped in architecture it does not need. The zone records how established the work is. It says nothing about how much control the work requires.
That is why adoption needs a second axis. Call it implementation level. L1 is assembled automation: fixed trigger, fixed sequence, basic run history, manual recovery. L2 is controlled orchestration: explicit branching and retries, persisted state, idempotency, human gates, and evidence at each step. L3 is a durable agent system: resumable state, adaptive loops, complete traces, evaluation, governed tools, and memory with provenance. These levels describe required control, not status.
A stable invoice-routing workflow may properly rest at standing/L1. A high-variance research workflow may still be only wired and already require L3 because it runs longer, changes course, and carries more consequential failure modes.
The invoice workflow is more established. The research workflow is more demanding. Those are different facts.
This rejects a common mistake. Leaders hear “deeper architecture” and assume it means a more advanced company. It may mean only that the task is harder to govern. The highest level is not the destination. The right level is.
The mechanism: value comes from workflow redesign, and risk comes from control mismatch
Giving employees a model does not redesign a workflow. It leaves the old work intact and adds a new place to type.
In McKinsey’s survey, workflow redesign had the strongest association among the practices tested with reported EBIT impact from generative AI. Yet only 21 percent of respondents using generative AI said their organizations had fundamentally redesigned at least some workflows. Many companies are asking the technology to pay off before changing the work that is supposed to produce the return.
A private prompt may be useful. It is not yet an operating capability. The zone marks the distance between the two.
A bounded customer-support workflow makes the point cleanly. In a real deployment, AI assistance increased the number of customer issues resolved per hour. Useful not because support predicts your outcome, but because it shows something narrower and more important: value can be established at the workflow level. You do not need a verdict on “the company” to know whether a particular operating task is producing gains.
Even there, the effect was not uniform. The gains were much larger among less experienced and lower-skill workers, with little to no negative effects on top performers and the most experienced workers. So availability of a tool is not the measure. Task design and user context remain live variables even after the use case is chosen. Two employees can be in the same workflow and still experience very different value from the same assistance.
Now imagine a long-running workflow fails after its fourth step. The final output is wrong. The run history says only that it completed. You cannot see the decision that bent the path, restore the state before it, or replay the failure after a fix.
That is control mismatch. The work requires replay, but the architecture retained only an answer. Work that must handle exceptions, preserve state, pause for approval, or adapt through loops cannot safely rest on a system that emits an output and forgets how it got there.
At L2, the needed discipline starts to appear: explicit branches, retries, persisted state, human gates, evidence at each step. At L3, it becomes more durable: checkpoints that preserve thread-scoped state, replay and fault recovery, complete execution traces that record model calls, tool use, and decision points. Those components are not engineering ornament. They are how consequential work becomes governable once the workflow is too variable, too long-running, or too exposed to run on faith.
Readiness is fit: the diagnostic a CEO can actually use
For every important task, ask four questions:
- What exactly is the task?
- Which zone has its evidence earned?
- What level do its variance, duration, and consequence require?
- Where should this task rest?
Readiness is the fit among those answers. Licenses prove nothing about it. Full autonomy is irrelevant when the task should never operate autonomously. What matters is whether the evidence matches the intended operation and the controls match what the task can do wrong.
Now the roadmap is visible. List every task not at rest and the exact checks it is missing: machinery, receipt, command, trigger, or control. That displacement list is the plan.
It also gives you a sequencing rule that does not pretend certainty you do not have. Start with narrow, valuable use cases. Let confidence accumulate from measured operation. Widen only when the evidence earns it. And do not treat autonomy or control placement as fixed forever; the proper placement depends on the context and can migrate as the task proves itself.
What operating discipline looks like after launch
One more correction is necessary. Readiness is not a gate you pass once. Task fit changes with deployment context, user behavior, and model behavior. Good operating practice therefore includes post-deployment monitoring, user feedback, appeal and override paths, incident response, recovery, change management. Those are not cleanup steps after the real work. They are part of running the system.
At higher-control tasks, this becomes concrete. Durable checkpoints preserve state so work can pause, resume, replay, and recover. Complete traces expose what the system actually did, step by step. Evaluation loops turn production failures into targeted datasets and offline tests, so fixes can be validated before redeployment. Monitoring stops being a vague governance word once it can preserve state, show the path, and feed improvement.
On Monday morning, remove the colored box that says the company is AI-ready. Put the task ledger in its place.
One row might say invoice routing: standing/L1, receipt current. Another might say research: wired/L3, replay missing, evaluation pending. Beside each row is a date.
Now leadership can see what exists, what the work requires, and what has not yet been earned.