Thinking ·
What is an AI wrapper?
Short answer
An AI wrapper is a product whose core value comes from a prompt and an interface built around a general-purpose model it does not own or train. The useful test is not whether a product wraps a model — nearly all of them do — but whether anything accumulates underneath: proprietary data, a measurable evaluation set, or workflow the vendor could not rebuild for the next customer from scratch.
“It’s just a wrapper” is the most common objection raised in AI procurement meetings, and one of the least useful. It is usually correct and almost never decisive.
The definition
An AI wrapper is a product whose core value comes from a prompt and an interface built around a general-purpose model the vendor does not own, train or meaningfully control. The model does the cognitive work. The vendor supplies the packaging: a user interface, some prompt engineering, an integration or two, and a bill.
The term is usually deployed as an insult. It is more useful as a measurement.
Why “just a wrapper” is a lazy objection
Almost every piece of software wraps something. Your CRM wraps a database. Your payments provider wraps a card network. Stripe is, in the least generous reading available, a wrapper around banking infrastructure that already existed — and nobody argues Stripe has no moat.
Packaging is real work. Turning a general capability into something a non-expert can use safely, repeatedly, inside an existing workflow, is most of what software has ever been. Dismissing that as “just a wrapper” tells you the speaker is annoyed, not that the product is thin.
The question is not whether a product wraps a model. It is whether anything accumulates underneath.
What separates a wrapper from a product
Four things can accumulate. A product has at least one of them and can show you evidence. A wrapper has none and talks about roadmap instead.
1. Proprietary data you could not obtain yourself
Not “we have access to public filings.” Data that is genuinely hard to assemble — licensed exclusively, accumulated over years, or labelled by people with domain expertise. If you could buy the same dataset on the same terms, it is not their moat, it is a line item.
2. Evaluation evidence on your kind of task
A vendor that can state its error rate on a task resembling yours has done engineering that a prompt in a text box has not. A vendor that answers with demos and testimonials has usually not built an evaluation set, which means they cannot tell you when they get worse — and neither can you.
3. A loop that improves with use
Does the product get better for you as your team corrects it? Or do the corrections evaporate at the end of each session? A stateless tool is useful the tenth time in exactly the way it was useful the first. That is a tool, not a compounding asset — and it is worth tool money.
Watch for the version where it improves for everyone, including your competitors. That is a real loop, but the value accrues to the vendor, not to you.
4. Workflow depth that is genuinely expensive to rebuild
Owning the edge cases, the exception handling, the ugly integrations with systems that have no API. This is the least glamorous moat and often the most durable, because it is boring enough that nobody wants to rebuild it.
The swap test
The fastest single question, and the one worth asking in writing: if the underlying model were swapped for a different frontier model tomorrow, how much of this product would still work?
- “Almost nothing” — the model is the product. You are paying the vendor for prompts.
- “Most of it, quality would dip” — some engineering exists, but it is thin.
- “All of it, we route between models” — there is a real system here.
- “We fine-tune on our own data” — assuming it is true, ask to see the evaluation that proves it helps.
The answer matters less than the manner. A vendor with substance answers immediately and specifically, because they are proud of it. A vendor without substance changes the subject to their roadmap.
When buying a wrapper is the right call
Frequently. If the capability is not where you compete, if your team is genuinely constrained, and if the price reflects packaging rather than a moat — buy it, on a short term, and stop worrying about it. Speed has value. Not everything needs to be an asset.
The failure is not buying a wrapper. It is paying moat prices for wrapper substance, or accepting multi-year lock-in for something you could replace in six weeks. Thin product plus hostage terms is the combination that actually costs money.
Most organisations get this backwards. They build the commodity plumbing, because it is satisfying, and they rent their differentiator, because it is fast.
What to do with the answer
“I think it’s a wrapper” loses arguments. A score against a published rubric, with the weaknesses named and the contract terms to demand, wins them — because it reads as analysis rather than as the engineer’s opinion.
That is what the Wrapper Test is for. Twelve questions across substance, ownership, lock-in and what it would honestly cost you to build. The weights and thresholds are published so anyone who disagrees can say exactly where.
Common questions
- What is an AI wrapper?
- A product whose core value comes from a prompt and an interface around a general-purpose model it does not own or train. The model does the work; the vendor supplies packaging.
- Is being an AI wrapper bad?
- Not automatically. Packaging is real work and most software wraps something. It is only a problem when the price assumes a moat that does not exist, or the contract creates lock-in the product has not earned.
- How can you tell if a product is just a GPT wrapper?
- Ask what still works if the underlying model is swapped for a different one tomorrow. If the answer is "almost nothing", the model is the product and the vendor is selling packaging.
- What is the difference between an AI wrapper and an AI product?
- A wrapper resets to zero after each use. A product accumulates — proprietary data, labelled corrections, an evaluation set — so it gets measurably better at a specific job over time.