Your AI rollout stalled. It's probably not a training problem.

The pattern is consistent enough to describe from memory. The rollout launches with real energy: licenses for everyone, a kickoff, a training session, a channel for sharing wins. Weeks one and two look promising. By month three the channel is quiet, a handful of people still use the tool for drafts, and at renewal time the honest summary is: nobody uses it, and nobody can say what changed.

Ask the people who stopped, and the answers rhyme. It doesn’t understand the context of what I’m doing. I had to explain everything from scratch, every time. The answer sounded right and was wrong in the ways that matter here. None of those are complaints about the model’s intelligence. They are complaints about what the model was given — which, in most rollouts, was nothing: no decisions, no exceptions, no record of how the work moves. A capable tool with no knowledge of the business behaves exactly like this.

So the quiet channel is not evidence that your people resist change. It is evidence that they ran a fair test. The tool answered like a stranger, and they stopped asking.

Because training addresses the half of the exchange that was already working. A workshop improves how people ask: better phrasing, better follow-ups, better habits. It cannot change what the tool knows when the question arrives. If the tool has no access to your pricing history, your client exceptions, or your definition of finished work, a better-phrased question produces a better-phrased generic answer.

This is why second and third training rounds show diminishing returns in stalled rollouts. The first workshop captured whatever gains better asking could produce. The gap that remains is a knowledge gap, and no amount of prompting technique closes it — a distinction covered in plain terms in context engineering.

The observation this page rests on: a stalled rollout is usually a context problem, not a training problem. Public advice on stalled rollouts names change management, executive sponsorship, and skills. Missing written context — the actual raw material the tool reads — rarely makes the list. It should usually be first.

Three kinds of written material separate a tool that answers like a stranger from one that answers like a colleague:

• The decisions. What the business already chose and why: pricing calls, scope boundaries, tools, positions. Without these, the tool re-opens settled questions and contradicts standing policy with a straight face.
• The exceptions. The client on legacy terms, the process step skipped for one product line, the rule that bends on referrals. Exceptions are where generic answers do real damage, because they are the part no model could guess.
• How things get done. Who approves what, what a finished deliverable looks like, what never goes out the door. This is the file that turns a draft generator into something that produces work you can send.

Almost every stalled rollout shipped without all three. Not from negligence — this knowledge lives in the heads of your most experienced people and has never needed writing down before. AI tools are the first reader that requires it. Why the tools cannot simply remember what people tell them is its own mechanism, covered in why AI forgets.

Map it. The Working Intelligence Audit is a bounded diagnostic with a fixed price ($397 to $997, depending on how much of it you want run for you). Over roughly thirty days it locates where your operating knowledge actually lives, what people re-explain most often, and which workflow would change first if the tool could finally read the business.

The deliverable is the map itself: which files exist, which are missing, and which single process to reconnect first. You keep the map either way — whether you fix the rollout in-house, hire someone, or decide the licenses genuinely are not worth renewing. A stalled rollout is a finding, not a verdict. The verdict comes after the tool has been given a fair chance to know what it is talking about.