On this page · 9 sections
Summary. Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027, blaming escalating costs, unclear business value and inadequate risk controls. MIT's Project NANDA studied $30–40 billion of enterprise spend and found 95% of generative AI pilots delivered no measurable profit-and-loss impact through 2025. Yet the same research shows a working minority: buying from specialised vendors succeeded about 67% of the time, roughly three times the rate of internal builds. The gap is not model quality. It is scoping, ownership and evaluation. This guide breaks down why agents die in the pilot stage and gives you the checklist that moves one to production.
The pilot graveyard, in numbers
The agent hype cycle has met its bill. In its June 2025 forecast, Gartner predicted that more than 40% of agentic AI projects will be scrapped by the end of 2027. A January 2025 Gartner poll of 3,412 people found only 19% had made a significant investment in agentic AI, 42% a conservative one, 8% none, and 31% were still waiting to see. Most of what exists today is a proof of concept, not a shipped system.
"Most agentic AI projects right now are early stage experiments or proof of concepts that are mostly driven by hype and are often misapplied," said Anushree Verma, Senior Director Analyst at Gartner. That sentence explains most cancellations. Teams build a demo that dazzles in a sandbox, then discover that the cost, latency and failure modes make it unshippable.
The academic read is harsher. MIT's Project NANDA report, State of AI in Business 2025, drew on 52 executive interviews, 153 leader surveys and 300 public deployments. Its headline: 95% of generative AI pilots produced no measurable P&L impact. The 5% that worked shared a pattern. They targeted a narrow back-office workflow, they measured a real number, and they more often bought a specialised tool than built one from scratch.
None of this says agents do not work. Gartner also expects 15% of day-to-day work decisions to be made autonomously by 2028, up from 0% in 2024, and 33% of enterprise software to include agentic AI by 2028, up from under 1%. The technology is arriving. The failure rate is a scoping problem, and scoping is something you control.
Why agents die between demo and production
A pilot proves an agent can do a task once, under supervision, on clean inputs. Production asks whether it can do the task ten thousand times, unattended, on messy inputs, inside a budget, without leaking data or taking an action no one authorised. Those are different bars. Most projects never write the second one down.
Four patterns account for most stalls. First, no measurable success criterion: the team cannot say what "good" means, so it cannot prove value and the budget gets pulled. Second, scope creep: an agent asked to "handle support" instead of "issue refunds under ₹5,000 with a confirmed order ID" has an unbounded action space no one can test. Third, no evaluation harness: the agent regresses silently when a prompt, model or tool changes, and nobody notices until a customer does. Fourth, ungoverned tool access: the agent can call systems it should never touch, so security blocks the launch.
| Dimension | Typical pilot | Production bar |
|---|---|---|
| Success metric | "It looks impressive" | One number with a target and a kill threshold |
| Scope | "Handle customer support" | One workflow, bounded tools, defined refusal cases |
| Evaluation | Manual spot checks | Automated evals in CI/CD, run on every change |
| Tool access | Broad API keys for convenience | Least-privilege scopes, human approval for risky actions |
| Cost | Ignored during the demo | Tracked per task, with a ceiling per run |
| Ownership | A data scientist's side project | A named owner with an on-call rotation |
The through-line is that a pilot optimises for a wowing demo and production optimises for a boring, repeatable, cheap outcome. Getting from one to the other is an engineering discipline, not a bigger model. For the deeper failure mode where agents break quietly after a change, our note on agent evaluations in CI/CD shows how to catch regressions before users do.
The scoping checklist that reaches production
This is the sequence we run before writing agent code. Each step kills bad projects early, when killing them is cheap.
1. Write the outcome and the kill metric first
Name one business outcome the agent must move and the number that measures it: deflection rate, hours saved per week, cost per resolved ticket. Set a target and a kill threshold. If the agent cannot beat the threshold in a bounded trial, you stop. This single step answers the "unclear business value" that Gartner blames for cancellations, and it forces a conversation with the budget owner before any GPU is rented.
2. Shrink the scope to one workflow
Pick the narrowest useful task, not the broadest impressive one. "Draft a first-response email for billing questions" beats "run billing." A narrow scope has a testable action space and a clear refusal set: the list of things the agent must hand to a human. The MIT finding that back-office automation delivered the biggest returns is a scoping lesson in disguise. Narrow, unglamorous, measurable tasks ship.
3. Build the evaluation harness before the agent
Write a graded test set of real cases, including the awkward ones, and wire it into continuous integration so every prompt, model or tool change is scored automatically. Agents fail silently: a model upgrade that helps 95 cases can quietly break five. Without evals you learn this from an angry customer. With them you learn it from a red build.
A useful test set has four kinds of case. Happy-path examples confirm the agent does the common task correctly. Edge cases cover the rare-but-real inputs that break naive prompts: empty fields, mixed languages, contradictory instructions. Adversarial cases probe for prompt injection and out-of-scope requests the agent must refuse. And regression cases capture every past failure, so a bug fixed once stays fixed. Score each on task success, cost per run and latency, and fail the build if any metric crosses its threshold. Twenty well-chosen cases scored on every commit catch more production defects than a thousand ad-hoc manual checks, because they run the same way every time.
4. Give least-privilege tool access and guardrails
Grant the agent the smallest set of tool scopes it needs, require human approval for irreversible actions, and validate every tool call. Prompt injection turns an over-privileged agent into a liability, which is why unbounded tool access is where security teams block launches. Our guide to prompt-injection guardrails covers the controls that keep a tool-using agent inside its lane, and the wider agent governance layers piece maps who signs off on what.
5. Model the unit economics, then decide build versus buy
Estimate tokens per task, multiply by volume, add retries, and set a hard cost ceiling per run. If the maths does not clear the value from step 1, the project should not exist. MIT's data is blunt here: buying a specialised tool worked about 67% of the time versus roughly a third for internal builds. Sometimes the disciplined answer is to buy. Our build vs buy analysis for support agents walks the cost model for the most common first use case.
6. Assign a named owner and a rollout ladder
Production systems need an owner and an on-call rotation, not a data scientist's 20% time. Then climb a rollout ladder: shadow mode (the agent proposes, a human acts, you compare), human-in-the-loop (the agent acts, a human approves), and supervised autonomy (the agent acts within limits, humans audit samples). Each rung has its own eval bar. You only promote when the numbers earn it.
| Failure cause (per Gartner and MIT) | What it looks like in the pilot | The scoping fix |
|---|---|---|
| Unclear business value | No agreed metric; demo-driven | Outcome plus kill metric defined first |
| Escalating cost | Token spend ignored until the bill | Cost per task modelled, ceiling enforced |
| Inadequate risk controls | Broad tool access, no approvals | Least-privilege scopes, human sign-off |
| Silent regression | Manual spot checks only | Automated evals in CI/CD |
| Unbounded scope | "Handle X" with no refusal set | One workflow, defined hand-offs |
| No ownership | Side project, no on-call | Named owner, rollout ladder |
A worked example: the unit economics of a support agent
Numbers make the discipline concrete. Take a support-triage agent that drafts a first response for billing questions. Assume 10,000 tickets a month and roughly 4,000 tokens per ticket once you include the system prompt, retrieved context and the drafted reply. Multiply that volume by your model's current per-token rate, add retries, evaluation runs and logging, and for a mid-tier model the monthly spend typically lands in the low hundreds of dollars. Re-price it against the vendor's live rate card before you commit, because those rates move month to month.
Now weigh that spend against the outcome from step one. If the agent lets the team close billing tickets materially faster, the saved agent-hours dwarf the token bill and the project clears. If the time saved is marginal, the token cost is noise but so is the benefit, and the honest call is to stop. This is the calculation Gartner says most cancelled projects never ran until the invoice arrived. Running it first, on a spreadsheet, costs nothing and kills the weak ideas before they consume a quarter. The method matters more than any single figure.
Which use cases ship first
MIT's finding that back-office automation produced the biggest returns is a map, not a footnote. The agents that reach production tend to sit behind an internal user, handle a repetitive text-heavy task, and have a human check the output before it leaves the building: drafting support replies, summarising documents, reconciling records, triaging tickets, preparing first-pass reports. They are unglamorous, which is exactly why they survive: the scope is narrow, the failure is recoverable, and the value is countable. Customer-facing agents that take irreversible actions are harder, and they belong later on the rollout ladder once the internal versions have earned trust. Start where a mistake costs an edit, not a refund.
India-specific considerations
For Indian enterprises the failure math is the same, but two local factors change the plan. Cost discipline matters more because rupee budgets are tighter and GPU capacity is scarcer, so the unit-economics step is not optional. And the Digital Personal Data Protection Act, 2023 reshapes any agent that touches personal data. The Act's Consent Manager framework becomes operational on 13 November 2026, and penalties for breaches can reach ₹250 crore per violation. An agent that reads customer records, drafts replies or takes account actions is processing personal data, so consent, purpose limitation and a clear audit trail belong in the scope from day one, not after launch.
The practical move is to fold DPDP into steps 4 and 6: least-privilege access limits what personal data the agent can reach, and the named owner is also accountable for the data-processing record. Designing for this early is far cheaper than retrofitting consent into a shipped agent weeks before an enforcement deadline.
How eCorpIT can help
eCorpIT is a Gurugram-based technology company, founded in 2021, with CMMI Level 5 and ISO 27001:2022 certification and senior-led, multi-disciplinary engineering teams. We help enterprises take AI agents from a promising pilot to a governed production system: defining the outcome and kill metric, narrowing scope, building the evaluation harness, wiring least-privilege tool access, and modelling the unit economics so the business case survives contact with real traffic. Our enterprise AI agent development work applies the checklist above, and the broader enterprise AI agents in production guide shows where agents pay off first. If you have an agent stuck in pilot, contact us and we will pressure-test its path to production.
FAQ
References
- Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 — Gartner newsroom, 25 June 2025.
- State of AI in Business 2025 (Project NANDA) — MIT NANDA report PDF.
- MIT Finds 95% of GenAI Pilots Fail Because Companies Avoid Friction — Forbes, 26 August 2025.
- MIT Report Finds Most AI Business Investments Fail, Reveals 'GenAI Divide' — Virtualization Review, 19 August 2025.
- Why most AI products fail: Key findings from MIT's 2025 AI Report — Mind the Product.
- Why 40% Of Agentic AI Projects May Be Canceled By 2027 — Forbes, 7 July 2026.
- MIT report: 95% of generative AI pilots at companies are failing — Yahoo Finance.
- DPDP Act compliance timeline and enforcement 2026-27 — India Briefing.
_Last updated: 1 August 2026._
