Why Does the Same AI Stack Produce Different Results at Two Companies?

Two companies buy the same model, the same orchestration layer, and the same seats. One gets a measurable lift. The other gets mediocre output, decides AI is overhyped, and quietly stops renewing. The variable is not the technology. Both had the same technology.

The way I have said it on record for two years: AI is like electricity. Everyone has access to power. What matters is how the power is applied. You can run a city or you can run an electric chair. Same current.

The differentiator is not the AI tech. It is the domain expertise of the human applying the AI tech.Jonathan Kvarfordt, on the New Workings podcast

Why the model stopped being the moat

Frontier capability is now purchasable in a browser tab. When capability is democratized, and it should be, the advantage moves to the layer that is not purchasable: how well you understand your own systems, your own process, and your own buyers. That layer is slow to build and impossible to buy in a demo.

This is the practical form of the proof gap. Teams that publish a real result almost always did the unglamorous work first. Teams that publish a story usually skipped it and hoped the vendor covered the difference.

Where the gap actually opens

• Definitions. If two managers describe the same pipeline stage differently, the model inherits both descriptions and averages them into nonsense.
• Process. Speed up a bad process and you get more bad output, faster. The AI is doing exactly what you asked.
• Domain knowledge in the prompt. A generic prompt returns a generic answer. Your five-year understanding of why deals in Latin America stall in procurement is the asset. Most teams never write it down, so the model never sees it.
• Ownership. Someone has to be accountable for the workflow, not just for the license. Without that seat, quality drifts and nobody notices until renewal.
• Feedback. If you cannot tell whether output improved, you cannot improve it. Most teams measure usage and call it adoption.

The mediocrity loop

The failure pattern is consistent. A team applies AI casually, gets mediocre output, mediocre output produces mediocre results, and the team concludes AI is not worth the time. The conclusion is wrong and the experience is real. The tool was never the constraint. The input was.

I can name ten companies applying the same underlying model who get very different results. If the technology were the variable, that spread would not exist.

What to do about it before the next purchase

1. Write down the process you are about to automate. If it cannot be written in one page, it cannot be handed to an agent.
2. Name the outcome first, then work backwards to the tool. Average sale price, ramp time, churn risk. The tool is chosen last, not first.
3. Put the domain expert in the prompt loop. The person who knows why deals die should be shaping what the model looks for, not reviewing a summary of it later.
4. Set a kill criterion before launch. See kill criteria. An initiative with no failure condition never fails, it just persists.
5. Measure output quality, not logins. Usage is an input. Behavior change is the result.

The uncomfortable part

Domain expertise is not a purchase order. It is the accumulated understanding of how your revenue engine actually behaves, and most teams have it distributed across people who were never asked to write it down. The teams pulling ahead did the boring work of documenting systems, process, and definitions, then pointed AI at that. The teams throwing AI at a problem and hoping it resolves are producing the case studies we later file under rollback.

Access is equal. Application is not. That is the whole story.