AI due diligence · Vendor claims · Technical DD

Is the AI real, or a wrapper? A technical due diligence guide

Every AI product is a wrapper. That is not the question. The question is whether anything defensible lives between the model and the customer - and you can only answer it by reading the system.

Aug 18, 2026

Somewhere in the second meeting of almost every AI deal, someone asks the question the whole room has been circling: is this real AI, or just a wrapper on ChatGPT?

I understand why the question gets asked. Valuations for "AI-native" companies carry a premium, and nobody wants to pay a technology multiple for a prompt. But as a diligence question it is badly formed, because it treats "wrapper" as a binary when it is actually an address. Every AI product wraps a foundation model - the honest ones and the pretenders alike. Nobody outside a handful of labs trains frontier models, and choosing not to is usually the correct engineering decision. The useful question is not whether the product wraps a model. It is where the defensible engineering lives, and whether the price you are about to pay assumes more of it than exists.

I have sat on both sides of this. I have shipped agentic AI into production trading workflows at a regulated venue, where "the model decided" is not an acceptable answer to anyone, and I read codebases for a living when investors want the claims checked. What follows is the shape of that check: what I look at, what a real system looks like from the inside, and what a thin wrapper looks like when it is dressed up as one.

The layers, from cheapest to hardest to copy

When I open an AI product, I am mentally sorting everything I find into five layers. They differ enormously in how fast a competent team could replicate them.

The prompt layer. System prompts, templates, few-shot examples. This is where thin products live. It is real work, but it is days-to-weeks of work, it leaks through the API to anyone who probes it, and it is portable to any competitor with the same model access.
Orchestration. Retrieval, tool use, routing between models, state management, agent loops, human checkpoints. This is months of engineering and it encodes actual product decisions. It is where most genuine differentiation in applied AI currently sits.
The evaluation harness. Regression sets built from real failures, scoring pipelines, gates that stop a bad prompt or a new model version reaching customers. This is the layer that tells you whether the company can change anything safely. It is also the layer most often missing entirely.
Data. Not "we have data" - data that is proprietary, permissioned, refreshed by product usage, and demonstrably improves output quality. Most claimed data moats fail at least one of those four tests.
Distribution and workflow. Being embedded where the work happens, integrations that took quarters to certify, a sales motion the model cannot commoditise. Not a technology layer at all, which is precisely why it survives model churn.

A wrapper, properly defined, is a product whose value is concentrated in layer one while its valuation is priced as if it lived in layers two to five. That mismatch - not the architecture - is the diligence finding.

What a real system looks like from the inside

These are the signals I weight most heavily when the repo is open, roughly in the order I go looking for them.

An eval suite that has clearly been used in anger. Regression cases named after real incidents. Scores tracked over time. A gate in CI that blocks deploys on regression. When I ask "how do you know the new prompt is better", the answer is a dashboard, not a shrug.
A story for model migration. Models get deprecated on the provider's schedule, not yours. A real team can tell you what happened last time they moved versions, what broke, and what the eval suite caught. A thin one has never migrated and has no mechanism to do it safely.
Guardrails and fallback paths. What happens on a malformed model response, a timeout, a refusal, an answer outside the allowed range? In production systems, the unhappy path is most of the code. In demos, it does not exist.
Observability and audit trails. Can they reconstruct what the system did for a specific customer last Tuesday - the inputs, the model calls, the outputs, the decision? In regulated markets this is a legal requirement arriving on a schedule; I wrote up the mechanics in a separate piece on agent observability, and the diligence version of that argument is in how to audit AI agents. A system with no trace is a system whose behaviour you are taking on faith.
Cost engineering. Caching, model routing by task difficulty, batching, token budgets per feature. Gross margin in an LLM product is an engineering artefact. If nobody can tell me cost per request by feature, nobody is managing it.

And the mirror image, the wrapper tells: a system prompt in a trench coat, with the orchestration doing little more than string interpolation. No evals at all - the most common single finding. Behaviour that is polished on the demo path and unhandled everywhere else. No answer for model deprecation. Unit economics that die if token prices move against them or the provider changes rate limits. None of these is exotic; you find them by reading, not by genius.

Two hours off the demo path

You do not always get the repo on day one, but you can learn a lot from a supervised session with the product if you refuse to follow the demo script. My standard two hours looks like this: feed it inputs from the edges of the claimed domain, not the centre. Give it ambiguous cases where the correct behaviour is to ask or decline, and see whether it confabulates instead. Push adversarial input - instructions embedded in the data it processes - and watch whether the system or the demo driver flinches. Ask the same question five times and look at the variance. Ask for something the marketing page says it does, but the demo never shows.

A real system degrades politely at its edges, because someone has been there before you and left handling code behind. A demo-shaped product falls off a cliff, and the founder reaches for the keyboard to steer you back to the happy path. That reach is a finding. Arvind Narayanan's AI snake oil framing is a decade of this pattern condensed: the gap between what is claimed and what is checkable is where the risk lives. Vendor-claim red flags follow the same grammar in security - Scylla's list is written for CCTV analytics and reads perfectly well for LLM products.

The rebuild test, answered honestly

The question investors actually care about compresses to: could a good team rebuild this on off-the-shelf models in a quarter? For the prompt layer, the answer is always yes. For orchestration plus a mature eval harness, usually no - not because any single piece is hard, but because the regression sets and the failure handling encode a year of contact with reality that a fast follower has not had yet.

But here is the part that gets missed when the wrapper question is asked as a gotcha: sometimes the honest answer is "yes, they could rebuild it, and it would not matter". A product that is replicable at the technology layer can still be a fine business if the moat is workflow lock-in, certified integrations, a data flywheel that is actually spinning, or plain distribution. Thin wrappers are not automatically bad investments. Mispriced ones are. The diligence job is not to sneer at the architecture; it is to make sure the multiple being paid matches the layer where the value actually sits. If the deck says "proprietary AI" and the repo says "prompt plus distribution", the price chip is on the word proprietary, not on the business.

For agentic products there is one more turn of the screw, because autonomy adds a risk layer that static LLM features do not have - tool access, action authority, and a new attack surface that the OWASP Top 10 for Agentic Applications now catalogues. An agent that is a wrapper is a much bigger problem than a chatbot that is a wrapper, because it is a thin system that has been handed credentials.

This piece is one of three I published together: the AI due diligence checklist is the structured version of everything above, and how to audit AI agents covers the audit-trail side in depth.

What I would tell a deal team

Stop asking whether it is a wrapper. Ask where the engineering lives, get someone to actually read the system, and price the answer. The read takes days, not weeks. It routinely moves valuations by more than it costs, in either direction - I have seen it kill technology premiums, and I have seen it justify them, which is the outcome founders with real systems should actively want from diligence.

Sources

I do technology and AI due diligence for investors and acquirers through Trustflux Ltd - evidence-backed findings with explicit assumptions and confidence levels, from someone who has shipped agentic AI in production at a regulated trading platform. If you have an AI claim you want verified before a term sheet, that is the practice.

Written with Claude Code. The repo read is the artefact; the article is the method.