Every AI demo looks the same. Someone types a prompt. Something impressive comes out. The presenter smiles. You, the SMB owner, leave the room thinking: okay, but how do I use that in my actual business?
The honest answer — the one most consultants won't tell you because it isn't what they sell — is that the gap between a demo and a system that runs your business is enormous. It's not a matter of prompt engineering. It's not a matter of buying the right platform. It's the part of the work that demos, by design, never show you.
I've been on both sides of this. I spent years leading AI implementations at Fortune 100 companies through Accenture, where the gap was manageable because there were enough bodies and enough budget to throw at it. Then I went to build and run Tumble, and the gap got personal. I shipped roughly a dozen AI agents inside Tumble — for marketplace balancing, retention, dispatch, support, even a vision model that reads laundromat price boards from photos — and every single one of them taught me something different about what's in the gap and how to cross it.
What follows is the short version of what I'd tell any SMB owner who's watched a demo and is trying to figure out if there's a real thing on the other side of it.
The gap, briefly
A demo is: we feed the model a clean prompt and it produces something impressive.
A system is: we read data out of your existing stack, send it through a model we can reason about and replace, act on the result in a way that doesn't break when it's wrong, tell a human about the weird cases, and log the whole thing well enough that you can trust it next week.
Both of those are "AI." Only one of them runs your business.
What's actually in the gap
Here's what demos leave out. Some of these will sound obvious, and some of them are the things that kill projects that "should have been easy."
1. The data isn't clean
Every demo uses a prepared example. Your business doesn't have prepared examples. It has a ticket that was typed with one thumb on a Tuesday night by someone who was tired. It has a field labeled "notes" that's been used for seventeen different things over four years. It has a CSV export whose column order changed three months ago and nobody updated the import.
A production AI system has to deal with the data you actually have, not the data the demo assumed. That's usually 40% of the work, and it's the part that has no demo.
2. The model is not the whole system
In the marketplace balancing work we did at Tumble, the "model" — the part that actually forecasts demand or picks an intervention — is maybe 15% of the code. The other 85% is: reading the current state of the marketplace, deciding when a gap is large enough to act on, picking which of several interventions to run, handing off to a sub-agent that knows how to execute, watching what happened, feeding that back.
The model is a component. The system is everything around it, and the everything-around-it is where production AI lives.
3. Failure modes matter more than happy paths
The first question every serious AI engagement should answer isn't "what does this do when it works?" It's "what does it do when it's wrong?"
A good production system has answers: confidence thresholds, human review for low-confidence cases, escalation paths for the weird stuff, rollback if a decision turns out to be bad. Every agent we built at Tumble had escalation paths in the design from day one, not bolted on after the first incident. That is not the exciting part of the work, and it is the part that makes the difference between a system your team trusts and a system they turn off.
4. It has to live in your stack, not a separate one
If "the AI" is a separate platform with its own dashboard and its own login, you have two problems: you have to maintain it, and your team has to remember to check it. Both of those are projects in themselves.
The AI systems that work are the ones that live where your team already lives. In your ticketing system. In your existing messaging stack. In your warehouse or your CRM. The best version is the one your team doesn't have to think about — it just quietly does more of the work than it used to.
5. Someone has to own it after the vendor leaves
This is the part most consulting engagements never address. The vendor ships the thing, does the demo, hands over some documentation, and leaves. Six months later something breaks, and nobody on your team knows enough about the system to fix it or even to know what broke.
Every agent we built at Tumble was built with the assumption that the people who'd operate it forever weren't me. We wrote things down. We kept the architecture simple enough that it could be extended by an engineer who hadn't been there when it was built. We deliberately turned away from the exotic options even when the exotic options would have been a little more interesting, because maintainability was worth more than cleverness.
What this means if you're an SMB owner thinking about AI
You don't need to become an AI expert. You need to hire — or talk to — someone who's actually been on the operator side of one of these projects and lived with the result. The questions to ask are not about model choice or prompt design. They're:
- How does this integrate with the systems we already run?
- What happens when it's wrong?
- Who owns it once you leave?
- How would we know if it's not working anymore?
If you can't get clear answers to those four, you don't have an AI project. You have a demo.
Clarified Consulting exists because I wanted there to be a firm that answered those questions honestly — one that had actually run a business before it gave advice about how to run yours. If any of this sounds like a problem you're trying to solve, the first call is free.