Constraint migration

AI productivity gains plateau because acceleration and improvement are different things. AI makes individual tasks faster. The organisation around the tasks, the handoffs, the review steps, the decision points, stays exactly as it was. So the limiting constraint does not disappear when a task gets faster; it moves to the next part of the system that nobody redesigned. Local productivity rises. End-to-end performance stays flat. I call the mechanism constraint migration.

In one line

The task got faster. The knot moved.

Where the idea comes from

Published evidence

The underlying observation is older than AI. Goldratt’s theory of constraints (The Goal, 1984) showed that every system has one binding constraint at a time, and that improving anything other than the constraint improves nothing. It also showed what happens when you do fix it: the constraint moves, and the work starts again somewhere else.

The AI version of that observation is now visible in the institutional data. McKinsey’s 2025 State of AI survey finds the organisations capturing value are the ones that fundamentally redesigned workflows rather than adopting tools in place, and the UK Government’s response to the AI Champions’ adoption plans (June 2026) finds that scaling adoption depends less on the model than on whether workers can interpret and act on its outputs, and that well-managed firms are far more likely to adopt at all.

What I see in practice

AI is the largest single-stage acceleration most organisations have ever applied to knowledge work, and it is being applied almost everywhere in the same shape: individual tasks get tools, the surrounding system gets nothing. The result is constraint migration at unusual speed and scale. Work that used to wait on production now waits on review. Teams that used to wait on building now wait on decisions. The waiting did not go away; it changed address.

My interpretation

The consultancy consensus says “AI requires workflow redesign”. That is true, and it is not an explanation. The mechanism underneath the consensus is constraint migration, and naming the mechanism is what makes the problem diagnosable: if you know constraints migrate, you stop asking “why didn’t AI work?” and start asking “where did the constraint go?”

Where the constraint goes

In organisational AI adoption the knot lands in one of three places, and which one tells you what kind of problem you actually have.

Verification. The most common destination. Generation gets cheap, establishing correctness does not, and the work piles up in front of the small group qualified to say “this is right”. That instance has its own name and its own page: the verification bottleneck.

Coordination. The task inside one team gets faster, and the handoffs between teams stay priced as they were. Pilots die at the joins between workflows; architectures grow layers whose real function is moving work around. Local productivity rises while cross-functional cost remains.

Decision authority. Building and analysing get cheap, so the constraint moves to whoever can say yes. An organisation that could not prioritise at the old speed of building definitely cannot prioritise at the new one, and acceleration turns a decision-rights problem into the binding constraint.

How to tell it is happening

Four questions, all checkable against real work rather than sentiment:

• Are task-level metrics improving while end-to-end cycle time stays flat?
• Where does work wait now, compared with where it waited a year ago?
• Has any workflow actually been redesigned, or have tasks been accelerated in place?
• Are your most senior people busier since AI arrived, and busier with checking rather than deciding?

If the first and last are both true, the constraint has migrated and you can usually name its new address within a day of tracing real items end to end. That tracing is also something you can do yourselves: Flowscope, my self-serve mapping tool, interviews your team and builds the value-stream map live, so the wait points surface without a consultant in the room.

When it is not constraint migration

The mechanism presumes acceleration actually happened somewhere. If the model genuinely cannot do the task, you have a capability problem. If the data the workflow runs on is wrong or inaccessible, you have a data problem. If nobody is using the tools at all, you have an adoption problem. Those are real, they are just different, and they respond to different interventions. Constraint migration is specifically the pattern where the acceleration worked and the organisation did not move with it.

The pattern library is a map of it

Every pattern in the library is this mechanism wearing different clothes. Same knot, different address:

What to do about it

Not “slow the AI down”. Slowing adoption throws away the acceleration without touching the constraint. The intervention is to redesign the small part of the system the constraint moved into: the verification step, the handoff, the decision right. Find where the knot sits now, prove the redesign on real work, embed what survives contact, and leave. That sequence is how every engagement I run is shaped.

This is also why the first useful question about any AI adoption is which level it reached: doing the work faster, changing how the work works, or doing work that wasn’t viable before. Acceleration alone, the first level, produces constraint migration by default. The second level is the redesign that resolves it.