Why Most AI Adoption Fails: Fix the Order, Not the Tool

Most companies adopt AI backwards

I'm not going to open with the usual stats. If you're a founder or a manager, you already know them, or you're three or four GenAI pilots deep and still waiting for one to stick.

We've spent over a year now running AI adoption programs, training, and hackathons with teams of every size. Every failed rollout we've seen shares the same root cause: the tool showed up before the problem did.

That order was always risky. It's worse now. The vendors building these tools have their own incentive to keep you unscoped, and the less you understand about why you're using a tool, the easier you are to bill.

The pattern that keeps failing

Mistake 1: Buy the tool, hope it sticks.

Company buys Copilot. Rolls it out. Employees don't use it because it's either not good enough for their actual work or nobody told them it exists. This was the first wave, and most companies are still living in it.

Then comes the next wave: they buy Claude. Everyone gets hyped by what they saw on LinkedIn and starts using it for, well, whatever. The bill jumps the window, and these are real cases, not thought experiments. Microsoft pulled Claude Code licenses from thousands of engineers after per-engineer costs hit $500-$2,000 a month, far past what finance had budgeted. Uber rolled the same tool out to roughly 5,000 engineers and burned through its entire $3.4 billion 2026 AI budget in four months. One unnamed enterprise client accidentally spent $500 million on Claude in a single month because nobody set a usage cap. A CTO at that company later admitted some employees were using it to check the weather.

Mistake 2: Have the tool, now hunt for a problem to give it.

This is the one that stings. The tool is live, so now it needs a job, any job, doesn't matter if there's real value behind it. Squeeze in as much context as possible, token max the thing, mostly to show off in a Slack channel or a team meeting. I heard about a manager who vibe-coded a throwaway game and burned through 87K tokens doing it. Impressive demo, zero business value.

Mistake 3: Bring in AI trainers who sell hope instead of skill.

Someone brings in trainers who sell excitement over ability. The room leaves inspired and unable to do anything differently on Monday morning. That's the loop we kept seeing before we changed our own approach: buy tool, chase demo, hire hype, repeat.

The dark pattern nobody is warning you about

This moment is different from the last decade of tool rollouts. The confusion isn't only coming from your team anymore. Some of it is coming from the vendor, by design.

Agentic tools now spin up their own sub-agents, which spin up sub-agents of their own, five layers deep, with no warning before the meter runs. Uncapped, that pattern is how one enterprise client burned $500 million in a single month without anyone setting a usage limit, and how per-engineer bills at companies like Microsoft and Uber blew past what finance had modeled.

Anthropic knows the shape of this problem better than anyone because they have the usage data. They floated a plan to move Agent SDK usage off the flat subscription pool onto tiered monthly credits, then paused it on the day it was due to take effect, after developers who'd been paying roughly 15-30x below the equivalent API cost saw what the real bill would look like. They've also reportedly scanned git commit messages for signals of third-party orchestration frameworks like OpenClaw and Hermes, then rerouted matching usage to standard API billing. That's a company managing its own cost exposure in granular detail while individual users and their employees find out the hard way.

None of this is a skill issue you can train away entirely. AI is the most flexible tool anyone has built, so how you use it decides what it costs, and a disciplined user can scope things tightly and still get burned when a tool spins up work nobody asked for. Now picture someone new to all of this: no muscle for scoping, no idea an agent can quietly call three more agents, just a subscription and a bill they didn't expect. Nobody at the vendor is stepping in to protect that person. That's not their business model.

This is exactly why the order matters more now than it did two years ago. If your team never learned to name the specific problem an AI system is solving, they have no way to notice when a tool is doing far more than the job requires, and no way to tell whether that's their mistake or the product's design. Problem-first education isn't a nice-to-have anymore. It's the only real defense your team has against being blindsided by a bill.

What we do instead

Two weeks ago, we ran a full-day hackathon in Oman. We barely mentioned Claude. Skills, plugins, agents, none of that came up. We put a tool on the screen and showed what it could do, because that's what people care about. As a mentor of mine likes to say, it doesn't matter if there's a monkey typing behind the screen. If it delivers value, people will love it and use it.

So we led with value, not vocabulary. We showed how we went from an idea to a working system without saying a word about skills, MCPs, or agents. Most of the room had never heard the word "agent" before that day. A few knew what a skill was. None of them had heard of an MCP. There was no reason to teach it.

Once the room understood one equation, they were hooked:

AI = borrowed expertise + your expertise and process. That equals time saved, which equals happier people, which equals more revenue and a better working life.

Then we proved it, live, on screen. Still no mention of skills.

They left day one curious instead of overwhelmed. We gave them a minimal setup tutorial, and the next morning everyone showed up ready. A few people even bought their own laptops for the hackathon so they wouldn't have to touch their company machine. That's a room that's locked in before you've taught them a single tool.

We spent the rest of the time using AI to drive creative thinking, helping each person map where their own expertise was needed and where AI could fill the rest. It's a creative process. By the time they ran through it with us, they'd seen proof, used the tool under our guidance, and learned without anyone forcing a lecture on them about MCPs or skills. Engineers love abstraction for its own sake. Most people don't, and they shouldn't have to.

The order we'd propose instead

Run an AI co-facilitated workshop on finding where AI is needed before you run one on tool literacy. Put your team through a design thinking process. Let them brainstorm freely, bring their own expertise and their own problems to the table, under guidance. Put a prize on it. People get excited once they see it work, not before.

Our Oman group left with feasible AI ventures they were proud of. The same format works just as well for internal ops projects: teams walk away with skills and agents they can use on their own tooling the next day, on processes they already know are broken, with gains big enough to matter now.

Nobody in that room learned a tool first. They found the gap. Then they learned only what closed it.

The takeaways

• Start with the problem worth solving, not the tool.
• Pressure-test the idea before anyone builds anything.
• Learn the one tool that closes the gap, not all of them.
• Measure P&L, not prompts.
• Know what "done" looks like before you start, so nobody on your team can be talked into paying for work nobody asked for.

Don't train first. Find the gap first, then train on the thing that closes it. It's the only rollout order that also protects your team from a vendor whose incentives don't match yours.

If this sounds like the shape of the problem you're facing, reach out. We'll walk you through the methodology, and I think it'll change how you think about your next rollout.

Full details and workshop booking: https://aibl.to