The workflow that reverted by Thursday

Meta description: AI support fails when the tool, habit change, and feedback loop are treated as isolated projects instead of one system.

The rollout went well. I have read the internal metrics: adoption in launch week was strong, training completion was high, the vendor’s dashboard showed engagement. Then, a month later, I watch how the work actually happens — and it is the old workflow, unchanged, with the AI tool open in a second tab that people consult occasionally and route around constantly. The organization reports an adoption success and operates a side-car. The gap between the two is the pattern, and it repeats with a regularity I have stopped finding surprising.

A company can introduce a capable AI system, provide access to every employee, and still find that working life has changed very little. The product may be technically strong. Training sessions may have taken place. Usage may rise briefly and then fall. Nothing in that pattern requires the technology to be poor. It usually indicates that one element of a larger system was introduced without the conditions that allow people to learn and improve.

What does “embedded” mean in the rollout plan?

In the rollout plans I read, “embedded” is a deployment term: the tool is available inside the applications people already use, SSO is configured, the integration is live. Embedded describes the software’s location. It says nothing about the work. A tool can be embedded in the software and absent from the workflow — present in the tab bar, bypassed in the process. The plan measures the first meaning and assumes the second follows. In the reversions I watch, it never followed, because nobody had decided what in the work would be done differently.

Where does the old step remain the real path?

An effective AI system needs a feedback loop. When a user gets a disappointing result, something should capture the problem, help identify the cause, and support an improved attempt next time. When a user gets a good result, the organization should also be able to learn what made it effective. The loop does not have to be a complex software platform. But someone or something has to make the learning cycle possible.

The speed of feedback matters. If a person asks for help and receives it the same day or within hours, the lesson can still be connected to the task. If the answer arrives weeks later, the context has disappeared. A help desk that functions as a slow administrative queue may be formally available but practically absent.

What I observe is where the old step survives. It survives at the moments of consequence: the document that actually gets sent, the number that actually goes to the client, the decision that actually gets signed. The AI-assisted path is used for drafts, for exploration, for the low-stakes middle of the work. At the point where the work becomes real, the old step reasserts itself, because the old step is where trust, accountability, and habit all live. The new path was added alongside. Nothing was removed, and what is not removed remains the path.

Why does pressure restore the old path?

The false explanation is training: adoption slipped because training was insufficient, so schedule more training. I have watched training repeat and reversion repeat, because training was never the mechanism. Under deadline, people do what they trust. The old path is trusted — its failure modes are known, its outputs are predictable, its use is socially safe. The new path is none of these yet. Pressure does not create the reversion; it reveals it. A workflow that holds under deadline was built into the work. A workflow that evaporates under deadline was never in the work.

What pattern marks a side-car versus a workflow?

The marker I have learned to use is removal. Imagine the tool vanished tomorrow. In a side-car arrangement, the work continues with mild inconvenience — the tool was supplementary. Where the tool is genuinely in the workflow, its removal breaks something: a step cannot be completed, a throughput collapses, a queue forms. In the reverted organizations I visit, removal would change almost nothing, which tells me the rollout changed almost nothing. The usage numbers were real. They measured a hobby.

I see a role for a shared operating system for AI work. A practical standard would describe what the organization is trying to achieve, what kinds of tasks the tool is expected to support, what information can be used, what a good result looks like, and how users should respond when something fails. That framework makes feedback meaningful: a user can say the output did not meet the agreed standard, and the organization can ask whether the fault lay in the input, the process, the tool, or the standard itself.

Without the shared frame, every disappointing result is handled as an isolated event.

When the experience is bad, employees may conclude that an older method is easier. An AI assistant can also reduce friction to such an extent that users stop examining the output. Neither outcome is inevitable. Both indicate that the introduction of the tool has not been matched by a system for learning and control. A specialist or consultant can work with the same tool and produce a much better result because they bring context, judgment, and an informed way of correcting errors.

Miklos Roth

What question reveals whether the work changed?

Adoption dashboards answer the question leadership asked: are people using the tool? The dashboards cannot answer whether the work changed, because that question is not about the tool. I have noticed the companies that catch reversion early ask a different question — one about the shape of the work itself — and they ask it of the people doing the work, not of the dashboard. The dashboard was never going to confess.

The question I would ask leadership is not whether the organization has an AI tool. It is this: when a person using AI encounters a problem today, who or what helps them learn from it before they face the same problem tomorrow?

PR excerpt (80–120 words, Miklos’s own words): A company can introduce a capable AI system, provide access to every employee, and still find that working life has changed very little. An effective AI system needs a feedback loop: when a user gets a disappointing result, something should capture the problem and support an improved attempt next time. The speed of feedback matters — an answer that arrives weeks later arrives after the context has disappeared. The question is not whether the organization has an AI tool; it is who or what helps a person learn from a problem before they face the same problem tomorrow.

By Miklos Roth — AI marketing consultant, Budapest. More: his field notes.