Why enterprise AI agents fail — and what every failed run costs you.

Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Benchmark data explains why the prediction is plausible. When Carnegie Mellon researchers built a simulated software company and asked frontier AI agents to do real knowledge work, the best agent completed about 30% of tasks autonomously (updated results; the original December 2024 paper reported 24%). Salesforce found the same shape in benchmark environments built on its own platform: on CRMArena-Pro, leading agents succeeded on roughly 58% of single-turn business tasks, falling to about 35% once the work became multi-turn.

Those numbers get quoted as evidence that the models are not smart enough yet. That reading is mostly wrong, and it leads teams to wait for a better model when they should be fixing something else.

Agents fail in enterprises for two structural reasons. They can only reach part of the product they are supposed to operate. And they have none of the context that makes a human operator safe and efficient inside that product. Both problems sit outside the model. Both also show up somewhere unexpected: your inference bill.

This article works through the two failure modes, then does the cost math most agent business cases skip.

Why Do Enterprise AI Agents Fail?

Enterprise AI agents most often fail because they can only reach part of the software they need to operate, and because they lack the application context — permissions, workflow rules, state, and downstream effects — that determines whether an action is correct. Model capability compounds these problems but does not cause them: the same model that performs well on a documented, well-scoped task fails when the workflow crosses into undocumented product territory.

That is the compressed answer to why AI agents fail in production. The longer answer is worth working through, because each failure mode has a different fix.

Failure Mode 1: The Agent Can Only Touch Part of Your Product

Every route into a product reaches a different amount of it. A connector reaches the documented API. A unified API reaches a normalized slice of that. A browser agent reaches whatever the screen renders. We compared these routes in detail in our guide to AI agent integration platforms; the short version is that none of them reach the whole product.

Meanwhile, real enterprise workflows do not confine themselves to the documented surface. They run through private web APIs the vendor never published. They depend on actions that exist only as buttons in an admin screen. They traverse custom objects, tenant-specific configuration, and integrations someone built in 2019 and never wrote down. This is especially true of the older systems that run core operations, which is why we wrote separately about application maps for legacy systems.

An agent scoped to the documented surface behaves like an employee who is locked out of most of the building. When a workflow crosses from the reachable surface into the unreachable one — and multi-step enterprise workflows usually do — the agent stalls, hallucinates a step, or hands the task back. The benchmark signature of this is exactly what Salesforce observed: tolerable single-turn performance that collapses in multi-turn work, because longer workflows are more likely to cross a reach boundary.

Failure Mode 2: The Agent Has No Intrinsic Context for Your Product

A human operator who has used your CRM for two years knows things no API response contains: which fields are load-bearing, which account segment triggers a compliance review, which "delete" is reversible and which is not, and whether this system or the ERP is the source of truth for a given field.

An agent starts every run without any of that. It has to rediscover the application — its schema, its rules, its side effects — inside the run itself, through trial, error, and tool calls. Or it has to be spoon-fed context by an engineer who anticipated the exact workflow in advance. The Carnegie Mellon team saw the consequence directly: agents in TheAgentCompany handled a good portion of simple tasks but failed long-horizon work, and some resorted to faking completion when they hit walls they could not diagnose.

This is the failure mode that most surprises teams, because it looks like incompetence. It is actually amnesia. Nothing in the standard agent stack persists application understanding between runs. Each run pays the discovery cost again.

What This Is Not

It is worth being precise about what these failures are not. They are not primarily prompt problems, and a better system prompt does not create reach the agent lacks. They are not solved by a bigger context window, because the missing knowledge is not sitting in a document you forgot to include — it is embedded in the application's behavior — and they are not waiting on the next model generation, either. Model capability on long tasks is improving fast — METR measures the length of software tasks agents can complete as doubling roughly every seven months — but a more capable model locked out of half the product is still locked out.

What Agentic Work Actually Costs

Now the part of the business case that tends to be missing: what a complex agent workflow costs to run, and why the two failure modes above are also cost drivers.

Agent runs are billed in tokens, and the arithmetic is unforgiving on long tasks. Using Anthropic's published API pricing as of this writing, Claude Opus 4.8 — the workhorse frontier model — lists at $5 per million input tokens and $25 per million output tokens, and the newest top-tier models list at $10 and $50. Anthropic's own worked example prices a modest one-hour agent session — 50,000 input tokens, 15,000 output tokens, plus metered session runtime — at about $0.70 all-in.

That number looks harmless. The problem is that complex workflows are not modest, and cost does not grow linearly with task length. An agent working through a long task re-reads its accumulated context on nearly every step: the conversation so far, tool definitions, tool results, and its own reasoning. By the time a run has made dozens of tool calls over a context that has grown to a few hundred thousand tokens, each additional step is billed against that entire history.

Here is the shape of it, at Opus 4.8 list prices and stated as an illustration rather than a quote:

Prompt caching and batch discounts pull these numbers down meaningfully; retries, verification passes, and the newest model tiers push them back up. The order of magnitude is the point: a workflow that an enthusiastic team runs "per teammate, per day" at tens of dollars per run is a six-figure annual line item before anyone has checked whether the runs succeed.

Failure Is a Cost Multiplier

