Most enterprise agent pilots don't fail. They stall, which is worse, because nobody gets to kill them. The model works on the sample data, the demo lands in the steering meeting, and then the project sits for months waiting on a permissions ticket, an undefined success bar, or a team that never agreed to run it. Across our engagements, the pilots that stall were usually doomed by decisions skipped in the first fortnight, and a CTO can catch all three before signing anything.
Pilots Stall Because They Were Built to Demo
A pilot is usually scoped to answer one question: can the model do this task? That's the cheapest question in the whole project. Hand a frontier model a picked sample and it will draft the reply or summarise the contract, and everyone involved had already suspected as much well before the pilot started. So it answers the one question nobody really doubted.
The questions that decide whether anything ships are different. Is 'good enough' defined well enough to argue about? Can the agent reach the data it needs without a six-month access review? Who is on the hook when it does something wrong at 2am? A sandbox pilot dodges all three by design. It runs on an exported CSV, gets judged by whoever built it, and has no on-call rota because nothing real depends on it.
We've written before about the organisational reasons pilots die around month four. The three checks below are the pre-flight version: things you can verify on paper, before budget is committed, that predict whether a pilot has a path to production at all.
Check One: Write Down the Number That Kills the Project
Before greenlighting, ask for the acceptance test. It needs a metric, a threshold, a test set drawn from real traffic, and a named person who signs it off. 'Agent resolves 35% of tier-one tickets end to end, with a wrong-action rate under 1% on a 300-case set sampled from last quarter' is an acceptance test. 'Improve support efficiency' is a wish.
The threshold matters more than the metric. It's the line below which you stop, and agreeing it upfront is what lets a project die cleanly in week six instead of limping through quarter three. We now write the acceptance test with clients before the build starts, and a meaningful share of conversations end right there. Usually that's because the business can't say what number would make the work worth it. Better to find that out for the price of a meeting.
Watch for a quieter failure: the build team grading its own metric. If the people who wrote the prompts also choose the test cases and then score the outputs themselves, the pilot will pass. Every time. Ask who outside the team owns the test set.
If nobody can say what number would make you stop, you haven't approved a pilot. You've approved an open-ended experiment.
Metric tied to a business outcome, not a model score
Kill threshold agreed before the build
Test set sampled from real production inputs, including the ugly ones
Sign-off owner who didn't build the agent
Check Two: Prove Production Data Access in Week One
In our audits, the most common reason an agent sits in pilot is boring: it can't get at the data in production. The pilot ran on a snapshot someone exported with admin rights. Production needs a service account, row-level permissions that match what the end user is allowed to see, data fresher than last night's ETL, and an API that doesn't time out under load. Each of those is a ticket in another team's queue.
Ask the team to demonstrate, before the pilot is funded or within its first week, that the agent can read one real record through the same path it'll use in production. One record, real credentials, real permission checks. If that takes three weeks of approvals, you've just learned your actual timeline, and it has nothing to do with the model. We've written a longer checklist for de-risking the data access layer, but the week-one test catches most of it.
Same check for writes. If the agent will update a CRM record or issue a refund, confirm which system of record it touches and who has to approve a non-human writer. Security teams are right to be slow here. Start that conversation before the demo, not after.
Check Three: Name the Person Who Gets Paged
Ask who owns the agent on the day after launch. Not the sponsor; the person who gets the alert when the wrong-action rate spikes, who decides whether to roll back a prompt change, and who reviews the cases the agent escalated. If the answer is 'the vendor' or 'we'll figure it out', the pilot will stall at handover, because no operations team will accept a system they can't observe or fix.
Ownership is only real if the owner has instruments. That means an eval use they can rerun when prompts or models change, traces that show which tool call went wrong, and some estimate of failures that never become a complaint. Without those, the owner's only signal is the ticket queue, and agent failures mostly don't show up there.
This is the check we still find hardest to satisfy. Plenty of companies run a strong platform team and have nobody whose job includes reading agent transcripts. Tooling won't fix that. Whether you hire someone for it or rotate it through the team, it's an org-design problem, and it sits with the CTO.
Our recommendation: if a proposed pilot can't pass all three checks on paper, don't approve a smaller pilot. Fund a week or two of discovery instead, long enough to write the acceptance test, prove one read against production and put a name next to the owner. Projects that come out of it with answers tend to ship. The rest were going to stall anyway. Now they cost you a fortnight instead of a quarter.
Acceptance test: written, with a kill threshold and an independent sign-off owner
Data access: one real production read, through production credentials, demonstrated
Ownership: a named operator, with an eval use and tracing in scope for the build
FAQ
Why do enterprise AI agent pilots fail to reach production?
Most stall on non-model issues: no agreed success threshold, no production data access under real permissions, and no team that owns the agent after launch. The model usually works on sample data; the surrounding decisions were never made.
What should a CTO check before approving an AI agent pilot?
Three things: a written acceptance test with a kill threshold, a demonstrated read of real production data through production credentials, and a named owner who'll operate the agent with evals and tracing. If any is missing, fund a short discovery sprint first.
How do you define success criteria for an AI agent pilot?
Pick a metric tied to a business outcome, set a threshold below which you stop, and test against cases sampled from real production traffic. Someone outside the build team should own the test set and sign off on the result.
Who should own an AI agent after it goes into production?
A named operator inside your organisation who gets alerted on failures, can roll back prompt or model changes, and reviews escalated cases. Vendors can build the instruments, but ownership has to sit with someone who'll still be there next quarter.
— Daniel · usqrd.com · reply to this email, I read everything