The AI Moat Is Dead

The menu has to be right.

Imagine a restaurant using AI to rewrite its menu descriptions. The copy sounds good. The prices are correct. But the model adds an ingredient that isn't in the dish. That is a failed job, however impressive the model looked before someone checked the menu.

If I sell that service, access to the model is only the beginning of what I owe the customer.

That is the AI moat I don't believe in: access to a leading model as a permanent foundation for my business. A lab can have a real advantage and deserve a premium without keeping that lead forever. I don't want my business to require it.

If access stops being special, what makes a customer choose what I built?

KB

---

Work worth accepting

In the menu example, the restaurant needs descriptions it can actually use. A page full of fluent text gives it something to review. Whether that is useful depends on how much work remains.

If the owner has to check every sentence against the original menu, repair the facts and then check the repairs, I may have moved the work rather than removed it. Making the first draft cheaper doesn't settle that question.

I want to compare the cost of acceptable work: the model call, retries, review and the consequences of getting it wrong. A more capable model can be worth paying for if it reduces those other costs. A smaller model, an ordinary script or a person doing the task directly can also be the right choice.

A leaderboard helps me decide what to investigate. It doesn't tell me whether the ingredient survived an edit, or whether the system asks when a description is incomplete. I need to try the actual job.

That changes what I should be building. For this example, I would start with the restaurant's supplied information, show what changed and keep publication behind its approval. Generating more variations matters less than making a useful draft easy to check.

Responsibility for the result

Approval doesn't let me stop caring about mistakes.

Suppose the restaurant catches the invented ingredient. It should be able to correct the description without having to understand why a model put it there. And that correction should survive the next rewrite. Otherwise I have given the customer a recurring supervision job and called it assistance.

If the wrong version reaches the public menu, the problem gets more serious. Now someone has to find what was published, correct it and work out where the failure happened. The original information, proposed changes and approved version matter because they make that possible.

This is part of what I mean by taking responsibility for results. I can't promise that an AI system never makes a mistake. I can hold myself responsible for how my product handles one: whether the customer can see what happened, get help and recover their work.

“The model did it” would be a bad answer from the company that sold the service.

The customer bought from me. My choice of supplier is part of the job I took on, which means I need to think beyond how well that supplier performs today.

---

A supplier I can replace

Renting intelligence can be a good deal. I get a capability without buying the machines or operating them myself. But a provider can raise prices, change a model's behavior or retire the version a workflow depends on. It doesn't have to be malicious. Its priorities only have to stop matching mine.

I don't need a theory about who will win the model race to take that risk seriously. I need to know whether I could keep doing the customer's work if my current arrangement stopped making sense.

Changing an endpoint isn't enough. Another model may interpret instructions differently or use tools in a way that breaks the workflow. Keeping the documents and approval rules is necessary; checking that the replacement respects them is work of its own. A fallback needs to be tried on representative, non-sensitive tasks before I rely on it.

In the menu example, a successful switch would still produce accurate descriptions, preserve corrections and wait for approval. If it cannot do that, a lower token price isn't a reason to move.

I would rather spend effort understanding those limits than build a business that needs one lab to lead forever.

My own lock-in

This is where the argument becomes convenient for me.

I build AI products. If the durable value isn't simply access to a model, I have an obvious answer ready: the memory, workflows and integrations around it. The part I can build and charge for.

Some of that work really does help. Remembering the restaurant's correction means the owner doesn't have to make it again. Keeping track of approved changes means they don't have to reconstruct the menu from a conversation. There is a reason to pay for that.

But I could also make that accumulated work difficult to take anywhere else. Then every useful month with my service would make leaving more painful. From my side, that might look like a stronger business. From the customer's side, it would mean the records they helped create had become a reason they couldn't leave.

If I criticize one layer for trapping people, I cannot celebrate the same trap one layer up.

The question I need to sit with is whether they would stay if they could leave.

That takes away an easy explanation for why someone keeps paying me. A renewal could mean the service is valuable. It could also mean rebuilding elsewhere is more trouble than putting up with me. I shouldn't treat those as the same endorsement.

Giving someone their files doesn't make the services interchangeable. A new system may need setup, different permissions and a fresh check of the work. I can't remove every switching cost. I can refuse to make losing their history the price of cancelling.

---

A reason to stay

Suppose the restaurant can take its menu, corrections and approval history elsewhere. Another builder can use a capable model too. What is left for me to earn?

The next update still needs to be easier with my service than without it. The owner should be able to recognize the draft as their menu, see the changes that need attention and trust that approving one version won't publish another. When something goes wrong, they need help that starts with fixing the menu rather than explaining the model.

Those are reasons I would understand as a customer. They are also harder to claim than access to a new release. I have to keep doing the work well enough that someone values having me do it.

Some customers may prefer another service. Some may decide they can handle the task themselves. Making that choice possible means accepting that they may use it.

I still want to build a durable business. But I want to know that a customer who renews is choosing the service, not postponing the damage of leaving it.

I want customers to stay because the work is good, not because leaving means starting over.