I make my living building AI automations. This piece is about the ones I refuse to build - which turns out to be the more useful list.
The industry numbers explain why. In the most recent surveys, 42% of companies reported abandoning most of their AI initiatives - up from 17% a year earlier - and the average organization now scraps almost half its AI proofs-of-concept before they ever reach production. Those projects weren't killed by bad technology. Post-mortems keep finding the same thing: the failures were structural, not technical. A technical failure throws an error message and gets fixed. A structural failure - wrong process, bad data assumptions, misaligned logic - produces no error at all. Just wrong output, discovered downstream, usually by a client.
Which means the most valuable moment in any AI project is before it starts: the moment someone decides whether this thing should exist. Here are the five requests where my answer is no, and what I say instead.
1. The process that isn't stable yet
The request: "Automate our proposals." Then you look at the proposals, and every one is different - not because clients differ, but because the process does. It changed twice this quarter. Half of it lives in the founder's head.
Automating an unstable process doesn't fix it. It freezes the instability and hides it inside a system nobody can safely modify. My rule, which I hold even when it costs me the project: extract the rule, run it manually for a quarter, then automate. A rule tested by humans is a specification. A rule invented for the tool is a pilot heading for the drawer.
What I say instead: "Write down how you do this. Do it by hand, by the written version, for three months. Then call me - the build will be half the price and it will actually work."
2. The automation nobody owns
The request comes from a champion - enthusiastic, senior enough to buy, not the person whose job touches the output daily. Ask who will own it in production and the answer is "the team" or "we'll figure that out."
The research on abandoned projects is blunt about this pattern: pilots without a named owner with real authority stall the moment the champion's attention moves on. They enter what one analysis calls pilot purgatory - frozen, perpetually extended, consuming maintenance without producing value. An automation needs one person with the authority to pause it when it misbehaves. No name, no build.
What I say instead: "Give me the name of the person who can switch this off at 4pm on a Friday. If that person doesn't exist yet, that's the project."
3. The whole workflow at once
The request: "Automate the entire pipeline - intake to delivery." Ambitious, exciting, and the single most reliable path to failure in the small-business automation literature. Full-workflow automation in one deployment fails because every segment's uncertainty multiplies, and when something breaks, nobody can isolate where.
The boring alternative wins every time: one module, validated alone, in production, before the next one is connected. It feels slower. It's measurably faster, because it's the version that survives.
What I say instead: "Which single segment hurts most? We build that. When it's been stable for a month, we talk about the next one."
4. The output that can fail silently
Some automations have a shape that makes their failures invisible: they complete without errors, look plausible, and are wrong. Records updated with wrong values. Messages routed to the wrong client. Reports with confident, incorrect numbers. Nobody notices, because nothing crashed - the damage surfaces weeks later, wearing your company's name.
A useful test from the failure research, which I now apply to every design: could someone other than the builder diagram this system's decision logic from the documentation? If not, it's over-engineered relative to the team that has to live with it - and its failures will be silent ones. If the output can be wrong without anyone naturally noticing, the build must include the noticing: expected-output checks, drift alerts, a human review point. If the client won't pay for the noticing, I won't build the thing.
5. The craft
The request: automate the work itself - the strategy, the creative, the judgment the client's clients pay a premium for.
This is the refusal that surprises people, coming from someone who sells AI. But it's just arithmetic. An agency's commodity layer - the same-shape-every-time work around the craft - is where automation pays. The craft is the margin. Automate it and you've converted a premium business into a discount one, permanently, to save hours that were never the expensive part. The hours reclaimed from grind should fund the craft, not replace it.
What I say instead: "Let's list your work in two columns - same shape every time, different shape every time. I only build in column one."
Why a builder says no
There's an incentive problem in AI consulting that nobody names: the person advising you what to build usually gets paid to build it. Every refusal above costs me revenue in the short term.
But the 42% abandonment number is my competition's portfolio. Every scrapped pilot in your industry makes the next honest project harder to sell - and every automation I decline is one that won't become shelfware with my name on it. The no is not generosity. It's the longest-term marketing I do.
If someone's pitching you an AI build right now, run their proposal against these five. If it fails one, the cheapest moment to find out is now.
No gate, no funnel, and no course teaching you to say no at the end of this. If you want a second opinion on something you're about to build - or about to buy - my inbox is open. That's rather the point.