There is a pattern playing out in AI right now that should worry a lot of founders and fascinate everyone else. A startup spots a gap, builds a clever feature on top of a foundation model, and gets traction. Then, a few months later, the company that makes the model ships that exact feature natively, and the startup discovers it was never building a product so much as keeping a seat warm. Call it the wrapper trap, and once you see it you cannot unsee it.
This is an opinion piece, and it ends somewhere genuinely strange: with the question of whether we will need most software at all. Stay with me, because the logic is cleaner than it first sounds.
The graveyard of absorbed features
Start with the evidence, because the pattern is already well documented in the short history of this technology.
Perplexity built a real business by bolting live web search onto a language model, and for a while that was a genuine edge over a model that only knew its training data. Then web search became a native feature inside ChatGPT and Claude, and the moat narrowed overnight. The same happened with writing tools. A wave of startups wrapped models to generate marketing copy and blog posts, and then the base models simply got good enough that the wrapper added little. Image generation used to mean opening a separate specialist tool. Now you ask for an image inside the same chat window you use for everything else.
The pattern accelerated as the labs moved up the stack. Anthropic shipped Claude Code, absorbing much of what standalone AI coding tools were selling. It shipped Artifacts, swallowing the idea of a separate canvas for generated work. It added Connectors and embraced MCP, pulling the integration layer into the model’s own orbit. It launched Cowork, reaching into the agentic-workspace territory that a dozen startups were racing to own. OpenAI and the others have done the same in their own ways. Each time, a category that looked like a product turned out to be a feature the model had not gotten around to yet.
Why this keeps happening
The mechanism is not mysterious. If your product is mostly a prompt plus a thin interface, you are building on land your supplier owns, and your supplier can build the same thing with better economics, better distribution, and the model itself in house. You are competing with the company that sells you your core ingredient, and they can give the feature away to make their platform stickier while you have to charge for it to survive.
There is a deeper reason too. Many of these features were really just the model’s latent capability waiting for a convenient wrapper. The wrapper was a workaround for something the model could almost do but had not been wired to do yet. The moment the lab wires it in directly, the workaround has no reason to exist. The startups were, in a sense, doing unpaid product research for the labs, mapping out which capabilities people wanted enough to pay for, which the labs then shipped.
The distinction that decides who survives
This is the point where the honest version of the argument matters, because not everything on top of a model is a doomed wrapper. The companies that survive the absorption have something the model cannot easily swallow.
Proprietary data is the clearest example. A model can generate legal text, but it cannot absorb a firm’s decades of private case outcomes. Deep workflow is another. A tool woven into how a specific industry actually operates, with all the messy edge cases and integrations and compliance baked in, is far harder to replicate than a clever prompt. Trust and accountability matter in regulated domains where someone has to be responsible when things go wrong. And distribution into a hard-to-reach audience can be a moat in itself.
The simple test is to ask what is left of your product if the underlying model improves by another order of magnitude. If the answer is nothing, you have a wrapper. If the answer is your data, your workflow depth, your relationships, or your accountability, you have a business. The middle ground, generic software whose only real ingredient is access to a model, is the dangerous place to stand.
The bigger idea: why have software at all?
Here is where it gets interesting, and where the wrapper pattern points at something larger than startup strategy.
Step back and ask what most software actually is. A great deal of it is a frozen set of decisions about how to turn data into action through a fixed interface. A CRM is a database of customers wrapped in forms and buttons that someone designed years ago. A dashboard is a set of queries someone wrote, rendered as charts. An internal tool is logic plus a screen, built so a human can manipulate data the computer could perfectly well manipulate itself. The software exists because, until now, data could not interpret itself or act on its own, so we built rigid layers of interface and logic to bridge the gap between raw data and human intent.
Now imagine that gap closes. Imagine your data is well described, with rich metadata, clear semantics, and a shared context layer that explains what everything means and how it relates. And imagine an intelligence that can read that context, reason over it, and take action through standard connectors. At that point, a lot of the software in the middle stops being necessary. You would not open a purpose-built app to filter and chart your data, you would ask a question and get the answer, with the interface generated on the spot if you needed one at all.
This is the thread that ties the wrapper pattern to the future. The labs are not only absorbing features, they are slowly assembling the pieces of a world where the application layer itself becomes optional. MCP and connectors are the plumbing that lets a model reach data and tools. Artifacts hint at interfaces generated on demand rather than built in advance. The direction of travel is toward intelligence that runs on well-described data, rather than software that sits between you and your data.
The OSI parallel
The closest analogy is networking. Before the OSI model and the standards that followed, connecting two different computers was a bespoke nightmare, and every pairing needed custom work. A layered set of agreed standards changed that, so any machine could talk to any machine because they shared a common stack of meaning at each level. That standardization is what made the internet possible, and it is what turned networking from a project into a utility.
We are at the very beginning of building the equivalent for context and meaning. MCP is one early layer, a standard way for intelligence to reach tools and data, which is why I argued recently that MCP is the new API. Above and around it, the harder work is in describing data itself: shared semantics, metadata, and ontologies that let a model understand what a field means, how records relate, and what an action implies, without a human hard-coding all of that into an app. When that stack matures, software stops being the thing you build to use your data and becomes, at most, a thin and often generated surface over it.
What this looks like in practice
Play it forward and the shape of things shifts. Dashboards become questions you ask of your data rather than screens someone maintains. Most internal tools, the endless CRUD apps companies build to let staff poke at a database, quietly disappear, because the database can be addressed directly in plain language by something that understands it. The interface stops being a fixed artifact and becomes ephemeral, assembled for the task in front of you and discarded after, which is exactly what generated artifacts gesture at today.
The durable layers in that world are few. There is the model, which is becoming a commodity substrate. There is the data, which is where real, defensible value concentrates. There is the context and standards plumbing that lets intelligence operate on the data safely. And there is trust and governance, the layer that decides what the intelligence is allowed to do and proves what it did. Notice what is missing from that list: the vast middle of generic feature software that exists only because data could not previously act on its own. That middle is what thins out. The agents that will live in this world are already taking shape, as our guide to the best AI agents shows, and the early tools for building software by describing intent rather than coding it appear in our look at the best AI app builders.
Where this argument breaks down
Now let me push hard against my own thesis, because the clean version hides some genuinely difficult problems.
The biggest is that data is almost never well described. The dream of intelligence running on clean, semantic, fully documented data runs straight into the reality that most organizational data is a swamp of inconsistent fields, undocumented assumptions, and tribal knowledge that lives in people’s heads. The phrase “if only the data were well described” is carrying enormous weight, and closing that gap is the work of years, maybe decades. Software has historically been the place all that messy context got encoded, and you cannot delete the encoding without first capturing what it knew.
Reliability is the second problem. A lot of software does jobs where mostly correct is not good enough. You cannot have an intelligence that approximately runs payroll, or probably applies the right tax rule, or usually moves the money to the right account. Deterministic, auditable, guaranteed behavior is exactly what rigid software provides and what probabilistic models struggle to promise. For a large class of tasks, the boring guarantees of traditional software are the feature.
Then there are the practical drags: latency and cost when intelligence sits in every interaction, regulation that demands specific controls, the very long tail of real-world integrations that resist standardization, and the simple fact that humans sometimes prefer a familiar interface to a conversation. Software does not vanish in this future. It migrates and it thins, with the wrapper layer dying first and the data, workflow, and trust layers surviving and growing.
What to actually do about it
If you build products, the lesson is to stop building thin wrappers and assume the model will absorb anything that is only a prompt and a screen. Build instead on something the model cannot eat, which almost always means proprietary data, deep workflow, or genuine trust and accountability. Treat the foundation model as a commodity substrate you rent, not as your secret sauce.
If you run an organization, the most valuable preparation is unglamorous: get your data into shape. The companies positioned to win when intelligence can run directly on data are the ones whose data is clean, well described, and richly contextualized, because they will be ready to point intelligence at it while everyone else is still untangling spreadsheets. The investment that looks like boring data hygiene today is the foundation of the agent-driven future.
The bottom line
Foundation models keep eating the features built on top of them, and the pattern is not slowing down. The deeper truth underneath the wrapper trap is that a great deal of software exists only because data could not previously interpret or act on itself, and that assumption is dissolving. As context standards mature and intelligence learns to operate directly on well-described data, the application layer in the middle gets thinner, and the durable value moves to the data, the standards, and the trust around it. We are nowhere near the end of software, because messy data and the need for reliability will keep it alive for a long time. But the direction is set. The question worth asking about anything you build or buy is no longer just whether it works today, but whether it is a wrapper waiting to be absorbed, or one of the few things the model can never swallow.