This is where the two halves of this article meet. Token billing is indifferent to outcomes. A run that stalls at step 40 because it hit an undocumented workflow costs the same as one that finishes. A run that spends thirty tool calls rediscovering an application's schema — knowledge the last run also discovered and then discarded — bills every one of those calls.

So the benchmark numbers translate directly into unit economics. If leading agents succeed on about a third of multi-turn enterprise tasks, then for every dollar of agent spend that produces an outcome, real money is going to exploration, retries, dead ends, and human cleanup. Teams experience this as a bill that grows faster than delivered value, which is precisely the "escalating costs, unclear business value" pattern in Gartner's cancellation prediction.

And the exposure grows with ambition. As models get more capable, teams point them at longer tasks — the task horizon is doubling roughly every seven months — and longer tasks mean more accumulated context per run. Per-token prices have generally trended down tier by tier, but per-task consumption is rising by design. Budgeting agent programs on today's short tasks understates what next year's tasks will consume.

A Diagnostic Before You Blame the Model

Before concluding that a failed agent pilot needs a better model, ask five questions:

• Reach: Can the agent take every action the workflow requires, including the ones that only exist in a UI or a private API? If not, where exactly does its reach end?
• Context: Does the agent know the workflow rules — permissions, approvals, downstream effects — or is it inferring them per run?
• Rediscovery: How many tool calls in a typical run are spent learning things about the application that a previous run already learned?
• Verification: Can you confirm an action succeeded and had the intended effect, or only that a call returned 200?
• Unit economics: What does one completed workflow cost, all-in — including failed attempts and retries — and does anyone track it?

If the answers cluster around "we don't know," the pilot did not fail on intelligence. It failed on infrastructure the model was never going to supply.

The Structural Fix: Discover the Application Once

Both failure modes, and much of the cost problem, share a root cause: application knowledge lives nowhere. Reach is limited because nobody has mapped what the product can actually do beyond its documented surface. Context is missing because schema, permissions, and workflow rules are not persisted anywhere an agent can use. Costs balloon because every run re-derives that knowledge from scratch and then throws it away.

The structural fix is to move discovery out of the run and into shared infrastructure. This is the approach Monarch takes. Once connected to an application, Monarch maps it into a Product Graph: a living, machine-readable model of the application's executable surface — APIs, undocumented endpoints, UI paths, permissions, schemas, and business logic.

That changes both failure modes at the source. Reach extends below the documented surface, because the graph includes the private endpoints and UI-only actions that connector catalogs and API docs leave out — which is how agents can act across software with incomplete or missing APIs. Context stops being rediscovered per run, because the model selects from verified actions whose permissions, preconditions, and effects are already mapped, while execution and validation stay mechanical. And when the underlying application changes, Monarch detects the drift and re-validates affected workflows before agents rely on them, instead of letting runs fail into expensive retry loops.

The cost logic follows from the mechanism. An agent choosing among verified actions does not spend fifty exploratory tool calls learning what an application is. Discovery is paid once, into the graph, and amortized across every agent and every run that uses it, rather than paid in tokens, per run, forever.

Monarch does not replace your connectors, MCP servers, or iPaaS. It supplies what those routes assume someone else has already figured out: what the application actually is, and which actions inside it can be trusted.

Talk to Monarch about mapping the applications your agents keep failing inside: start here.

FAQ

Why do AI agents fail in production?

Most production failures trace to two structural gaps: the agent cannot reach part of the workflow (private APIs, UI-only actions, undocumented flows), or it lacks application context (permissions, workflow rules, downstream effects) and acts incorrectly. Benchmarks like TheAgentCompany and CRMArena-Pro show sharp failure growth as tasks become longer and more multi-turn.

What is the failure rate of AI agents on real work?

On Carnegie Mellon's simulated-company benchmark, the best agent completed about 30% of tasks autonomously in updated results — the original December 2024 paper reported 24% for the best agent then available. On Salesforce's CRMArena-Pro, leading agents scored around 58% on single-turn business tasks and about 35% on multi-turn ones. Rates vary by task design, but the multi-turn drop-off is consistent.

How much does it cost to run an AI agent workflow?

It depends on task length and model tier. At Anthropic's published prices, a short agent session runs well under a dollar, while a long-horizon workflow that accumulates hundreds of thousands of tokens of context can reach tens of dollars per run at list prices — before retries. Caching and batching reduce this; failure and rediscovery multiply it.

Will AI agent costs go down as models get cheaper?

Per-token prices have generally fallen tier by tier, but per-task consumption is rising: more capable models get assigned longer tasks, and longer tasks re-process more accumulated context per step. The newest frontier tiers also list at higher per-token prices than their predecessors. Net task-level costs are not reliably falling.

Do better models fix agent failures?

They help with reasoning, but they do not create reach or context. A stronger model locked out of an application's undocumented surface fails in the same place, faster. That is the case made in why AI agents need an application map: target the application side of the problem, not just the model side.

What is a Product Graph?

A Product Graph is a living, machine-readable map of a software application's executable surface — its APIs, undocumented endpoints, UI paths, permissions, schemas, and business logic — that agents use to select verified actions instead of rediscovering the application on every run.