← BlogRemote
Dispatch № 001July MMXXVI

Why your AI pilot died in week six.

Almost none of these are model problems. They are ownership problems that surface late and were decided early.

Lede

There is a shape to failed AI projects that repeats so exactly it is almost boring. The demo lands in week two. Everyone is delighted. Then weeks three through five go quiet, and somewhere around week six the project stops being discussed in the weekly. Nobody kills it. It just stops having a next step.

The reflex is to blame the model — it hallucinated, it was too slow, it was too expensive. In our experience that is almost never what happened.

The four decisions nobody made

Who owns the source system. The agent needs to read from a system that belongs to a team with its own roadmap. In week two you were reading a CSV export somebody mailed you. In week five you need a real connection, and the team that owns it has not agreed to anything. This single item stalls more projects than every model limitation combined.

What "correct" means. If you cannot write down fifty cases and the right answer for each, you do not have a specification, you have a vibe. Teams that skip this end up arguing about output quality with no way to settle it, which means every disagreement escalates to the most senior person in the room.

Where the exceptions go. Every workflow has a tail of cases that a person must decide. If you have not designed that path — who sees it, in what queue, with what context attached — then in production the agent either guesses on cases it should not touch, or it stops and nobody notices.

Who runs it on a Tuesday in March. A pilot is owned by the person who championed it. Production is owned by whoever gets the page. If those are not the same person, and the second one was not in the room, they will quietly decline the handover.

What to decide first

Turn the list around and it becomes a scoping checklist. Before writing code, we want four things written down: a named owner for every source system, fifty cases with agreed answers, a drawn exception path with a queue and an owner, and the name of the person who will run this in six months.

None of that is glamorous, and none of it involves a model. But a project with those four things settled tends to ship, and a project without them tends to die in week six regardless of how good the demo was.

If you cannot get those answers from your own organisation, that is worth knowing too — and it is a much cheaper thing to discover in a scoping call than in month three of a build.