Why AI pilots stall, and how forward deployed avoids it
An AI pilot most often stalls because nobody on the business side owns it, it runs on demo data instead of the real documents, nobody in the company validates its output, and nobody follows it after launch. A forward deployed engineer works inside the client's company, with its real files and its real teams, which removes those four causes. It does not guarantee the outcome: someone on the business side still has to review.
The pilot works in the demo, everyone applauds, and then nothing happens. Three months later nobody uses it. This article lists the concrete causes of that pattern and what an engineer working inside the company changes. We give no figure for how often it happens: we have not read a primary source that measures it.
Why does an AI pilot stall?
Four causes come up, and they compound.
Nobody on the business side owns it
The pilot often starts in the IT department or an innovation team. The team that should use it (quoting, support, engineering design) did not ask for the tool and has nobody to say whether an answer is right. With no owner, nobody rules when the agent gets it wrong, and nobody asks for the next version.
The pilot runs on data that looks nothing like the real thing
A handful of clean documents, picked for the demo, produce lovely answers. Real folders hold scans, duplicate versions and naming habits nobody wrote down. Anthropic describes the testing side of this trap: its engineers recommend building evaluation tasks from real failures, which keeps the test set faithful to actual use. A pilot that has never met a hard document has proved nothing.
Nobody in the company validates
An agent that prepares a reply or a document can be wrong. Anthropic notes that an agent’s autonomy means higher costs and the potential for compounding errors, and recommends extensive testing in sandboxed environments along with guardrails. When nobody reads before it goes out, the first visible mistake becomes the argument for stopping the project.
Nobody follows what happens after launch
Anthropic writes that without evals, teams get stuck in reactive loops: they wait for complaints, fix the bug, and hope nothing else regressed. It adds that evals get harder to build the longer you wait. A pilot shipped without follow-up degrades quietly, until the day the business team has stopped trusting it.
What does a forward deployed engineer change?
Forward deployed means an engineer sent to the client’s site instead of staying at their own desk. The point is proximity: the person who builds the agent hears the complaints, sees the documents people actually open, and notices when a team quietly goes back to its old spreadsheet.
- Real data from day one. The agent is connected to the actual folders, flaws included. The hard cases show up in the first week, not after signature.
- A named owner. An engineer on site asks who in the company will judge the answers. If the answer is “nobody”, the project waits.
- Failures turned into tests. When a user reports a mistake, the engineer sees it, fixes it and keeps it as a check, which follows the method Anthropic describes.
- Follow-up that continues. The engineer stays the point of contact after go-live.
The limit is real. An engineer, however present, does not replace the business person who validates. If the company frees nobody to review the first outputs, the pilot stalls just the same.
What does a pilot with a good chance of holding up look like?
A few conditions can be checked before a single line of code is written.
- The name of the business person who will judge the answers is known, and their review time is blocked in their calendar.
- The documents used are the real ones, including the messiest, not a selection prepared for the occasion.
- A first set of test cases exists. Anthropic considers 20 to 50 simple tasks drawn from real failures a good start, and notes that evals get harder to build the longer you wait.
- Someone watches real usage after launch. Anthropic describes this monitoring as a complement to automated evals: it reveals real user behaviour at scale and catches issues that synthetic evals miss.
- It is settled in advance what the agent may not do on its own, for example sending a document to a customer.
None of these conditions needs a special budget. They need decisions made early, by people inside the company, and that is where having an engineer on site helps most: they ask the questions before the pilot begins.
And with us?
We publish this blog. We are three Télécom Paris engineers specialised in AI, working forward deployed. The first call lasts 30 minutes, is free and carries no commitment. You open access to your tools in two clicks, with no password, and two weeks after the call a first agent is running. After that you have a dedicated contact.
Nothing goes out without a person at your company approving it. That is a rule of how we work, not an option. The agents cite their sources, so the person validating can check where each answer comes from. See the pages on AI transformation for companies and the AI audit.
Sources, consulted on 12 November 2026
Questions
Why do so many AI pilots never reach production?
The concrete causes are no business-side owner, a pilot run on demo data, no validation by a person in the company, and no follow-up. This post gives no figure for how common it is, because we have not read a primary source that measures it.
What is a forward deployed engineer?
An engineer sent to work at the client's company. They work with its teams and on its real documents, build the agent on site and follow it after it goes live.
How do you measure whether an AI agent works?
Anthropic recommends starting with 20 to 50 simple tasks drawn from real failures, then monitoring real usage after launch. Without that, it writes, teams fly blind.
How long until a first agent runs?
With us, a first agent is running two weeks after the first 30-minute call, which is free and carries no commitment. Amounts are given on the call.