Why most “AI for trades” pilots die in week six

There is a pattern that repeats so reliably you can set a calendar by it. A service business gets excited about AI, runs a pilot, sees a promising first demo, and then watches the whole thing quietly die around week six. Nobody calls a meeting to kill it. It just stops getting used. The champion gets busy, the novelty wears off, and the tool joins the graveyard of the ninth marketing app nobody opens.

The autopsy almost always blames the model — it was not accurate enough, it hallucinated, it did not understand the trade. That is rarely the real cause of death. The model usually worked fine in the demo. It died for a more boring and more fixable reason: there was no system for it to live inside.

The demo is the trap

A pilot starts with a demo because a demo is easy. You take a single task — draft a quote, summarize a call, answer a customer question — and you show the AI doing it impressively on one clean example. Everybody nods. The problem is that a demo is a performance on a stage. Real operations are not a stage. They are messy, continuous, and full of the exact edge cases the demo carefully avoided.

Three things the pilot did not have

It did not have the data. The impressive demo ran on a hand-picked example. In production, the AI needs your actual job history, your customer records, your parts and rates — and that data is scattered across the nine disconnected tools nobody integrated. The model is only as good as what it can see, and in a pilot, it can see almost nothing real.

It did not have a place to put the output. A drafted quote that lands in a chat window is a parlor trick. A drafted quote that flows into your actual pipeline, attaches to the right job, and waits for an estimator’s approval is a workflow. Pilots produce outputs with nowhere to go, so the human has to manually ferry every result into the real system — which is more work than doing it by hand, which is why they stop.

It did not change anyone’s actual workflow. The pilot lived next to the way people already worked, as an extra tab. Anything that lives next to the workflow instead of inside it is, by definition, optional. Optional tools lose to busy days, every time.

What survives instead

The AI that survives past week six is the AI you never think about, because it is not a tool you open — it is a behavior of a system you already use. The triage happens because the lead came into the operating layer and the agent acted on it automatically. The quote drafts itself because the job spec lives in the same system that knows your rates. The follow-up sends because the job closed and the system noticed.

Notice what is doing the work in every one of those sentences. It is not the model. It is the system the model lives inside. The model is a component. The operating layer is the product.

Build the system, then the model has somewhere to live

This is why we do not sell pilots. A pilot optimizes for an impressive first demo and is structurally set up to die in week six, because it skips the unglamorous part — the operating layer that connects the data, holds the output, and is the workflow rather than sitting beside it.

Build that layer first, and the intelligence stops being a fragile experiment and becomes a permanent capability. Skip it, and you will run another pilot next year, see another promising demo, and bury another tool around week six — for the same reason as last time.

The model was never the hard part. The system is the work. Once it exists, the AI simply lives there, doing the boring things flawlessly, and nobody ever has to remember to open it.