How do I tell whether an AI feature is genuinely custom or just a thin wrapper on a model?
Ask what happens without the model. If removing it leaves nothing, it is a wrapper. Real AI systems carry substantial engineering around the model: data pipelines that assemble context from your systems, validation of output, business rules, storage of results, and a feedback path. The model is a component. The integration is the product.
Wrappers are not automatically bad
A thin wrapper is a reasonable thing to build when the task genuinely is send text, get text. Drafting a reply, summarizing a document, rewriting a paragraph. If that is the need, paying for elaborate engineering around it is waste.
The problem is paying for custom-build engineering when wrapper work is what is needed, or expecting a wrapper to behave like an operational system. The distinction matters because the two fail in completely different ways.
Questions that reveal which one you are looking at
- Where does the context come from? If the only input is what a user typed, it is a wrapper. If the system assembles context from your CRM, job history and call records, that assembly is the actual engineering.
- What happens to the output? Displayed and forgotten is a wrapper. Validated, stored, joined to a customer record and acted upon is a system.
- What happens when the model is wrong? A real system has validation, confidence handling and a human path. A wrapper shows you the mistake.
- Can it be evaluated? If there is no way to measure whether output quality is holding steady over time, nobody is managing quality.
- Does it improve with your data? Not necessarily training — rules, examples and rubrics tuned to your business count.
The part people underestimate
In most useful AI applications the model call is a small fraction of the work. Getting the right data to the model, in the right shape, at the right moment, is most of it — and that is ordinary integration engineering, not machine learning.
This is why an AI feature that reads only what a user pastes in is so much cheaper than one that knows your customer history. The second one requires that your systems be connected, which is a prerequisite most organizations have not met. That prerequisite is the entire premise of operational AI as distinct from generative tools.
A practical way to judge a proposal
Ask to see what the system sends to the model and what it does with the response. If nobody will show you, that is an answer. If they show you and it is a short prompt with the user's text pasted in, you now know what you are buying.
Also ask how output is checked before it reaches a person or a record. Systems that write into your operational data need validation the way any other write path does. That standard is what separates a demo from something you can run a business on, and it is how model integration should be evaluated regardless of who builds it or which model is underneath.
Topics: ai development · evaluation · vendor selection · architecture
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.