The conversation about why AI projects fail usually focuses on the model. The model hallucinated. The model was too expensive. The model was not good enough.

After dozens of engagements, we have come to a different conclusion. Most AI projects do not fail because the model is wrong. They fail because of three decisions made (or skipped) before a single line of code is written. This piece is about those three decisions, in the order they matter, with concrete examples of what each one looks like done well and done badly.

If you are about to start an AI project, this is the checklist to hand to the team running it.

Why this matters

The cost of a failed AI project is not just the money spent. It is also:

Six months of organisational attention burned on something that did not work
The credibility hit when you have to tell the board “the AI initiative is on pause”
The opportunity cost: while you were chasing the failure, your competitors were doing something that worked
The cultural cost: your team’s appetite for the next AI project shrinks every time the last one disappoints

A failed AI project is rarely a small cost. Getting these three decisions right at the start is the difference between “we shipped something useful in 8 weeks” and “we are still talking about it in 12 months”.

Failure mode 1: the scope is too vague to test against

This is the most common, and the most preventable.

A bad scope looks like this:

“Use AI to improve customer service.”

You cannot ship that. You cannot test that. You cannot even argue about whether it is done. It is not a scope, it is a wish.

A real scope looks like this:

“Build a chatbot that answers the 40 most common customer questions in under 60 seconds, in our brand voice, escalating any pricing question or complaint to a human, integrated with Intercom, live on the website and WhatsApp.”

Notice what is in that sentence. The job to be done. The latency target. The voice. The escalation rules. The integration. The channels. You can hold a contractor accountable to that. You can measure it. You can decide when it is done.

If you cannot reduce your AI project to a sentence like that, you are not ready to start. The first task in every engagement should be tightening the scope until the team can write the success test.

How we handle it. Every WPfoss AI engagement begins with a half-day scoping conversation. The deliverable is one written paragraph the client signs off on, in the form: “By [date], we will have shipped [exact thing], used by [exact people], measured by [exact metric].” Everything else is built backwards from that paragraph.

Failure mode 2: the knowledge base is junk

Once the scope is right, the next failure mode is data.

An AI agent (chatbot, automation, RAG system) is only as good as the source it reads from. If your SOPs live in three Notion pages, two Google Docs, an old PDF in your founder’s inbox, and one engineer’s head, the agent will be confidently wrong about half the time.

Worse: the failures will not look like data failures. They will look like AI failures. The bot quotes the wrong price. The agent gives outdated policy. The RAG system cites a document that has been deprecated for six months. Everyone blames “AI hallucination”. The actual root cause is your source.

We spend the first third of every engagement just cleaning the knowledge. SOPs centralised. Contradictions resolved (yes, you have contradictions; everyone does). Pricing rules formalised. Brand voice samples extracted. Decision history made searchable.

This is the least glamorous and highest-leverage work in the project. Skipping it is the most expensive shortcut a client can take. We have walked away from engagements where the client refused to invest the knowledge-base time, because we knew the project would fail and we did not want our name on it.

How we handle it. We refuse to start the build phase until the knowledge base passes a basic audit: single source of truth, no major contradictions, current within the last 30 days on every business-critical field. Sometimes this means delaying the build by two weeks. Always worth it.

Failure mode 3: nobody owns the agent after launch

This one is harder to see, because it shows up later.

The agent launches. The team moves on. Six weeks pass. The model degrades, the data drifts, new edge cases appear, the OpenAI bill creeps up. Nobody is paid to watch. By month four, the system is materially worse than it was at launch.

By month six, customers are quietly being failed. The CEO eventually says “the AI experiment did not work” and turns it off. The conclusion drawn is “AI is not ready for our business”, when the real conclusion should have been “we did not staff the operations side”.

Every AI system needs an owner. Either an internal one (someone whose job description includes “monitor and improve the AI”) or an external one (us, on a Managed AI Operations retainer). Without one, the system decays.

How we handle it. Every build engagement is offered with an optional managed retainer. About 70% of clients take it. Of the 30% who do not, half come back within six months to add it. We let clients choose, but we are honest about the consequences either way.

A pattern, not a checklist

These three failure modes interact. A vague scope makes the knowledge-base work harder, because you do not know what data the agent needs to know about. A bad knowledge base makes the operations work harder, because edge cases keep appearing. A lack of ownership makes the scope drift over time, because nobody is enforcing the original vision.

The reverse is also true. Tight scope makes the knowledge base work obvious. Clean knowledge base makes operations cheap. Clear ownership keeps the scope stable. Get the three right and the AI project is mostly downhill.

A concrete contrast

Two projects we worked on in the same quarter, in the same industry (mid-sized service businesses), with the same budget range ($15k to $25k for the build).

Project A (succeeded). The client showed up with a written one-paragraph scope, half their SOPs already consolidated in Notion, and a designated “AI lead” inside their company who would own the system after launch. We shipped a chatbot in 6 weeks. Three months later it was handling 71% of inbound messages without human intervention, and the client renewed for a managed retainer.

Project B (failed). The client said “we want to use AI to be more efficient”, refused to nominate a project owner, and resisted spending time on knowledge-base cleanup. We pushed back. They moved forward with another vendor who agreed to skip the prep. Six months later, we heard from them again: the system had been turned off, the vendor was blamed, and the client was now sceptical of “AI as a category”. The technical work the other vendor did was probably fine. The three pre-conditions were missing.

The technology was not the variable. The pre-conditions were.

The checklist, before you start

Before you commit budget to any AI project, internal or external, get yes-or-no answers to these:

Can I write the success test in one sentence?
Is the knowledge the AI will use centralised, current, and free of major contradictions?
Will there be a named owner of this system 90 days after launch?

If you have three yes-es, you are ready to start. If you have one or two, fix the gaps before you spend money. If you have zero, do not start. Spend the budget on the prep instead.

Frequently asked questions

What if I cannot find a clear scope yet?

Hire a short discovery engagement. A two-week scoping project usually costs $3k to $8k and saves an order of magnitude more later. It is the cheapest insurance in AI work.

Who should own the AI system internally?

Ideally someone in operations, not engineering. The person who would own a new internal tool, not the person who writes the code for it. They do not need to be technical; they need to care.

Can WPfoss help fix a failed AI project?

Sometimes, after an audit. About 30% of our engagements are takeovers of projects that went sideways. We can usually resurrect the work, but we are honest when we cannot.

What is the smallest AI project that makes sense?

Roughly $5k to $8k for a tightly scoped single-purpose chatbot or automation. Below that, the prep work dominates and the ROI is hard to defend. There are exceptions, but they are rare.

Why do you talk about failure modes on a marketing site?

Because clients who have been burned before are the best clients. They have learned the same lessons we have. The clients we cannot serve well are the ones who have not learned them yet and resist learning them now.

The honest pitch

If you are starting an AI project, get the three pre-conditions right before you pick a vendor. If you cannot get them right alone, hire someone (us or someone else) to help you scope before you commit the bigger budget. The build work is straightforward when the prep is done.

If you want to talk through whether a project you are about to start has the pre-conditions in place, book a free call. If you already know what you want and just need it built, order the engagement.

Why most AI projects fail before they start