The demo always works
Enterprise AI stalls in two places the pitch never mentions: the harness you didn't build, and the team that never picked it up.
By Patrick McGrath ·
The demo always works. That's what makes it dangerous. A vendor shows you an agent triaging a queue or drafting a policy, and it lands. You approve the pilot. Six months later the pilot is a tab nobody opens, the number on the spreadsheet hasn't moved, and the board wants to know what happened to the AI budget.
Nothing exotic happened. The pilot hit two walls, and neither of them is the model.
A model on its own is a gifted hire on day zero. No tools, no rules, no memory, no manager. It can reason, and almost nothing else. Everything that makes it dependable sits around it: the tools it can call, the gates that stop a bad output before it ships, the evals that say whether this week's version beat last week's. That scaffolding is the harness, and it is the part the demo skips.
Andrej Karpathy drew the two ends of this at Sequoia's AI Ascent in 2026. Vibe coding, he said, raises the floor: it lets almost anyone create software by describing what they want. Agentic engineering raises the ceiling, and he defined it as "the professional discipline of coordinating fallible agents while preserving correctness, security, taste, and maintainability."
His own example is the useful part. Karpathy's app MenuGen shipped a payment bug because the agent had identified users by email address instead of a persistent ID. The code was plausible and it was wrong, and the model is not the thing that failed. The specification was. That is the shape of nearly every stalled pilot we are brought in to diagnose.
Where we part company with that map is who it is drawn for. It is a developer's map. Inside a company, engineering rigor is necessary and not sufficient, because the second wall has nothing to do with code.
The tooling gets built. It works. The team doesn't use it. Support keeps answering tickets the old way, the analysts keep pulling the report by hand, and the thing you paid for runs in a corner while the work routes around it.
We watch for this because we came up in games, where you cannot ship a system players won't touch and call it a success. At June's Journey, a critical live-ops issue could take hours to close: manual data pulls, cross-referencing dashboards, escalating to a PM, waiting on an engineering fix. Building something to shorten that was the easy half. Getting the people who ran that loop every day to trust it over their own hands was the half that decided whether it was worth building.
A system your people don't use is not a smaller win. It's a loss that takes longer to show up on the invoice.
The pitch is always the model. The next one will be smarter, the story goes, and then this will work. It won't, for the same reason a faster engine doesn't finish a car.
The teams getting real value out of AI are not the ones with access to a better model. They built the harness once, and they got their people to use what it produces. Both halves, or neither one counts.