The AI is the easy part.

Most of the AI projects that quietly die had a good demo. Someone showed a model doing something clever, the room nodded, and a build got greenlit on the strength of a moment that will never happen the same way twice. Then months pass, and the thing is either half-used or forgotten.

Many never make it into real, durable use. The usual explanations are vague: no clear owner, a process nobody changed, a dashboard ignored since month two. All true. Underneath them is a simpler pattern we see again and again. The projects start from the tool, not the friction, and the attention goes to the part that matters least.

The model is rarely why AI projects fail

A language model is a probabilistic component. It is genuinely useful, and it is also the least reliable thing in any system you build around it. The reliable parts are the boring ones: the scripts, the repeatable steps, the way one job hands off to the next, the checks that run when something looks wrong. That scaffolding is where most of the value lives, and it is where most of the effort should go.

When a project is framed as “add AI”, the scaffolding gets treated as plumbing, something to sort out once the clever bit works. That is backwards. The model is the easy part. You can swap it, prompt it, or replace it with a better one next quarter. The scaffolding is what you actually own, and it is what decides whether the model’s output ever turns into something a business can rely on.

So before we talk about which model, we ask whether the project has understood what it is really building. Usually it is not an AI feature. It is a process, with a model doing one messy step in the middle.

The list we run before any build

Discovery, done properly, is allowed to say no. That is the whole point of it. A step that can only ever conclude “yes, let’s build” is not discovery, it is a formality. The value is in the questions that can stop a weak idea before it becomes a budget.

Here is the short version of what we ask. None of it is about the model.

decision://before-we-build
  is there a named owner who loses sleep if this fails?
    no        -> stop, find the owner first
  what is the smallest surface that proves value in two weeks?
    unclear   -> the scope is still too big
  who catches it when the model is wrong, and what does it cost?
    nobody    -> do not ship it
  what in the current process actually breaks, that this fixes?
    nothing   -> you are adding AI, not removing friction
  is this a model problem, a rules problem, or a people problem?
    not model -> do not reach for a model

Most ideas that fail this list fail on the last question. Someone wanted a model for something a rule would have done more reliably, or for something that was really a people problem wearing a technical costume. Catching that in a discovery conversation costs an afternoon. Catching it after a build costs a quarter.

The pilot nobody was watching

Here is the failure that taught us to take the scaffolding seriously.

An automation gets built. It works on the day it ships. Everyone moves on. There is no review built in, no feedback, nothing that reports on whether it is still doing its job. Months later it breaks, quietly, on some input nobody anticipated. Because nothing was watching, nobody notices. The work it was supposed to be doing simply stops, and the first sign is a person downstream wondering why something feels off.

That is not a model failure. The model was fine. It is a scaffolding failure. An automation that cannot tell you when it has stopped working is not finished, however good its demo was.

So we treat two things as part of the build, not as extras. First, it has to report: a heartbeat, a log, a plain “I ran, here is what I did, here is what I skipped”. Second, it has to be documented as part of the larger process, so that when it breaks, or when the person who built it has moved on, someone can see where it sits and what it touches. An automation is not a clever trick you install and forget. It is a small piece of infrastructure, and infrastructure nobody can see is infrastructure nobody can fix.

An automation that cannot tell you when it has stopped working is not finished, however good its demo was.

What we tell people to do first

If you take one thing from this, it is not a tool recommendation. It is a habit.

Before your next AI build, write the stop condition first. Decide, in advance, what result would make you kill it, and decide how it will tell you when it breaks. If you cannot answer either, you are not ready to start, and that is useful to know now rather than a quarter from now.

Then build the smallest version that could prove value, keep a person on the parts where being wrong is expensive, and spend most of your effort on the scaffolding around the model rather than the model itself. The clever part tends to take care of itself. The unglamorous part is the work.

None of this is anti-AI. We build with these tools every day, including to run our own businesses. It is that the projects which last are the ones that treated the model as the easy part, and put their attention where the reliability actually comes from.