Nobody Budgets for the Handoff That Kills AI Adoption

A pilot and an adopted workflow can look identical from the outside. Both run. Both produce output people are satisfied with. Someone can point at either one and say the AI thing is working, and be telling the truth.

The difference sits somewhere less visible: whether normal operation still depends on the person who built it. While the builder is around, that dependency is invisible and free. It becomes visible later — when they are on another project, on leave, or gone — and by then the discovery is expensive.

Which questions count

The evidence is already in your messages, but it needs reading carefully, because not every question to the builder means something failed.

A genuinely new edge case, a real defect, a request for something outside what the workflow was built to do: these arrive in healthy systems and will keep arriving. They are work.

What signals a transfer gap is the recurring operating question — something a person needs answered in order to run the workflow the way it normally runs. Which file do I start from. What do I do when it comes back empty. Does this go out, or does someone check it first.

Those should be answerable from inside the workflow, or by whoever owns it. When they reach the builder instead, and keep reaching the builder, they name a piece of operating knowledge that stayed with him.

The useful part is that different recurring questions point to different transfer gaps, and each gap has someone responsible for closing it. That is what the rest of this article works through.

A workflow that runs and has not transferred

What follows is a composite, written for this article. No real company.

A support team added an AI step to first-response drafting. An operations analyst built it: ticket intake feeds a model, the model drafts a reply in the customer’s language, and an agent reviews it before sending.

It works. The drafts are good, the team likes it, and first responses go out sooner than they used to.

It has also not been handed over, and three things show that.

The first is a question that keeps coming back. For one category of ticket the draft returns empty, and each time it happens someone asks the analyst what to do. He answers. The answer exists only in his head, so the next person asks again.

The second is that the workflow has no place in anyone’s routine. It runs because agents happen to open it. On a busy afternoon some of them skip it, and the gap surfaces later, in the numbers, when the moment has passed.

The third is that the old macro library is still in routine use for the same ticket types. Not as a fallback for an outage — as a parallel path some agents simply prefer. Two processes are doing the same work every day.

Each of those is a specific thing that stayed where it was. Calling it resistance would name the wrong problem, and send you to persuade people when the work is to finish a transfer.

What each side owes

The builder owes operating knowledge, where the work happens

This is narrower than documenting everything. The test is only this: whatever a person needs in order to run the normal cycle should be answerable without him.

So the behaviour of the cases the operator will actually meet — the empty draft, the language the model handles badly, the input that arrives malformed — belongs where the work is done, rather than in a file that lives beside the project.

The empty-draft answer in the example is a single sentence. It stayed unwritten because answering the question felt easier than making the answer part of the workflow. That is how a transfer gap can persist without anyone explicitly deciding to preserve it.

Management owes the workflow a place in the routine

A workflow that runs only when somebody remembers it has not yet become part of normal operation. Management has to establish the moment it runs, what the operator is responsible for producing, and where an exception goes when one arrives.

That last part is worth separating from a question it resembles. Which decisions belong to a person and which belong to the system is a design question settled earlier. The handover question is narrower: does the person now operating the workflow know what that design requires of them?

Management owes the retirement of the parallel path

This is the one that gets skipped, because it is the only one that requires taking something away.

Adoption means the previous way is no longer being run in parallel as the normal path. A documented fallback can stay: rollback, a manual route for an outage, a procedure for the exception the system was not built for. Those do not make the new workflow a pilot. What does is two processes routinely doing the same work, with people choosing between them by preference.

Retiring the parallel path is what makes the handover consequential. Until that happens, the organisation can keep avoiding the gaps in the new workflow by falling back to the familiar one. Once normal work has one primary path, the missing pieces become visible and have to be resolved.

The Adoption Check

Three conditions. They fail in different ways, and each failure points at a different piece of unfinished handover.

• Operating knowledge. A normal operating cycle completes without the builder answering a routine operating question or stepping in to keep it moving. Fixed by the builder, in the documentation or in the design itself.
• Routine ownership. The workflow has a named place in a named person’s routine: they know when it runs, what they are responsible for, and what requires escalation. Fixed by management.
• Predecessor retired from normal use. The previous process is no longer the routine parallel path, and any fallback that remains is explicitly a fallback. Fixed by management.

A workflow can pass one and fail another. The example above fails all three, and each failure tells you which part of the handover remains unfinished and who is responsible for closing it.

Agents change the amount of work that can proceed without a person touching every step; they do not change the handover principle. Operating knowledge still has to leave the builder, the workflow still needs a place in someone’s routine, and the previous process still has to stop functioning as the normal parallel path.

Take one workflow you believe is in use and put the three conditions to it. If it fails, do not begin by calling the problem resistance. Name the transfer that is still missing: operating knowledge, routine ownership, or retirement of the parallel path. Each one gives you something concrete to fix and someone responsible for fixing it.

Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment.