The demo was impressive. The vendor case studies checked out. The pilot numbers were promising enough to greenlight a broader rollout. And now, six months in, the thing is running — technically — and nobody can tell you with confidence whether it's working.
Not failed implementations in the dramatic sense. Nothing crashed. No project got cancelled. Just a persistent, uncomfortable gap between what the technology is capable of and what the organization is actually getting out of it. Usage lower than projected. The efficiency gains on the slide not showing up in the operating numbers. The people who were supposed to benefit from it quietly routing around it.
The instinct is to blame adoption. Run more training. Build a champions program. Hire a change management firm. Sometimes that's right — sometimes the rollout communication was thin and the training was an afterthought. But more often, the adoption problem is a symptom of something that happened much earlier, in a conversation that either didn't happen or didn't go deep enough.
What didn't get asked
When we deployed an enterprise agentic AI platform at a 45,000-person global BPO — NLP, LLMs, conversational AI across multiple geographies — the question driving the deployment was "What can this platform do?" That's the vendor conversation. It's also the wrong starting point.
The question we should have been asking was simpler and harder: how do we get people to actually use this? And how do we get them to build on top of it? Those aren't procurement questions. They come from sitting with the people doing the work until you understand why they do it the way they do — what they're routing around, what they've already tried, what the last improvement produced.
What we found, when we stopped asking what the platform could do and started asking where people were actually hitting walls, was a support model that had calcified around its own inefficiencies. Tickets being opened for things with documented resolutions — but the documentation lived somewhere nobody had been taught to look, and nobody had time to look anyway. The agents weren't failing. They were doing exactly what the process asked. The AI wasn't going to fix that by being more capable. It was going to fix it by being present at the moment of friction, with the right answer, before the ticket ever got opened. We eliminated 33% of support tickets. That number came from context, not capability.
The capability trap
Modern AI tooling is genuinely capable. That's part of the problem. When a platform can plausibly do fifteen things, the organization under pressure to show results picks three based on what's fastest to stand up — not what's most connected to the actual constraint on the workflow.
The Theory of Constraints has a direct answer here: the throughput of any system is limited by its bottleneck. Improve anything else and the overall output doesn't change. Applied to an AI rollout, if you're automating something adjacent to the bottleneck rather than the bottleneck itself, the operating numbers don't move. The technology worked. The problem persisted. Nobody can quite explain why.
I've watched this with document processing, with service desk automation, with predictive analytics. The output is technically accurate. The people who needed the problem solved are no better off. The thing that got automated was near the problem, not the problem itself.
Why the context step keeps getting skipped
Nobody skips it deliberately. The pressure is real: board expectations, competitive anxiety, the feeling that every quarter without a visible AI deployment is a quarter handed to someone moving faster. There's not a single organization in this environment that can afford to look like it's moving slowly on this.
The ones getting the most out of AI aren't moving faster than everyone else. They're spending longer than feels comfortable on the part that comes before the implementation.
That means mapping the actual workflow, not the documented one. It means talking to the people doing the work until you understand not just what they do but why they do it that way, what they've already tried, and what the last three improvements actually produced. It means being willing to discover that the AI use case you planned is the second or third most valuable thing you could do, and having the organizational discipline to act on that.
None of that is complicated. All of it takes longer than skipping it. When you skip it, you end up with an implementation that works and a problem that persists — and six months of post-launch effort trying to explain why adoption is soft when the real answer is that the tool was solving the wrong version of the problem.
The question worth asking before you're in it
Before any significant AI initiative, the most useful thing a CIO or operating partner can do is force a direct answer to one question: How specifically will we know, twelve months from now, whether this worked?
Not "what metrics will we track" — that's the consultant's version of the question. The real version: what will be true in the daily experience of the people this is supposed to help that isn't true today? If you can't describe that in concrete, human terms before you start, you don't have enough context yet. Go get it. The implementation will still be there when you come back.