Most AI-in-RevOps Pilots Die in 90 Days. Here's the Autopsy.

The old way to ship AI in RevOps was to launch a pilot and celebrate the demo. Someone wires an enrichment agent, it runs in a sandbox for six weeks, it works, and the room claps. That is where most of them stop. We ran exactly that agent. Then someone asked who owned it, what it had cost that month, and how we would turn it off if it started writing garbage to production accounts. Nobody had an answer to any of the three. That agent never shipped. It joined the graveyard, which is where most of these end up: 88% of teams report using AI and only 38% have scaled anything past the pilot stage (scaled-AI surveys, 2025).

The gap between those two numbers is an operations problem, not a model one. GPT-class models are good enough for most RevOps work. What breaks is everything around them, and it breaks the same way every time, on a clock. A pilot that looks alive at the demo starts dying the moment it leaves the sandbox, and by day 90 most of the cohort is gone. Watch the curve before you read the causes, because the shape is the argument.

100%Day 0Launch. The demo worked and the room clapped.

The 50-point gap between using AI and scaling it is the graveyard. The four causes of death do their work in the flat middle of that curve, between the demo everyone saw and the scaling nobody reached. Here is what fills it.

View as table

Item	Value
Report using AI	88%
Ran a real pilot	62%
Pilot survived 90 days	45%
Scaled past pilot	38%

The four causes of death

Every dead pilot I have autopsied failed on at least one of these, and usually more than one. They are not independent. A pilot with no owner also has no telemetry, because nobody was assigned to build it.

Cause one: no owner

A pilot with no named owner is a pilot that dies the first week its champion gets busy. The agent runs, something drifts, nobody’s job is to notice, and by the time someone does the trust is gone. That is the day-30 drop on the curve. Ownership is not “the RevOps team.” It is one person whose name is on the runbook, who gets the cost alert, and who has the authority to kill the thing at 4pm on a Friday without asking permission.

Write that name down before you write the first prompt. If you cannot name the owner, you do not have a pilot, you have a demo.

Cause two: no telemetry

Most dead pilots had no idea what they were doing while they ran. How many records did the agent touch today? How many did it change? What did it cost? How often did a human override it? If you cannot answer those in a query, you are flying blind, and blind agents get shut off the moment anyone gets nervous, which they will. That is the day-60 drop: finance asks the cost, nobody can produce it, and the agent goes dark.

Telemetry is what lets you defend the agent when finance asks about the bill and a rep complains it “messed up my account,” which is why you build it in from the start instead of bolting it on after the first scare. Log every action the agent takes as a row: what it looked at, what it decided, what it changed, what it cost. Here is the minimum shape.

-- agent_action_log: one row per agent decision
-- agent_name, record_id, field, action, before_value, after_value,
-- confidence, tokens_in, tokens_out, cost_usd, human_override, ts

SELECT
  agent_name,
  DATE(ts)                      AS day,
  COUNT(*)                      AS actions,
  SUM(CASE WHEN human_override THEN 1 ELSE 0 END) AS overrides,
  ROUND(AVG(confidence), 2)     AS avg_confidence,
  ROUND(SUM(cost_usd), 2)       AS day_cost
FROM agent_action_log
WHERE ts >= CURRENT_DATE - 30
GROUP BY agent_name, DATE(ts)
ORDER BY day DESC;

An override rate climbing week over week means the agent is wrong more often and humans are catching it. A cost line bending upward means volume or token usage is running away from you. You want both on a chart before launch, not after the incident.

Cause three: dirty data underneath

An AI agent scoring leads against an ICP built on 40%-incomplete firmographics is not scoring leads. It is laundering your data quality problem into a confident-looking number. Poor data quality costs the average org $12.9M a year (Gartner), and 76% of orgs say less than half their CRM data is accurate (Validity). Point an agent at that and you get wrong answers faster, at scale, with a machine’s authority behind them.

I cover the full gate in Your AI-Readiness Score Is Really a Data-Readiness Score, but the short version for a pilot: check completeness on the exact fields the agent reads, on the exact segment it will run against, before you turn it on. If the fields it depends on are 60% populated, fix that first. The agent cannot infer its way out of missing data, and pretending it can is how pilots earn their spot in the graveyard.

Cause four: no rollback

Every dead pilot I have seen shared one line at the post-mortem: “we could not easily undo what it did.” An agent that writes to production needs an off switch and an undo button, and both need to exist before the first write. The off switch is a single flag that halts all agent action in one place. The undo button is the before-value you already logged in your telemetry table, which is exactly why that table earns its keep twice.

If the agent updated 400 records with a bad prompt, rollback is a single statement that restores before_value for every row it touched in that window.

-- Rollback one bad run from the telemetry you already captured
UPDATE crm_account a
SET    industry = l.before_value
FROM   agent_action_log l
WHERE  l.record_id = a.id
  AND  l.agent_name = 'enrichment_v2'
  AND  l.ts BETWEEN :bad_run_start AND :bad_run_end
  AND  l.field = 'industry';

If you did not log before_value, rollback is a manual reconstruction from field history if you are lucky and a data-loss incident if you are not. The table you built for cause two is the undo button for cause four.

The cohort behind the curve

The survival curve is not a metaphor. Run a real cohort of 100 pilots through it and each drop lands on a specific cause. Here is the attrition, and it reconciles to the 38% endpoint on the curve and the stat tile at the top.

Checkpoint	Pilots alive	What killed the drop
Demo worked (day 0)	100	Nothing yet. The demo always works.
Day 30	71	No owner: 29 drifted and nobody was assigned to notice
Day 60	52	No telemetry: 19 got shut off when finance asked the cost
Day 90	38	Dirty data and no rollback: 14 wrote garbage that could not be undone

