Why AI agent pilots stall, and how to get one into production

The short answer: an agent pilot usually stalls between the demo and the second month, and the model is rarely the reason. The demo ran on a clean export, a handful of hand-picked cases and someone’s full attention. Production has live data, edge cases, no one watching and a bill. Below are the five gaps we see most often, a checklist to close them, and the cases where you should not build an agent at all.

What the numbers say

Several surveys point the same way, though each measures something different, so read them as signals rather than one statistic.

• Gartner predicted in June 2025 that more than 40% of agentic AI projects will be canceled by the end of 2027, citing rising costs and unclear business value, as reported by Reuters. Gartner also estimated that only about 130 of the thousands of vendors selling “agentic AI” are genuine.
• Gartner also predicted that through 2026, organizations will abandon 60% of AI projects that lack AI-ready data, and found in a July 2024 survey that 63% of organizations lack confidence in their data management practices for AI (Freevacy summary of the Feb 2025 release).
• MIT NANDA’s GenAI Divide report (August 2025) found that about 5% of generative AI pilots achieve rapid revenue growth, while the rest show little or no measurable P&L impact. The authors blame a “learning gap” and poor integration into workflows rather than model quality (Fortune). It is a preliminary study with a modest sample, so treat the 95% as a direction, not a law.
• LangChain’s State of Agent Engineering survey (1,340 responses, run in November and December 2025) found 57.3% of respondents have agents in production, and named quality the biggest barrier, cited by 32%. Only 52.4% run offline evaluations and 37.3% run online evaluations (LangChain, published June 2026).

So agents do reach production. The ones that don’t tend to fail on the same five things.

1. The data is stale, partial or a one-off export

A pilot often runs on a CSV someone exported in week one. It looks fine in the demo because the questions were written against that export. In production the agent meets records added since, fields nobody cleaned and sources that were never connected.

Questions to ask about every data source the agent reads:

• Where does it come from, and who keeps it current? If the answer is “Sarah exported it,” that is a pilot, not a system.
• How fresh does it need to be? A pricing agent that reads last month’s competitor prices gives confident, wrong answers.
• Can the agent tell how old a value is? Return a source and a retrieval timestamp with each value, so the agent can say so, or refuse.
• Does it come from the web at answer time? Browsing live sites inside the agent loop is slow and unreliable. We cover why in web data for AI agents. For data your agent needs every day, a validated feed it can query, such as an agent-ready dataset over MCP or an API, holds up better.

Fix the data before you tune prompts. A better prompt on stale data gives you a more fluent wrong answer.

2. Nobody defined what “working” means

Most pilots are judged by a demo and a feeling. That is fine for week two. It cannot tell you whether a prompt change, a new model version or a new data source made things better or worse.

You need an evaluation set before you build much at all. Anthropic’s engineering team suggests that “20-50 simple tasks drawn from real failures is a great start” (January 2026), and recommends:

• deterministic graders where you can (did the record get the right status, is the total correct), with model-based graders checked against human judgment where you can’t
• grading the outcome rather than the exact path the agent took
• keeping capability evals, which start with a low pass rate, separate from regression evals, which should stay near 100%
• turning every failure users report into a new test case

In practice: pull 30 to 50 historical cases from the workflow, write down the correct result for each, and agree a pass bar with the person who owns the workflow. If nobody can write down the correct result, you have found a bigger problem than the agent.

3. The tools were built for people, not agents

Pilots often hand the agent existing internal APIs. Those return what a screen needs: long payloads, internal IDs, fifty fields when the agent needs four. The agent burns context, picks the wrong endpoint, or chains five calls where one would do.

Anthropic’s guidance on writing tools for agents (September 2025) is worth reading in full. The main points:

• Consolidate. One schedule_meeting tool beats separate list-availability and create-event calls.
• Namespace related tools with a shared prefix so the model can tell them apart.
• Return meaningful context, not low-level identifiers.
• Limit output with pagination, filtering or truncation.
• Test tools with an evaluation, not intuition.

