Skip to main content Skip to footer

Why AI projects fail: Antipatterns behind stalled enterprise AI programs

AI works well when individuals deploy it for their own needs. But once AI moves to the enterprise, where agents interact autonomously across processes and business units, the failure modes change.

These programs rarely stall because models underperform. The stall points trace back to how teams approach and implement AI projects. Infosys’ experience of agentic AI rollouts has revealed five recurring patterns. None is new, but teams often miss them in the rush to prove AI success.

We call them the “five antipatterns” of AI: AI fatigue, token guzzlers, AI slop, commoditization without contextualization, and the comfort trap. This article describes the architectural response to each: four through infrastructure, and the fifth through the harder work of changing how teams think.

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. 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. Without a deliberate structure for absorbing change, teams get worn down instead of being 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 chief information officer (CIO) has to answer for.

Moving from AI fatigue to AI vitality

Three structures work together to move teams from fatigue to vitality: an AI acceleration funnel, a poly-AI architecture, and an exponential engineering practice (Figure 1).

Figure 1. Acceleration funnel, poly-AI architecture, and exponential engineering

Source: Infosys

The AI acceleration funnel gives innovations a staged path. New capabilities enter a lab stage for rapid experimentation. Promising results move to an incubation stage, where they become a proven minimum viable product with defined skills and context. Survivors graduate to production at scale, backed by policies, guardrails, and evaluations. A fourth stage, evolve, feeds learnings back into the model gateway for continuous improvement. Most innovations wash out in the lab by design, which protects downstream teams from churn. A healthy funnel is judged by how much it stops.

A poly-AI architecture runs alongside the funnel. It stacks agentic UIs, skills, agent frameworks, interoperability protocols, policies, and models in layers that each evolve at their own pace. A new model or protocol does not force a rewrite of everything above it.

Exponential engineering supplies the human structure. Living labs, which are persistent and instrumented environments, give small teams safe space to test AI capabilities against real workflows and data. Exponential pods pair humans and agents in tight collaborative units. And an exponential ways-of-working discipline embeds continuous learning into daily routines.

The funnel stages the noise. The architecture absorbs change. And the engineering practice keeps teams steady enough to sustain the pace.

Start here: at your next architecture review, count how many of the last quarter’s model or framework changes reached production. A high number means the funnel is missing.

2. Token guzzlers

When Infosys rolled out agentic workloads across the workforce, bringing AI into daily work at scale, consumption grew roughly 275-fold in a single quarter and is on a modeled path to exceed a trillion monthly tokens with full adoption. The output met quality bars. But the experience exposed a cost architecture problem that matters for every enterprise at scale: agentic systems, by design, make many calls to a model in sequence. They reason, check, call tools, and check again. 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? A capability survives its first budget review when someone has asked these questions early enough.

Infosys’ own deployments bear this out. In a typical agentic pipeline, the model handling the heaviest cognitive work consumes several times more tokens than any other agent. 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.

Cost-aware architecture

A cost-aware architecture turns these principles into practice through capabilities that build on each other (Figure 2).

Figure 2. Cumulative cost reduction across four optimization layers

Source: Infosys

The foundation is a model gateway with tokenization. It provides a single control surface for all model traffic.

Intelligent task distribution and tiered model routing direct each task to the least expensive model that meets its quality threshold.

Context and prompt compression alongside multitier caching reduce costs further. Shorter prompts mean fewer tokens per call, and caching means fewer calls altogether.

The most aggressive layer combines cost-aware agent orchestration with hybrid intelligence, mixing model calls, deterministic logic, and retrieval. Teams that optimize across all layers have brought costs down to roughly one-tenth of the frontier-model baseline, as Figure 2 illustrates.

Start here: Instrument your model gateway to report per-task token cost by model tier. The first report will show where routing and caching decisions have the highest dollar impact.

3. AI slop

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

The quality risk is real and growing. Veracode tested more than 100 large language models across four languages and found that 45% of generated code samples introduced a known security flaw, with Java the worst performer at a failure rate above 70% [1]. Its spring 2026 update found that rate essentially unchanged, so the problem is not resolving as models get newer or larger [2]. GitHub’s own data points the same way: broken access control has overtaken injection as the most common vulnerability class, up 172% year over year, with AI-generated code that bypasses authentication checks among the causes [3].

Meanwhile, AI-generated code and agentic assets keep proliferating. GitHub now hosts 4.3 million AI projects, and 1.1 million public repositories lean on large language model software development kits [3]. Documented AI incidents rose 55% year over year in 2025, from 233 to 362 [4]. Volume is outpacing the checks that should govern it, and that makes this a security and governance problem as much as a quality one. In our experience, the risk concentrates where agentic assets touch external interfaces such as APIs, customer-facing workflows, and supply-chain integrations, because those are the surfaces an attacker probes first.

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

Agentic asset health and tooling

Volume gets attention, but visibility is the harder problem. Organizations generating hundreds of agentic assets, including workflows, connectors, agent configurations, and prompts, rarely have a clear picture of what they own, what overlaps, and what no one uses anymore.

Comprehensive tooling addresses this. A centralized inventory gives teams a single view of every agentic artifact across the organization. Automated quality scoring surfaces signals such as test coverage, error rates, latency, and drift from expected behavior. Root-cause tracing connects failures to the specific agent, prompt, or data source that caused them. Continuous validation runs throughout each asset’s life, not only at deployment.

