# The model behind your product is now a line item you can swap > Source: > Published: 2026-07-22 09:00:53+00:00 Apple spent a decade telling everyone that owning the whole stack was the entire point. The silicon, the OS, the frameworks, the store, the reason the phone felt like the phone and not a slab of someone else’s parts. So the most instructive procurement decision in tech this year is that Bloomberg confirmed the rebuilt Siri in iOS 27 will run on Google Gemini as its primary engine, moving off the current OpenAI integration. Apple, the company most allergic to depending on anyone, is renting its assistant’s brain from its oldest platform rival, and it is doing so having already switched model vendors once. Read that sequence slowly, because it says something a lot of product teams are still refusing to hear. The model your product runs on is a supplier, and suppliers get changed. I want to be careful about what this does and does not mean, because the loud version of the take is wrong. It does not mean models are all the same, or that capability stopped mattering, or that you can pick a provider by throwing a dart. Gemini 2.5 Pro Deep Think shipping in late June with 82.4% on GPQA Diamond is exactly why Apple is willing to move. The models are diverging in quality all the time, which is the whole reason the layer is worth swapping. What it means is narrower and more useful. The identity of your product lives above the model, in the interaction and the surface and the accumulated context, and the model underneath is a component you should expect to replace on a schedule you do not fully control. If the most vertically integrated company on earth treats its assistant’s core intelligence as a vendor line item, the rest of us should stop pretending ours is a permanent architectural marriage. **The worst model you will ever use, read the other direction** Kevin Weil, OpenAI’s CPO, has a line that gets quoted constantly and usually gets read as a pep talk. “The AI model that you’re using today is the worst AI model you will ever use for the rest of your life.” Builders tend to hear the optimistic half of that, the promise that everything gets better, and they use it to justify designing for capabilities that do not exist yet. Weil’s own framing, what he calls model maximalism, points that way too: build for where models will be in six months, not where they are today. There is a second reading that matters more for how you actually structure a product, and almost nobody talks about it. If the model you are using today is the worst you will ever use, then you are going to be replacing it, over and over, for the entire life of the product. The optimism and the churn are the same fact. A capability improving monthly is a supplier you are switching monthly, whether the switch is a version bump inside one provider or a jump to a different one entirely. Weil is describing a world where the component at the center of your product has a shorter shelf life than any other piece of your stack, and the design implication of that is not “wait for better models.” It is “assume the thing at your core is temporary and build so that swapping it costs you nothing.” Most teams have built the opposite. They wired their product to one provider’s specific quirks, tuned their prompts to one model’s personality, hard-coded assumptions about context windows and tool-calling formats and refusal behavior that belong to whatever they integrated first. That felt fine when the model seemed like the product. It stops being fine the week a competitor’s model is meaningfully better at your core task and you discover that moving to it means rewriting half your application logic. Apple can move Siri to Gemini because Apple, whatever else you think of it, understands the difference between the interface it owns and the engine it licenses. A team that fused those two things together does not have that option, and the improving-models future that is supposed to be good news becomes a trap, because they cannot capture any of the improvement without a migration project each time. **The product is the accumulated everything, not the weights** Here is the part worth sitting with. When Apple swaps Siri’s model, what stays? The name. The invocation. The place it lives on the device, the way it reaches into your calendar and messages and the rest of the OS, the permissions model, the years of behavior users have internalized about what it can and cannot touch. The identity of Siri as a product is almost entirely made of things that are not the model. The model is the part doing the reasoning, and it turns out the reasoning is the swappable commodity while the integration is the durable asset. That inversion is uncomfortable for anyone who spent 2025 believing the model was the moat. Think about what this means for your own product. If you strip out your current provider and drop in a different one of similar quality, how much of what your users value survives? For a well-built product the answer is almost all of it, because the value was never the raw model. It was the specific data you feed the model that no competitor has, the interface that makes the capability usable by a non-expert, the memory of the user’s history, the workflow the model is embedded inside, the trust the surface has earned. For a thin product the answer is nothing survives, because the product was the model with a login screen, and the moment the model is a swappable supplier, so are you. Marcus Moretti made a version of this point about SaaS survival that I keep coming back to: the two things that keep an AI product defensible are unique data sources and deep integration into the customer’s actual work. Neither of those is the model. Both of them are the layer above it, the layer that persists while the engine underneath gets replaced. If you are choosing where to spend your scarce engineering attention, the Apple decision is telling you to spend almost none of it on the model itself and almost all of it on the things that stay when the model goes. It helps to name the asset classes concretely, because “the layer above the model” is too abstract to act on. There are four things that survive a model swap, and they are the only four worth over-investing in. The first is proprietary data, the corpus or the signal that only you have because of your position, which no competitor can feed to whatever model they license. The second is the integration surface, the hooks into the user’s real workflow and systems that took you months to earn and that a competitor with a better model still has to build from scratch. The third is accumulated user context, the memory of a specific person’s history that makes your product’s output better for them than a fresh instance of the same model could ever be. The fourth is trust, the plain fact that the user has decided your product is the one they route this class of problem through, which is expensive to win and slow to transfer. Notice that a raw model gives you none of these. It gives you reasoning, and reasoning is now the commodity that Apple just demonstrated you can buy from whoever is best this quarter. Every hour you spend deepening one of the four durable assets compounds across every future model you adopt. Every hour you spend wiring your product to one provider’s idiosyncrasies is an hour you will spend again, in reverse, the day you switch. **Build the seam on purpose** The practical move is to design the seam between your product and the model as a deliberate, defended boundary rather than something that happened to you during the first integration. Concretely, that means the rest of your application should talk to an internal abstraction, not directly to a provider’s SDK. Your prompts, your tool definitions, your context assembly, your output parsing, all of it should sit behind an interface that assumes the thing on the other side will change. When it changes, and Weil is telling you it will change constantly, the blast radius is one adapter, not your whole codebase. This sounds like ordinary good engineering, and it is, but the reason teams skip it is revealing. They skip it because in the early, heady phase the model feels like the special thing, the reason the product exists, and wrapping it in an abstraction feels like insulating yourself from the magic. That instinct is exactly backwards, and Apple just demonstrated why at the largest possible scale. The company treats the magic as fungible. The magic is a supplier with a contract and a replacement waiting. The parts Apple guards are boring by comparison, the OS integration and the on-device privacy story and the distribution, and those are the parts that make Siri a product rather than a chatbot with Apple’s logo. There is a tell for whether a team has internalized this, and it shows up in how they talk about their own product in a meeting. A team that has not internalized it describes the product by the model: we use the best model, our model does X, we upgraded to the new version. A team that has describes the product by the durable layer: here is the data we have that nobody else does, here is how deep we sit in the customer’s workflow, here is what we remember about each user. The first team is one better competitor-model announcement away from having their entire pitch replicated, because their pitch was the model and the model is available to everyone. The second team is describing things a competitor cannot buy off a price list. When Apple talks about Siri, notice that the interesting claims are never about the model at all. They are about the device, the privacy posture, the reach into everything else you own. Apple learned to talk about the durable layer years before it had a model worth swapping, which is probably why swapping the model is a procurement decision for them rather than an identity crisis. I would go further and say the ability to swap is itself becoming a capability you should build toward, not just tolerate. If moving from one provider to another is cheap for you, you get to run the actual comparison your users care about, which is “which model is best at our specific task this month,” and you get to act on the answer immediately. If moving is expensive, you are locked into whatever you picked first, and you will watch better options arrive that you cannot use. The Reuters reporting on large firms deliberately mixing US, Chinese, and European models to reduce single-provider dependency is the same instinct showing up at the level of national procurement. The people with the most to lose from a bad supplier bet are building optionality into the architecture, and the people shipping thin wrappers are hoping their one provider never disappoints them or disappears on them. **Where the model still is the product, and where I might be wrong** I do not want to overstate this into a rule that fits every case, because it does not. For the frontier labs themselves, the model obviously is the product, and the abstraction argument is meaningless. If you are Anthropic or OpenAI or Google, the weights are the asset and everything else is packaging. The swap thesis is advice for the vast layer of companies building on top of those labs, not for the handful building the labs. It is easy to read a piece like this and quietly picture yourself in the wrong category. There is also a real cost to the abstraction that I would be dishonest to skip. The clean internal interface that lets you swap providers also flattens them toward their lowest common denominator, because you are only exposing the features every provider shares. The moment a specific model does something distinctly differentiated, some capability that has no equivalent elsewhere, your provider-agnostic seam becomes the thing stopping you from using it. There is a live tension between building for portability and building for the best-in-class feature of the model you have today, and anyone who tells you there is a clean resolution is selling something. My honest position is that for most products the portability is worth more than the marginal feature, because the features commoditize within a quarter or two and the lock-in does not, but I hold that with less certainty than I hold the rest of the argument. And I am not at all sure Apple’s specific bet is wise. Renting your assistant’s intelligence from the company whose entire business is knowing everything about users is a strange move for the company whose entire brand is privacy, and the tension there is not something Apple has resolved so much as deferred. The strategy lesson survives even if this particular deal ages badly, though. The lesson is that the most integration-obsessed company in the world looked at the model layer, decided it was a supplier rather than a soul, and structured the company around that. If you are building anything with a model at the center, the question the Siri decision puts on your desk is direct. When the model you use today becomes the worst model you will ever use, and it will, is your product built so that the upgrade is a config change, or is it built so that the upgrade is a rewrite you keep postponing while better models pile up on the other side of a wall you built yourself? [The model behind your product is now a line item you can swap](https://blog.stackademic.com/the-model-behind-your-product-is-now-a-line-item-you-can-swap-c4c4ee5ecd9f) was originally published in [Stackademic](https://blog.stackademic.com) on Medium, where people are continuing the conversation by highlighting and responding to this story.