Bottom Line Studio
Write the cancellation memo first
Most AI projects don’t fail loudly. They keep running because nobody wrote down what failure would look like. I learned that on my own workflow.
Decide how it ends before you decide how it starts.
Sound familiar? An AI pilot launched last quarter. Nobody has said it’s working. Nobody has said it isn’t. It’s still running, still costing something, and the next status meeting will probably push the question again.
Gartner expects a lot of these to be canceled
In June 2025, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, because of escalating costs, unclear business value or inadequate risk controls. That’s a forecast, not a count. But read the three reasons again. None of them shows up on launch day. All of them show up later, and “later” is exactly when nobody has a rule for deciding.
Cancellation isn’t the failure. A project that should stop and doesn’t is the failure.
My own pilot ran five weeks on autopilot
I run my content on a small, mostly automated workflow. In September I added an AI image step: every Monday, the workflow wrote a set of ready-to-paste prompts for an image model, so I could generate illustrations from my phone and drop them in a folder. If the folder stayed empty, the workflow fell back to the diagrams it already built.
The fallback worked perfectly. That was the problem. For five straight weeks the folder stayed empty, the fallback covered for it, nothing broke, and the step kept running. Every Monday it produced prompts nobody used, including me.
What finally worked was a different shape entirely: one batch request, run once, that produced a full set of images in an afternoon. The weekly step was never going to get used. I just hadn’t written down what “not working” would look like, so nothing ever told me to stop. Written on day one, the memo would have said: at least one set of images used by week 2; stop if the folder is empty three Mondays running; I decide.
Pilots don’t stop on their own
A stalled pilot rarely looks like a failure from the inside. It has a fallback, so nothing breaks. It has a sponsor, who would rather not call it. Its weekly cost is small, which makes one more week easy to carry. And the people who built it are already on the next thing, so nobody is watching the usage line.
That’s why the stop rule has to be written before launch. On day one everyone is optimistic and nobody has anything to defend. By week six, every conversation about stopping is also a conversation about whose idea it was.
The memo is one page
The fix is to write the cancellation memo on day one, before anyone is invested. Not a risk register. One page, four answers:
- What we expect by week 2. One observable thing: people using it, a number moving, a cost staying under a line.
- What would make us stop. Written as a signal, not a feeling. “Unused for three weeks running” counts. “Not delivering value” doesn’t.
- Who decides. One name. Committees keep pilots alive.
- What it costs to keep going. Money, compute, and the attention of whoever maintains it.
Early signals and late signals are different
The signals that should stop a project at week 2 aren’t the ones that should stop it at week 12. Early, you’re asking whether anyone uses it. Later, you’re asking whether it’s worth what it costs and whether you can control it.
| Kill signal at week 2 | Kill signal at week 12 | |
|---|---|---|
| Usage | The intended users haven’t touched it | Usage flat or falling after the novelty |
| Value | Nobody can name the decision it changes | The number it was meant to move hasn’t moved |
| Cost | Run cost already above the estimate | Cost per useful result still rising |
| Control | No owner for its access or its output | Errors need a person to catch them every time |
My image step would have tripped the first row by week 2. It took me five.
What’s one AI project on your team that nobody has written stop criteria for?