Cleanup matters equally. Duplicate detection identifies redundant assets, such as two workflows doing the same job against the same data source, and recommends whether to merge, retire, or quarantine them. Usage tracking flags assets that have never been invoked or whose usage has dropped to near zero. These become natural candidates for retirement. Organizations that invest in this discipline avoid the unmanaged technical debt that plagued earlier generations of enterprise software.

Start here: Run a count of agentic assets in production today. A team that cannot produce that number within a day needs the inventory capability first.

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, sets a company apart.

That context layer does not build itself. Budget and staff it as a line item rather than an afterthought you expect the vendor’s product to absorb.

Enterprise context mesh

Figure 3. Enterprise context mesh: Runtime feedback loop

Source: Infosys

The enterprise context mesh (Figure 3) consists of five components: a trigger, an agent harness, enterprise context, a skills library, and context traces.

A trigger starts the loop. It may be a human request, a business event, a scheduled job, or another agent calling for help.

The trigger reaches an agent harness, which controls, guides, orchestrates, verifies, and learns from the task. The harness is the runtime’s decision surface, where the organization’s rules meet the model’s capabilities.

The agent harness draws on enterprise context, including the company’s taxonomy, ontologies, decision rules, patterns, benchmarks, and semantic graph. It also draws on a skills library of domain-specific capabilities tied to concrete operational areas such as accounts receivable, business-to-business operations, IT operations, or enterprise resource planning workflows. Skills refer to enterprise context at runtime. A change in the taxonomy or a new decision rule propagates automatically to every dependent skill.

Every execution leaves a context trace. Those traces record successes, failures, emerging patterns, and new learnings. They feed back into both the context store and the skills library, so the system gets sharper with each pass. Context traces also serve regulatory requirements: audit replay, lineage for explainability obligations, and deletion propagation when a regulated data source is withdrawn.

Start here: Pick one high-volume agent workflow and map where it draws on implicit knowledge that lives in people’s heads rather than a structured store. That gap is the first context to codify.

5. Comfort trap

This is the hardest antipattern to fix, and the most human. Years of doing things the same way build habits that resist change. 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 will not carry over.

We call the needed shift an exponential mindset: readiness for change that compounds rather than arrives in neat, predictable steps. Don’t rely on mandates to change your team’s minds. 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 absorb, almost always slower than the technology allows. Most programs never plan for that gap, then wonder why adoption stalls after the technology works.

One of the biggest blockers to AI return on investment: companies fail to stop doing the old things AI replaced. Those that do not push themselves to think differently will not harness or sustain the benefits.

The exponential mindset in practice

The exponential mindset rests on a straightforward division of labor. Agents handle execution. Humans supply the judgment: choosing what work matters, checking whether the output holds up, and setting the guardrails. Most teams already understand this intuitively. The harder part is translating it into engineering practice. In our experience, 10 principles help teams make the shift.

  • Context as shared infrastructure: Persistent, structured context available to agents across every phase, rather than locked in people’s heads or scattered meeting notes.
  • Machine-readable artifacts: Specs, schemas, and test plans structured for agent consumption from day one.
  • Full life cycle coverage: Agents across the entire development life cycle, covering test generation, deployment checks, and dependency management alongside code generation.
  • Continuous governance: Validation that runs inside the agent loop, not a gate review bolted on at the end.
  • Human-plus-agent pods: Small teams sharing a backlog, trading context, and catching each other’s blind spots in short iterations.
  • Fractal flow: The same design patterns at every scale, so principles shaping a single agent also shape a fleet.
  • Microiterations: Rapid, small-batch feedback loops over long planning horizons.
  • Full traceability: End-to-end lineage for every generated artifact, so the team can always walk a result back to its origin.
  • Agentic financial operations: Token and compute spending that ties to business value through transaction-level telemetry.
  • Platform-agnostic design: No single vendor or framework becomes a permanent dependency.

Together, these 10 principles offer teams a shared vocabulary for the new division of labor. Agents absorb the volume, humans supply the judgment, and the principles mark where one responsibility ends and the other begins.

Start here: Identify one workflow where agents already generate volume and ask whether a human-plus-agent pod with continuous governance would catch quality problems earlier than the current gate review.

What CIOs need to fund

These five antipatterns interconnect, and so do their solutions. The acceleration funnel, cost-aware architecture, asset health discipline, enterprise context mesh, and exponential mindset form layers of one operating model for enterprise AI.

CIOs who fund only pilots will keep producing pilots. Sustained enterprise AI requires funding the infrastructure underneath: the model gateway and metering that make cost visible, the asset inventory and health scoring that keep quality honest, the context store that makes commodity AI specific, and the engineering practice that keeps teams steady through compounding change. The acceleration funnel is a process discipline rather than an infrastructure investment. It organizes the work these four layers do.

Two of these four deserve priority because they compound. The first is the context store, which codifies the implicit business knowledge that makes AI specific to the enterprise. The second is the engineering practice, which builds team structures, governance habits, and feedback loops that let an organization absorb compounding change without burning out. The model gateway and the asset inventory are necessary, and their value is largely linear. Context and engineering practice are the layers whose returns grow over time.

The shift is from “fund the next pilot” to “fund the operating model.” The five solutions described in the article are what that operating model looks like in practice.

References