Thirty-eight of the hundred are still running at day 90, which is the 38% on the curve and the middle stat tile. The other 62 did not fail because the model was bad. They failed because a build artifact was missing at the checkpoint where it was needed. Read the table the other way and it is a shopping list: 29 pilots would have survived day 30 with a named owner, 19 more would have cleared day 60 with a cost query, and the last 14 needed clean inputs and a rollback statement they never wrote.

Alive versus dead, side by side

	The pilot that died	The pilot that scaled
Owner	"The RevOps team"	One name on the runbook with kill authority
Telemetry	Nobody knew the daily cost	Every decision is a logged row
Inputs	40%-incomplete firmographics	Completeness checked on the in-scope slice
Rollback	Reconstruct from field history at 11pm	One query restoring before_value
When something drifts	Discovered at the post-mortem	Override alarm fires the same week

Shadow mode: the guardrail that flattens the curve

The four guardrails keep an agent from dying once it writes to production. Shadow mode is what lets you prove it will not die before it writes at all. In shadow mode the agent reads, decides, and logs what it would have done, but the write is suppressed. It runs against real records at real volume and populates the same agent_action_log, so you get override rate, cost, and confidence distribution from a run that cannot damage a single account.

A week or two of shadow mode is how you turn the steep curve into the flat one. You watch the would-be override rate before any rep sees a bad write, you watch the cost line before finance sees a bill, and you diff the agent’s proposed values against a human’s on a sample. When the shadow numbers hold, you flip a flag and the same logged decisions start writing for real, with the rollback statement already tested against the shadow run. The mapping from cause to guardrail is one-to-one, and none of it is expensive.

Cause of death	The guardrail that prevents it	Build cost
No owner	One name on the runbook with kill authority	5 minutes
No telemetry	agent_action_log, one row per decision	Half a day
Dirty data	Completeness check on the in-scope fields	One query
No rollback	before_value restore statement, tested	One query
Any of the above, unproven	Shadow mode: read and log, suppress the write	One flag

The pre-launch checklist

Before any AI agent touches production data, it clears these ten. No exceptions, because every skipped line is a cause of death on the list above.

1. 1

   Named human owner

   One person, on the runbook, with kill authority. Not a team.

2. 2

   Kill switch

   A single flag that halts all agent action from one place, tested.

3. 3

   Action logging

   Every decision is a row: input, output, cost, confidence, override.

4. 4

   Before-value on every write

   Captured at write time, so rollback is one query, not an archaeology dig.

5. 5

   A tested rollback statement

   Written and run in sandbox against a bad run, not theorized on a slide.

6. 6

   A shadow-mode run

   Read and log against the full segment with writes suppressed, for a week or two, before the first real write.

7. 7

   Scoped CRM permissions

   Exactly the objects and fields it needs, nothing more. FLS enforces it.

8. 8

   Completeness check passed

   On the fields it reads, on the segment it runs against, above your threshold.

9. 9

   A cost alert

   Fires at a daily dollar threshold before finance notices the bill.

10. 10

    A weekly override rate

    Checked every week, with a line above which you pause the agent.

Why survivors compound

Teams that get five or more AI use cases live in production are ahead of 90% of the market. They do not get there with better models. They get there because their first pilot had an owner, telemetry, clean inputs, and an undo button, so it survived long enough to earn the second one.

The mechanism is compounding, and it is worth naming because it changes what you optimize for. The first surviving pilot produces two things beyond its own output: a runbook pattern and organizational trust. The runbook for the second agent is a copy of the first with the nouns changed, because the owner, the action log, the kill switch, and the rollback query are the same shapes every time. And the trust is what gets you permission to point the third agent at something that matters, because finance saw the cost alerts work and a rep saw the override catch a bad write before it hit their account. A dead pilot produces the opposite: a story about the time AI “messed up the CRM” that gets told in every future planning meeting as a reason not to try again.

So the move with the most upside is making the first pilot boring enough to survive, not finding a better model or a cleverer prompt. Treat the four causes above as the difference between one agent that dies alone and a portfolio of five that each made the next one easier to ship.

The two that kill the most, and why nobody writes them down

Of the four causes, the owner and the rollback kill the most pilots, and they are the two teams avoid writing down. The reason is the same for both: writing them down puts a person on the hook. Naming an owner means someone’s name is on the runbook when the agent misbehaves at 4pm on a Friday, and that someone has to have the authority to kill it and the accountability if they do not. Committing to a tested rollback means admitting the agent might do damage, which sits badly next to a demo that worked. So both get deferred into “we will figure that out before we scale,” and the pilot dies in the gap between the demo and the scaling, right in the flat middle of the curve.

The fix is to invert the order. Write the owner’s name and build the rollback query first, before the prompt, before the tool definitions, before anything that makes the demo impressive. If you cannot find a person willing to own it, that is signal, not paperwork. It means nobody believes in the thing enough to be accountable for it, and a pilot nobody will own is a pilot that will not survive its first bad week regardless of how good the model is. The uncomfortable artifacts are the ones that predict survival, which is exactly why the dead pilots skip them. The same discipline shows up on the input side: an agent is only as trustworthy as the fields it reads, which is the whole argument in Your AI-Readiness Score Is Really a Data-Readiness Score.

What to do next

Take whatever AI pilot you are running or planning and score it against the ten. Count the fails. Each fail is a documented cause of death and a point of altitude you are giving up on the survival curve, and every one is cheaper to fix in the sandbox this week than at the post-mortem next quarter. Start with the owner and the rollback, for the reason above: they are the two that predict survival and the two nobody wants to write down. Then run it in shadow mode for two weeks and let the log, not the demo, tell you whether it is ready to write.