Most enterprise AI investments fail not because the underlying model was wrong, but because the layer they built on top of the model was wrong.
The distinction is architectural: a wrapper adds value on the model layer. A platform adds value on the integration layer. The model layer depreciates with every new model release. The integration layer compounds with every month of production use.
Teams that understand this distinction invest in data pipelines, workflow embedding, evaluation infrastructure, and governance — the components that persist when the foundation model is replaced. Teams that miss it spend their budget on prompts, formatting, and thin UX — the components that evaporate when the next model release does natively what the wrapper did with engineering effort.
The wrapper failure is not a theory. It is a pattern that repeats whenever an AI system’s value proposition lives entirely on the model side of the architecture boundary.
| Dimension | Wrapper | Platform |
|---|---|---|
| Value source | Prompt quality, formatting, model-side UX | Data integration, workflow embedding, evaluation loops, governance infrastructure |
| Model dependency | High — value requires the wrapper to outperform the raw model | Low — value comes from the integration layer, which is model-agnostic |
| Depreciation rate | Fast — each model generation closes the gap the wrapper was designed to fill | Slow — integration depth accumulates and is not replicated by switching models |
| Integration depth | Thin — sits above enterprise data and workflows, does not own pipeline or evaluation | Deep — owns data pipelines, workflow entry points, evaluation suites, governance gates |
| What persists when model changes | Little — prompts, formatting, and surface UX must be rebuilt around new capabilities | Most — pipelines, workflow hooks, evaluation sets, governance controls carry forward |
from pydantic import BaseModelfrom typing import Literal
class AIInvestmentAssessment(BaseModel): system_name: str value_source: Literal["prompt_layer", "integration_layer", "mixed"] model_dependency: Literal["high", "medium", "low"] integration_dimensions_present: list[Literal["data", "workflow", "evaluation", "governance"]] persists_on_model_swap: bool depreciation_risk: Literal["high", "medium", "low"] investment_verdict: Literal["wrapper", "platform", "wrapper_at_risk_of_depreciation"]Why Wrappers Depreciate
A wrapper is defined by its position in the architecture: it sits between the application and the foundation model API, adding value through prompt engineering, output formatting, context assembly, or surface-level routing.
That position is structurally fragile.
The value a wrapper provides today is a function of the gap between what the raw model does and what the enterprise needs. That gap can be real at the time the wrapper is built. It shrinks as model capabilities improve. When the gap closes — when the model can reliably handle context assembly, output formatting, and domain-specific reasoning without bespoke prompt infrastructure — the wrapper has no remaining architectural role.
This is the depreciation mechanism: the wrapper’s value is a bet that the model will not improve on the exact dimensions the wrapper is compensating for. That bet has a predictable failure mode.
The teams most at risk are those that built early and moved fast: their systems look sophisticated because prompt engineering is genuinely hard. But prompt sophistication is not integration depth. It is technical work that addresses the gap between model capability and enterprise need — a gap that the model vendors are actively closing.
What Integration Depth Actually Means
Integration depth has four concrete dimensions. The distinction between a wrapper and a platform is whether those dimensions are owned by the system or delegated to the model.
Data pipelines. A platform connects to enterprise data at the source: internal databases, document repositories, operational systems, event streams. It owns the ingestion, normalization, and refresh cycles for that data. The connection is not a retrieval call made at inference time — it is a persistent data pipeline that the system maintains and can audit. When the foundation model changes, the pipeline carries forward.
Workflow embedding. A platform enters business workflows at real decision points: approval gates, routing logic, escalation paths, operator handoffs. It does not sit as an optional add-on that users can consult. It is a required node in workflows that the organization depends on. The workflow embedding creates switching cost that is organizational, not technical. Replacing the model does not remove the system from the workflow.
Evaluation loops. A platform measures its own outputs against the outcomes it is supposed to produce. It has an evaluation suite: test sets built from real production data, operator correction signals from downstream steps, automated regression checks that run before deployment. Evaluation infrastructure accumulates value over time — the test sets get richer, the correction loops get tighter, the failure taxonomy gets more precise. A wrapper typically has no evaluation layer; it depends on user correction as a proxy for system quality.
Governance infrastructure. A platform has controls proportionate to its authority: approval gates before write actions, logging sufficient for incident investigation, rollback procedures that have been tested, ownership structures that survive personnel changes. Governance infrastructure takes time to design correctly and is invisible to competitors evaluating the system from the outside. It is also the component most likely to be missing in wrapper-stage investments.
A system that owns all four dimensions is not a wrapper. It is a platform, regardless of which foundation model sits underneath it.
The Model Portability Test
The model portability test is a direct way to classify an AI investment:
- describe the system’s value proposition
- remove the foundation model
- ask what is left
If what remains is a data pipeline connected to enterprise systems — keep it. If what remains is a workflow node that sits inside real business processes — keep it. If what remains is an evaluation suite measuring production outcomes — keep it. If what remains is governance infrastructure that required real organizational design and audit discipline — keep it.
If what remains is a collection of prompts, a formatting layer, and a thin API client — the system is a wrapper, and the next model release is a business risk.
The test is not theoretical. Organizations that run it honestly usually discover that their AI portfolio is a mix: a few systems with genuine integration depth, several with shallow integration and high model dependency, and at least one that is architecturally indistinguishable from a prompt engineering project.
That distribution drives portfolio decisions: where to invest more deeply, where to avoid doubling down, and which initiatives should be redesigned before more organizational dependency accumulates around them.
Build vs. Buy Through This Lens
The wrapper-vs-platform distinction changes the build-vs-buy question.
When an organization evaluates AI vendor products, the default evaluation criteria focus on the model layer: output quality on benchmarks, feature list, pricing, and model update cadence. Those criteria measure the wrong dimension for long-term investment.
The better evaluation criteria ask about integration depth:
- how deeply does this product connect to our data sources, or does it depend on us sending data at inference time
- does this product embed in our workflows at decision points, or does it remain an optional tool users can consult
- does this product have an evaluation framework that measures outcomes in our environment, or does it report model-level benchmarks
- does this product have governance controls appropriate to the authority it will hold, or does it leave governance design to us
Vendor products that score poorly on integration depth are, architecturally, wrappers delivered as a service. They carry the same depreciation risk as internal wrappers — plus vendor pricing power and reduced control over the integration layer.
For the architecture decision framework that governs which investments should harden into production systems, see Architecture Decisions That Cost Startups Time. For the signals that indicate an AI system has outgrown its current architecture, see The Architecture Review Your AI System Needs Before Scaling. For the portfolio-level view of which AI initiatives deserve sustained investment, see What an Enterprise Agentic Portfolio Review Should Produce.
- Run the model portability test on every AI investment: name what persists when the foundation model is replaced.
- Classify each initiative by integration dimensions owned: data, workflow, evaluation, governance.
- Treat high model dependency as a depreciation risk, not a feature — note it explicitly in investment records.
- Evaluate vendor AI products by integration depth, not benchmark performance or feature count.
- Invest in evaluation infrastructure before scaling any system — evaluation sets accumulate value that prompt libraries do not.
- Audit governance infrastructure proportionality: approval gates, logging depth, rollback design, and ownership should match the system's current authority, not its authority at launch.
FAQ
What is the difference between an AI wrapper and an AI platform?
A wrapper is a thin layer over a foundation model API — it adds prompts, formatting, and basic routing but its value depreciates as models improve. A platform has deep integration into enterprise data, workflows, evaluation, and governance — its value comes from the integration layer, not the model layer.
Why do AI wrappers fail?
Because their value proposition — better prompts, formatting, or UX on top of a foundation model — depreciates as model capabilities improve. When the base model does natively what the wrapper did with prompt engineering, the wrapper has no remaining value.
What makes integration the real AI moat?
Integration depth — data pipelines connected to enterprise systems, workflows embedded in business processes, evaluation loops measuring real outcomes, governance infrastructure enforcing compliance — is built through production work and cannot be replicated by switching to a different model or vendor.
How should organizations evaluate AI investments through the wrapper-vs-platform lens?
Ask: what persists when the model changes? If the answer is prompts and formatting, it is a wrapper. If the answer is data pipelines, workflow integration, evaluation infrastructure, and governance — it is a platform. Invest in the layer that persists.
The Decision Rule
The architectural argument is simple: the integration layer is the moat, not the model.
Data pipelines, workflow embedding, evaluation infrastructure, and governance controls are the components that accumulate value over time, survive model substitutions, and cannot be replicated by a competitor who simply picks a better API. Prompts and formatting layers are easier to rebuild than operational integration. Integration depth leaves organizational residue — workflows, test sets, governance records — that persists after the engineering work is done.
The review starts with the model portability test and ends with a concrete map of where investment will compound and where it will depreciate.