Its earlier post on building effective agents (December 2024) adds that a good tool definition includes example usage, edge cases and input format requirements. Two rules of our own: make data tools read-only by default, and put every write (a refund, an email, a status change) behind an explicit approval step until the evals say otherwise. For web data tools specifically, see how to give your agent reliable web data with MCP.

4. Nobody owns it after the demo

The pilot had a champion. Production needs owners, plural:

• A workflow owner on the business side. They decide what correct looks like, review the exceptions and say when the agent may do more.
• An engineering owner who gets the alert, reads the traces and ships the fix.

Without both, the first silent failure ends the project. Silent is the normal failure mode: the agent doesn’t crash, it returns a plausible answer from a source that stopped updating three weeks ago.

What monitoring should cover:

• traces of every run, so you can see which tools the agent called and why
• data freshness alerts on every source, not only uptime on the service
• a queue for cases the agent declined or flagged, with a person assigned to it
• the eval suite re-run on every prompt, tool or model change
• cost and latency per task, tracked week over week

LangChain’s survey found 89% of teams with agents have some form of observability. Observability without an owner is a dashboard nobody reads.

5. Nobody measured the cost per task

In a pilot, the bill is small and nobody looks at it. At volume, retries, long contexts and human review add up. Anthropic notes plainly that “agentic systems often trade latency and cost for better task performance”. Gartner’s cancellation forecast lists rising costs first.

Measure the cost of a completed task, not a model call:

• model and tool costs, including failed runs and retries
• the minutes a person spends reviewing or fixing the output
• the engineering time to keep it running

Then compare it with what the task costs today. Common ways to bring it down: move deterministic steps into plain code, use a smaller model for routing and extraction, cache data the agent reads repeatedly, and shorten tool outputs.

A checklist before you call it production

• Every data source has an owner, a refresh cadence and a freshness check.
• Each value the agent uses carries a source and a timestamp.
• An evaluation set of 20 to 50 real cases exists, with a pass bar agreed by the workflow owner.
• The eval suite runs on every prompt, tool and model change.
• Tools are narrow, documented and return only what the agent needs.
• Writes and irreversible actions need approval until the evals justify more.
• A named workflow owner and a named engineering owner exist.
• Runs are traced, and alerts go to a person, not a channel nobody reads.
• Declined and flagged cases land in a queue someone works through.
• Cost per completed task is measured and compared with today’s process.
• There is a documented way to switch the agent off and fall back.
• Prompt injection is considered for every input that comes from outside, especially web pages and emails.

If you can tick most of these, the pilot is ready to grow. If you can tick three, it is still a demo.

When not to build an agent

Being candid here saves everyone money. Don’t build an agent when:

• The process is fully rule-based. If you can write the steps down as a flowchart with no judgment calls, a script or a workflow is cheaper, faster and easier to test. Anthropic’s own advice is to find “the simplest solution possible” and add agentic steps only when simpler solutions fall short.
• One model call with retrieval answers it. Classifying a ticket or summarizing a document rarely needs a loop of tool calls.
• Volume is too low. A task done twelve times a month will not repay the build and the upkeep.
• Nobody can define a correct result. You can’t evaluate it, so you can’t improve it.
• Mistakes are expensive and nobody can review them. Keep a person in the loop or don’t automate.
• You need a list once. Ask your own assistant. We explain where that line sits in can your AI agent replace a web scraping service?
• The data doesn’t exist yet. Build the data feed first. The agent can wait.

Getting one into production

Our view is that data comes first: get the data right, then put agents on it, in your stack. That is the order in our AI agent development work. A one-week discovery maps the workflow, the data and the evaluation set, then a fixed-scope build ships the agent into your systems with monitoring attached. We run the same pattern on our own Nomad Watch dataset, where agent output passes a deterministic gate and a cross-model check before it ships. If your workflow fails the “when not to” list above, we will tell you, and a short conversation is usually enough to find out.