The five antipatterns behind stalled enterprise AI programs

1. AI fatigue

The last few years have felt like chasing a finish line that keeps moving. There’s a new model this quarter, a new framework next, always some fresh claim that this time will be different. The instinct is to run faster to keep up.

AI isn’t going to slow down, so trying to outrun it is a losing strategy. What organizations need instead is a filter — a clear way to separate what’s real from the noise and spot what helps the business. That’s what gives teams a steady rhythm for taking in change, so they choose what to adopt instead of reacting to whatever ships next.

A new wave of AI needs the right architecture, testing discipline, and scaling infrastructure behind it — without those, teams get worn down instead of built up. Tired teams lose momentum, and early adoption doesn’t survive without it. Left unaddressed, this stops being a problem the team can absorb and becomes one the CIO has to answer for.

The antidote is a set rhythm for testing new capabilities and filtering out what doesn’t matter before spending resources on it. Pace the adoption too, so teams build confidence instead of burning out.

2. Token guzzlers

One enterprise’s token consumption grew 275 times in a single quarter after it rolled out agentic AI workforce-wide, on a path that could push monthly consumption past a trillion tokens. The answers the system produced were usually fine. The problem was cost: agentic systems, by design, make many calls to a model in sequence — reasoning, checking, calling tools, checking again — and each call adds up.

When architecture isn’t built with cost in mind from the start, those costs compound quietly. A pilot that looked promising in a demo turns out to be financially unworkable at scale. It lands back on the CIO’s desk as a cost overrun, not a technology failure.

At the architecture stage, start with the boring questions. How many model calls does a task need? Could a cached answer or a smaller model handle it instead? What do the unit economics look like once volume scales tenfold? Whether a capability survives its first budget review usually comes down to whether someone asked these early enough.

The numbers bear this out. The model handling the heaviest cognitive work can burn through well over 100 million tokens a month — several times more than any other agent in the pipeline. That’s a routing problem more than a capability problem. Model routing alone can roughly halve per-token cost. Add prompt and context tuning, and aggressive optimization can bring costs down to a tenth of the frontier-model baseline. Getting there takes disciplined routing, context compression, tiered caching, and cost treated as a design constraint from the start.

3. AI slop

Not everything an AI system produces is worth keeping. A lot of it is just excess — more drafts than anyone asked for. Some of it sounds right and isn’t: plausible on the surface, wrong underneath. And some is only loosely connected to the task, generated simply because the system could. None of it saves a reviewer time — most of it costs time, clogging a workflow that was supposed to move faster.

AI-generated code and agentic assets are proliferating rapidly, and much of it is unchecked, low-quality output. GitHub Octoverse 2025, the AI Incident Database and the Stanford HAI Report 2026 put a number on it: GitHub now hosts 4.3 million AI projects, and 1.1 million public repositories lean on large language model software development kits. Meanwhile, documented AI incidents rose 55%, which makes this a security and governance problem too.

Ten mediocre drafts a day don’t add up to more than one good draft a week, even though most workflows quietly reward volume anyway. Quality filters — review gates, confidence thresholds, sampling-based human review — only work when someone actively enforces them as a rule, day to day.

4. Commoditization without contextualization

AI vendors are moving fast to package capabilities into products, and that speed helps — it lowers the barrier to adoption and lets enterprises get started without building everything from scratch.

But it also shifts the burden. Once a capability becomes a commodity, making it useful is the enterprise’s job.

Commoditize a capability, and every competitor has access to roughly the same underlying technology. What’s left to compete on is how well a company applies its own data, workflows, and institutional knowledge on top of it. The context layer, not the model underneath it, is what sets a company apart.

Doing it right means building that context layer as a loop that updates itself continuously.

Something triggers it — a person, an event, a schedule, or an automated signal — and the request runs through an agent runtime that manages the task, checks the result, and learns from what happens. That agent runtime draws on two things: a context store holding the company’s taxonomy, patterns, and decision rules, and a set of skills tied to specific jobs. Every run leaves a trace of what worked and what didn’t, and that trace feeds back into both the store and the skills. Run it enough times, and the system gets sharper.

Tailoring context to a business takes real effort, and most organizations underestimate how much. It means curating context, mapping it to the right tasks, and activating it inside the workflow. Someone has to own this: context over commodity needs to be a budgeted, staffed line item. The vendor’s product won’t absorb a company’s specific situation on its own.

5. Comfort trap

This is the hardest antipattern to fix, and the most human one. Years of doing things one way build habits that are genuinely hard to break. The new way asks people to sit with more ambiguity, move faster than feels natural, and accept that some of what they’re good at simply won’t carry over.

We call the needed shift an “exponential mindset”: being ready for change that compounds instead of arriving in neat, predictable steps. Don’t rely on mandates to change your team’s minds. Make sure you listen to them, even when the ask is hard and the answer you have isn’t the one people wanted.

Change management for AI adoption runs on a different clock than the technology does — it moves at the speed people can actually absorb, almost always slower than the technology allows. Most programs never plan for that gap, then wonder why adoption stalls even after the technology works.

Perhaps one of the biggest blockers to AI achieving return on investment is that companies fail to stop doing the old things that AI replaced. This is again about moving out of the comfort trap. Those that don’t push themselves to think differently will not be able to harness and sustain the benefits of AI.

What CIOs need to fund instead

These five patterns are not separate problems. And they are not a one-off fix. They need to be managed throughout the entire life cycle of an AI program, from development to deployment and its run phase. This requires strong governance and a cultural mindset shift.

But there are two foundational changes that help support this journey. First is to avoid the temptation of thinking AI is a one size fits all. The strength of this new exciting technology is that it can be molded to fit the context and working patterns of each of your stakeholders and processes. Losing that loses most of its value.

Second is to enable your teams to easily codify and share their implicit and tacit business knowledge into readable AI forms. Without the insights within this knowledge, AI agents can never fully support employees in doing their best work. Cracking this issue has always been one of the biggest challenges faced by CIOs, but now that challenge is at the scale and speed of AI.

Making this all work requires CIOs to fund the less visible parts of an AI program. The discipline, the tool architecture and selection, the project context, and the overall pacing across your teams. This means shifting from a “fund the next pilot” mindset to a “build sustainable resilience” discipline.