The Wrapper Problem — Datura Labs

A wrapper is not a company that uses a frontier model. Everyone does. A wrapper is a company whose product is the model’s capability with nothing owned underneath it — and whose success is therefore a cost line on someone else’s income statement.

By VK Singh Vashisht — Datura Labs

I have evaluated AI companies whose unit economics got worse with every customer they won. Not worse in the ordinary early-stage way, where scale eventually fixes the margin. Structurally worse, because the cost of serving a customer was a price set by a vendor the company did not control, and the value delivered to the customer was that vendor’s capability, and the company’s margin was whatever sat between the two — a number the vendor could move to zero with a pricing change or a feature release. The market was real. The team was competent. The company’s own success would have made it unprofitable.

That is the wrapper problem, and I think it is the defining failure mode of this cycle — not because wrappers are stupid, but because the thing that makes them fail is invisible at the moment they look best.

The steelman

Wrappers are not a dumb idea. Give the case its due.

Frontier models are general. Users are specific. The gap between “a model that can do anything” and “a tool that does my thing, in my workflow, with my vocabulary” is real, and closing it is real work. Vertical interfaces have always been valuable — nobody calls a tax-preparation product a wrapper around arithmetic. Distribution is a moat in every other software category; why not this one? And the empirical record is not empty: companies built on a rented model, with a good interface and a fast go-to-market, have reached revenue that would have taken a decade a cycle ago.

Who benefits from the case being told this way? Venture funds, whose cadence needs companies that can show revenue inside a fund’s life, and a wrapper shows revenue faster than anything else ever built. Founders, because speed is the honest reason to build one. And the model labs most of all, because every wrapper is demand for their product, and a wrapper ecosystem is the best sales force a lab could design.

Where it breaks

The flaw is in the word “moat.” The steelman’s moats — interface, workflow fit, distribution — are all rents on cognition being expensive: somebody had to figure out the prompt, the flow, the vocabulary, the edge cases. That figuring-out is exactly what the next model generation absorbs. The vertical interface that took a year to design becomes a paragraph of instructions to a model that is better at the vertical than the interface was. The workflow becomes a feature of the platform the workflow was built on. Distribution survives, but distribution of what? A product whose substance the vendor now ships natively.

Then look at the margin. A wrapper’s cost of goods is the vendor’s price. Its revenue ceiling is the vendor’s capability. The vendor sets both bounds and has every incentive to move them toward each other — lower price to grow the market, higher native capability to own it. The wrapper lives in a band that its supplier is contractually and strategically committed to compressing. This is not a risk to be managed. It is the structure.

And underneath both, the data flows the wrong way. Every interaction a wrapper mediates is training signal for the vendor and a customer record for the wrapper — and the customer record, in most wrappers, is held in the vendor’s context, not the wrapper’s store. The one asset that could have become possession is being handed upward with every call.

The possession test

Here is the screen, and it is one question.

If the model vendor released your product as a feature tomorrow, what would you still own?

If the answer is a user list and a brand, you are a wrapper, and the user list is the only real asset, and it is worth exactly what it costs the vendor to acquire the same users through a feature announcement. If the answer includes records the vendor does not have, a workflow the customer runs on hardware the vendor does not touch, a verification layer that produces receipts the vendor’s feature cannot produce, or an operating relationship in which the customer’s own history is the input — then you are not a wrapper. You are a company that rents intelligence, which is a different thing entirely, because the intelligence is the one part you should rent.

That last point is the one the discourse gets backwards. The mistake is not renting the model. The mistake is renting the product. A firm that builds directly on frontier models, treats the model as swappable, and owns everything the model is pointed at — the ingest, the corpus, the rules, the receipts, the record of every run — is not exposed to the vendor’s roadmap. It benefits from it. Every model improvement makes the owned layer more valuable, because the owned layer is what the improved model now reads. A wrapper is exposed to the same improvement, because the improvement is the thing it was selling.

What this means in practice

For the investor, it means the diligence question is not “how good is the product” — the product is the vendor’s, and it will be better next quarter regardless. The question is what the company possesses that the vendor cannot ship. Read the architecture, not the demo. Where does customer data live? Whose hardware? What does the company have on day 400 that it did not have on day one, that the vendor does not also have? If the honest answer is “more users,” the growth curve is a liability schedule.

For the builder, it means designing the possession layer first and the interface last, which is the opposite of how a wrapper gets built. The interface is the part that converges. The corpus, the cadence, the receipts, and the customer’s own record are the parts that compound. Build the thing the model reads, not the thing the model is.

For Datura, it is why the firm’s own machines are configured the way they are: the intelligence is rented and swappable, and everything else — deterministic ingest, change detection, a written rubric, a ranked digest, a receipt on every run, and the client’s corpus on the client’s hardware — is owned, in open formats, by whoever is paying for it. The vertical is configuration; the machine is the asset. Nothing in that sentence depends on which model is behind it this month.

The bet

My bet is that the wrapper cohort of this cycle resolves the way the on-premise-to-cloud middleware cohort resolved: a handful survive by becoming genuine possession businesses — records, workflow, distribution that actually locks — and the rest are absorbed as features or run out of margin quietly, without a single dramatic failure, because a company whose margin is being compressed by its supplier does not blow up. It just stops being able to raise.

What would prove me wrong is inference cost falling faster than native capability rises. If model pricing collapses toward zero while the labs stay general and leave the verticals alone, a wrapper’s cost problem disappears and its interface rent gets a long tail. That is possible; it is what happened to some categories of internet middleware. I do not expect it, because the labs have shown no intention of staying general and every intention of owning the verticals with the best margins. But it is the falsifier, and it is the reason the possession test asks what you own rather than what the model costs.