TL;DR
AI has compressed the time it takes to build a working capability. It has not changed the time it takes for an organisation to operate differently because of one. This article argues that the distance between those two speeds used to close itself, because slow build schedules did change management as a side effect, and that it now widens with every tool that arrives. It explains how the gap forms, what closes it, and where the argument breaks down.
I have lost count of the systems I have watched go live, get signed off, and then quietly stop being used. The technology worked. The demo was convincing. Six months later the spreadsheet was back, the old email thread was back, and the new capability sat there like a gym membership nobody wanted to cancel.
That pattern was common long before AI. What AI has changed is the timing. It has collapsed the distance between having an idea and having something that works. A prototype that would have occupied a project team for a quarter can now be produced in an afternoon. That is a genuine gain. It has moved the bottleneck rather than removed it, and it has moved it somewhere most organisations are not funding.
What embedding actually involves
Once a working capability exists, a set of questions becomes unavoidable, and almost none of them are technical.
Where does this sit in the workflow? At which step does someone reach for it, and at which steps should they deliberately not? What decisions can it support, and which ones still need a person to weigh the evidence and carry the consequence? What information does it depend on, and is that information reliable enough to trust with that decision? Who owns the outcome when the capability is used, and who owns it when it is bypassed? What happens to the cases that do not fit the pattern it was built for? How will anyone know whether it is performing?
These are operating questions. In my experience they are the ones that get skipped, because the build was the interesting part and the answers feel like administration. The result is a capability with no defined job. People use it when they remember, in whatever way each of them thinks best, and the business ends up carrying more variation than it had before it started.
Then the behaviour has to change
Answering the operating questions on paper is necessary. It is not sufficient, because people still have to change what they actually do on a Tuesday afternoon under pressure.
They need to understand the new way of working rather than simply be told it exists. They need to trust the capability enough to rely on it, which usually means watching it perform on real work rather than on a curated demo. They need to know what is expected of them, including what they are no longer expected to do. And they need the surrounding processes, roles and incentives to support the new way of working instead of quietly rewarding the old one.
That last condition is where most embedding efforts come apart. A service agent will keep writing responses from scratch if their manager still reviews every word and their targets still count tickets closed rather than customers satisfied. A salesperson will ignore a pipeline summary if the data underneath it was never cleaned. The old behaviour persists because it remains the rational response to a system that has not caught up with the capability placed inside it.
The work that gets underestimated
After the build, and after the behaviour change, sits a long tail of work that rarely appears in the business case. Training that amounts to more than a launch email. Testing on live work rather than sample data. Governance that states who is allowed to change what. Monitoring that shows whether outputs are drifting. Feedback routes so that problems reach someone with the authority to act. Refinement as the business learns what it actually needed. Ongoing ownership so the capability does not become orphaned when the original sponsor moves on.
None of this is glamorous, and all of it is where value is either protected or lost. A capability that is built well and owned by nobody decays on a predictable schedule. Data quality softens, exceptions become normal, workarounds reappear, and eventually someone asks why the business paid for it.
The vendors already describe this
It is worth noticing that the organisations selling the build tools describe the same shape of work. Microsoft’s current guidance for organisations deploying AI agents sets out the job as planning for business value, implementing the right foundations, driving adoption through people and process, managing agents at scale, and continuously improving outcomes. Adoption in that framing covers onboarding, training, feedback loops and change management that reshapes daily working habits. (Microsoft agents guidance hub, accessed 14 September 2026.)
Implementation, the stage most organisations think of as “the project”, is one of five. Four of the five concern what happens around the capability rather than inside it.
Having spent most of my career delivering on the Microsoft platform, I find that framing honest. It also makes the failure pattern easy to name. Most organisations fund implementation, hope for adoption, and staff neither management nor improvement at all. Then they conclude the technology did not work.
Two clock speeds
The distance between building something and operating differently because of it is widely discussed at the moment, usually under the heading of the absorption gap. What I want to add is an explanation of why it is widening now, because the common version treats it as a new problem and I think it is an old problem that used to solve itself.
Here is the position, and it is a position rather than a measured finding.
Every organisation runs at two speeds. The first is how quickly it can produce a working capability. The second is how quickly it can change how it operates so that the capability actually does something.
For most of the last twenty years those two speeds were roughly matched, and they were matched by accident. Building was slow. A twelve month implementation gave the business twelve months to argue about process, reassign responsibilities, clean data and prepare people, whether or not anyone called that work by name. The build schedule was doing change management as a side effect, and nobody had to fund it or own it, because it happened in the waiting.
Generative AI and agentic tooling have cut the first speed by something close to an order of magnitude. The second speed has not moved at all, because it is governed by how quickly humans change habits, how quickly leaders resolve ownership disputes, and how long it takes to trust information enough to act on it. Remove the waiting and you remove the change management that was hidden inside it. What used to happen by default now has to be done deliberately, and most organisations have not noticed that the default has gone.
This is why businesses that ran one system implementation every three years without obvious difficulty are now struggling with four AI initiatives a year. Nothing about their capacity to absorb change has deteriorated. The supply of things to absorb has increased, the absorption rate has stayed where it was, and the mechanism that used to disguise the problem has been removed.
What this looks like in one team
The following is a composite drawn from several engagements rather than a single client.
A mid-sized services business builds a drafting capability for its support team. Generative AI produces a first-response draft from the ticket and the customer history. It works. In testing it produces a usable draft roughly four times in five.
Then the operating questions arrive. The draft appears in the agent’s queue, so the workflow step is clear. But the agent’s quality score is still calculated on response wording, so every draft is rewritten to sound like the agent wrote it. The customer history it draws on includes twenty months of free-text notes that were never structured, so on complex accounts the draft confidently references the wrong contract. Nobody has defined which ticket categories it should not be used for. Nobody is monitoring the proportion of drafts sent unedited, so there is no signal when quality drifts.
Six weeks after launch, usage is high and time saved is close to zero. The capability works exactly as specified. The business has not changed, so the business gets nothing. Closing that gap took no further build effort at all. It took a revised quality measure, a defined exception list, a structured field for contract reference, and one named owner reviewing a weekly sample.
Where the argument stops working
The two speeds argument is not a universal law, and it has edges worth stating.
Some capability needs almost no embedding. An individual using generative AI to draft their own emails changes nothing structural and absorbs it in a day. The argument applies to capability that sits inside shared workflows and shared decisions, where multiple people and multiple systems have to agree.
The gap is also not uniform, and this is the point that complicates my own thesis. Small businesses with short decision chains sometimes absorb faster than they can build, which reverses the constraint entirely. In those organisations the advice to slow down and design the operating model first is simply wrong. They should build more, faster, and learn from live use.
Absorption is hard to measure. Usage statistics tell you a capability is being opened, not that work has changed. Most organisations do not have a credible measure of whether a decision is being made differently, which makes the argument easier to make than to quantify.
The vendor framing quoted above is guidance from a party with a commercial interest in sustained deployment. It aligns with what I see in practice, which is why I find it useful, and it should be read with that interest in view.
And there is a way of misusing all of this. “We are not ready” becomes an excuse for organisations that were never going to move. Absorption capacity is built by absorbing things. A business that waits until its workflows are perfect before it introduces capability will find that the waiting itself is the problem.
Conclusion
AI has shortened the distance between an idea and a working capability. It has left untouched the distance between a working capability and a business that operates differently because of it. That second distance is made of workflow design, decision ownership, information quality, measurement, and the willingness of leaders to hold a standard when it is inconvenient.
So the harder question for any organisation adopting AI is no longer whether it can build the thing. It almost certainly can. The harder question is whether it can redesign itself around what it has built, and keep doing so as the capability changes, the work changes and the people change. That is the deliberate, continuous building of organisational capability at the rate a business’s ambition demands, and it is the part no tool will do on your behalf.
The build is the beginning. Making the capability part of how work gets done, how decisions are made, how outcomes are owned and how the business improves over time is the actual job. It was the job before AI arrived, and AI has made it impossible to postpone.
If this describes something you recognise, the question worth asking is which part of your own operating system is currently setting your absorption rate. Contour is a capability profile for the whole organisation, built on the Business Evolution and Resilience Model and held by the Edge151 Institute. The method is published in full and free to run with your own leadership team. The instrument behind it is in development and will open as a tool you can use.
The absorption gap describes the distance between how quickly an organisation can build a working capability and how quickly it can change how it operates so that the capability produces value. The term is in general use. The argument in this article is about why the gap is widening: build speed has risen sharply, while absorption speed is governed by human and organisational factors that have not changed, and the long build schedules that used to carry change management as a side effect have gone.
They fail because the operating questions around the capability go unanswered. Where it sits in the workflow, which decisions it can support, what data it depends on, who owns the outcome, how exceptions are handled and how performance is monitored all have to be settled before behaviour changes. When they are left open, people use the capability inconsistently or not at all, and the business gets more variation rather than more value.
Embedding involves defining the capability’s place in the workflow, assigning decision rights, confirming the quality of the information it relies on, naming an owner, handling the cases that do not fit, and measuring whether it is performing. It then involves the behavioural work: training beyond a launch email, evidence that the capability performs on real work, clarity on what people are no longer expected to do, and incentives that reward the new way of working.
There is no reliable general figure, because the limiting factor is organisational rather than technical. The useful way to estimate it is to ask how long the organisation has historically taken to change a working practice that touches several roles and several systems. That timescale, not the build timescale, is what governs when value appears.
Not in most cases. The argument is about resourcing the absorption work, not about delaying the build. In organisations with short decision chains and few handoffs, absorption can run faster than build, and those businesses should build more and learn from live use. The recommendation to slow down and design the operating model first applies where capability sits inside shared workflows and shared decisions.
Usage statistics are a weak proxy, because they show a capability being opened rather than work being done differently. Better measures look at the outcome: the proportion of outputs used without rework, the time from trigger to resolved decision, the volume of cases still handled by the old route, and the rate at which exceptions are escalated. Each needs a named owner reviewing it on a defined cadence.
Data quality determines whether people trust the capability enough to rely on it. A capability that draws on unstructured or unmaintained records will be accurate most of the time and confidently wrong occasionally, which is the pattern most likely to destroy user trust permanently. Fixing the underlying information is usually cheaper than rebuilding the capability and is rarely included in the original business case.
Alastair Jupp writes on organisational capability and the practical adoption of AI. The argument here is developed at length in Workflows, Decisions, Discipline: The Operating System Behind Every High-Performing Business, published by Edge151 later this year. Details and publication updates.
Discover more from Edge151
Subscribe to get the latest posts sent to your email.