Writing
The Model Is Becoming a Replaceable Backend
Choosing a provider used to mean choosing an architecture. A stable interface makes replacement possible and evaluation makes it safe.
Notes
For the last few years, choosing an AI model has often meant choosing an application architecture.
Use one provider and you inherit its message format, tool schema, streaming behaviour, structured-output rules and deployment assumptions. Moving to another model can require more than changing an endpoint because model-specific behaviour leaks into the product around it.
Apple's WWDC26 updates point toward a cleaner boundary. The Foundation Models framework can now work with Apple's on-device model, Private Cloud Compute, local models, or third-party providers through a common LanguageModel protocol. A session can keep the same conversation while a Dynamic Profile changes the model, tools and instructions used for the next part of the task.
I think this is a useful direction for AI application design. The model should increasingly behave like a replaceable compute backend rather than the architecture the whole product is built around.
Model choice has become a systems decision
A few years ago, the default model decision was mostly about quality.
Which API produces the best answer?
That is no longer enough. A short private classification task may fit an on-device model, while a harder reasoning problem may need a cloud backend with a larger context window. A company may need a self-hosted model for sensitive data and a frontier provider elsewhere.
Apple's current stack makes these differences explicit. Its on-device system model is available directly through the Foundation Models framework. Private Cloud Compute provides a larger 32K context window and stronger reasoning for workloads that need more capacity. Core AI and MLX give developers ways to run their own models locally. The new LanguageModel protocol lets third-party or server-hosted providers conform to the same framework.
The product can choose a model because of the task rather than because the codebase was written around that vendor.
A common interface changes where application logic lives
The interesting piece is not that Apple supports more model providers. Applications have been able to call several APIs for years.
The difference is putting them behind one programming contract.
Apple's WWDC session describes two main protocol pieces. LanguageModel declares what a model can do and provides the configuration required to create it. LanguageModelExecutor performs inference and streams the response back to the session. The surrounding Foundation Models framework can keep handling sessions, tool calling and generated structured values above that boundary.
That separation means the application's business logic does not have to know every detail of the model implementation.
This resembles ordinary software architecture: product logic should depend on a stable capability boundary where one exists, not every detail of the implementation behind it. AI applications need the same discipline.
Capability still leaks through the abstraction
There is an obvious limit to this idea: language models are not interchangeable databases.
One model may support images while another accepts only text. One may call tools reliably while another struggles with the same schema. Context windows differ. Reasoning modes differ. Latency, price and safety behaviour differ. Even two versions of the same on-device model can respond differently to an unchanged prompt.
Apple acknowledges this directly. Its developer documentation warns that the system language model can change when the operating system updates and recommends testing prompts against each new version.
That means a common API cannot pretend every model behaves identically.
The abstraction has to expose capability while hiding unnecessary implementation detail.
This is why the LanguageModel protocol includes capability declarations. The application can share one interface while still deciding explicitly which backend suits the task.
Replaceable does not mean equivalent.
Dynamic Profiles make routing part of the session
Apple's Dynamic Profiles are an interesting extension of this idea.
A single LanguageModelSession can change its active instructions, tools and model while preserving the conversation. Apple's WWDC example uses one profile for quick analysis and another backed by Private Cloud Compute for deeper reasoning.
That creates a more flexible architecture than assigning one model to the entire feature.
An app could begin with an on-device model for a fast private interaction. If the task becomes more complex, a profile can move the next step to a stronger backend. Another branch could expose a different tool set without rebuilding the whole session.
This connects to the routing direction I wrote about with GPT-5 last year. Compute allocation can become part of application behaviour rather than a choice the user makes first.
The difference here is that the routing boundary is moving into a general application framework rather than staying inside one provider's product.
On-device AI makes portability more valuable
On-device models make this architecture more useful because local and cloud inference have very different operating properties.
A local model can avoid a network round trip and keep data on the device. It has tighter memory and context constraints. A server model can offer more compute and a larger working set but introduces network latency, availability and privacy considerations.
Those trade-offs are reasons to choose per task rather than permanently.
For a creative application, lightweight metadata extraction or project search may belong on-device. A heavier analysis of a large production document may move to a cloud model. A studio with its own internal model could expose that model through the same interface for private assets.
The application feature can remain conceptually the same while the execution backend changes according to policy.
Evaluation becomes the real portability layer
There is a trap here. If switching models becomes technically easy, teams may assume it is behaviourally safe.
It is not.
Apple introduced an Evaluations framework at the same WWDC for exactly this reason. Generative systems do not preserve the deterministic input-output contract of ordinary software, so developers need datasets and evaluators that measure behaviour statistically rather than relying only on unit tests.
That becomes even more valuable when several models can sit behind one interface.
If I can switch a production feature from an on-device model to a cloud model with one configuration change, I need an evaluation suite that tells me what changed. It has to tell me whether tool selection improved, whether structured output regressed, whether the new model kept to project terminology, and whether latency fell far enough to justify a quality trade.
The interface makes replacement possible. Evaluation makes it safe enough to trust.
What this means for production tools
The same pattern makes sense for the kind of Blender, game-development and automation systems I build.
I would not let the pipeline depend on one model's exact prompt format. I would define the domain operations first: inspect asset metadata, validate a scene, summarise a build log, classify an export error, generate a structured task plan.
Then I would decide which model class is appropriate for each operation.
Some work can run locally for privacy and responsiveness. Other work may need a larger hosted or internal model. The rest of the production code should not care more than necessary.
Model generations move quickly; production pipelines do not. A Blender validation system might live for years while the model behind one advisory step changes several times. Tying the pipeline to the model rather than the capability creates avoidable maintenance work.
My prediction
I think model abstraction will become a normal layer in AI application architecture.
Not because models become commodities. Their differences will remain large and sometimes product-defining. But applications will increasingly separate the capability they need from the specific backend that provides it.
The stack may look familiar: product logic defines the task, an evaluation layer defines acceptable behaviour, routing policy chooses the backend, and a model protocol handles execution.
On-device, private cloud, self-hosted and frontier APIs can then compete inside the same product rather than forcing separate product architectures.
Apple's framework is one implementation of that idea, not proof that its protocol becomes an industry standard. The broader signal is more useful than the specific API.
The model is moving downward in the stack.
It is still the intelligence engine.
It does not have to be the application architecture.
Sources
- Apple Developer, What's new in the Foundation Models framework, WWDC26.
- Apple Developer, Bring an LLM provider to the Foundation Models framework, WWDC26.
- Apple Developer, Foundation Models updates, June 2026.
- Apple Developer, Meet the Evaluations framework, WWDC26.
- Apple Developer, Meet Core AI, WWDC26.
More
Other write-ups
Approval Is Not Publication
Thirty seven items in the queue, one approved, nothing published. The last arrow in the diagram is the only one that pays.
Neural Rendering Is Crossing From Reconstruction Into Synthesis
Reconstruction filled in what sparse sampling missed. DLSS 5 generates appearance the renderer never computed.
The Renderer Is Becoming a Training Data Engine
The renderer used to sit at the end of the pipeline. Physical AI gives the same scene a second job: teaching a model.
Local AI Is Becoming a Compute Fabric
Local AI meant one model on one machine. Routing inference across the devices already on a network changes the unit.
Agent Infrastructure Is Becoming a Product Category
Every team used to build the loop, the store, the sandbox. That layer is being sold rather than written.
Choosing a local model with a stopwatch, not a benchmark
Three models, five hard tasks, code actually executed. The official build was 2.4 times faster and more accurate than a community repack of the same model.
We measured real time lighting against baked light, and baked won
A 3D product simulation that had to look like an offline render. The real time version ran at 60 frames per second and looked like clay. Here is the measurement and the architecture that replaced it.
What actually broke in an agency run by agents
Three failures from a delivery stack that runs on AI. None of them were the model's fault, and all three reported success while producing nothing.
A Task Without A Check Command Is Not Automated
If a task has no command that can fail, the pipeline advances on the appearance of work.
A Gate The Model Writes Is A Gate The Model Loosens
Three quality gates returned green while the work behind them was wrong, each for a different reason.
The Scoring Model Was Wrong And It Put The Worst Lead First
A weighted sum let one axis substitute for the other, so a company with money and no problem ranked in the top twenty.
Building Software Got Easy. Getting Value Out Of It Did Not
Aristo took weeks to build. Everything after the build is still in progress, and that gap is the whole story.
Capability Is Becoming an Operational Risk Surface
Safety questions used to be about the text. Once a model can act, the capability itself becomes something to operate.
The Scene Graph Is Becoming an API for AI
A scene graph exists for artists and software. Agents are becoming another consumer, and they need structure rather than pixels.
Animation Is Moving From Clips to Motion Priors
Authored keyframes and blended clips are giving way to asking which constraints define acceptable motion.
Materials Are Becoming Learned Programs
A material is texture maps, parameters and shader code. It is starting to become a small learned program that answers a rendering question.
Procedural Systems Are Expanding Beyond Geometry
Geometry Nodes started with a narrow name. Blender 5.2 puts physics, sound and object data through the same graph.
The Unit of AI Work Is Becoming the Task, Not the Turn
Chat taught us to think one turn at a time. Long-running agents make the task the thing that is scheduled, resumed and reviewed.
Game Engines Are Becoming Operating Systems for Worlds
Engines have been judged on what they render and simulate. The Unreal 6 roadmap points at operating a world rather than drawing one.
The Harness Is Part of the Capability
The same model behaves differently depending on context policy, tool design and execution feedback. That surrounding software is not neutral.
Physics Engines Are Becoming Trainable Components
A simulator predicts what happens next. A differentiable one can answer which parameter should change to stop the failure.
The Agent Needs an Environment, Not Just Tools
A search function and a database query were enough for short loops. Longer work needs a place to stand.
Coding Agents Are Becoming General-Purpose Computer Workers
Repositories were a friendly environment: text in, terminal actions, checkable results. That was a starting point, not a boundary.
Open Standards Outlive Model Generations
A year after the MCP bet, the argument can be checked against what happened rather than what was hoped.
Colour Management Is a Pipeline Contract
Blender 5.0 reads as better display options. Giving a file an explicit working colour space is an architectural change.
The Best Model May Be a Router, Not a Model
GPT-5 moves model selection inside the system. The interesting unit stops being which model and becomes which compute policy.
World Models Are Not Game Engines Yet
Genie 3 generates a navigable 720p world at 24 fps. Production work needs state you can inspect when something goes wrong.
Memory Is Becoming a System Capability
A follow-up to the long-context argument. Storing, selecting and expiring facts is turning into a named part of the product.
Coding Agents Change the Unit of Software Work
AI coding tools have been judged where code appears on screen. The boundary moves when the agent owns a task instead of a snippet.
Agents Need Protocols Between Each Other, Not Just Tools
Tool calling solves the inside of the loop. It says nothing about one agent reaching another built by a different team on another platform.
Agents Need a Runtime, Not a Prompt Loop
An agent is no longer well described as a prompt inside a while loop. The useful abstraction owns execution around the model.
Reasoning Is Not the Only Path to Better Models
Longer thinking improves maths and code. A model that solves a logic puzzle and misreads ordinary intent is not the better production model.
Rendering Is Becoming a Reconstruction Stack
Sparse samples, motion data and lower-resolution frames become a larger final result. Debugging becomes layered when reconstruction sits in the middle.
Agent Reliability Is an Evaluation Problem, Not a Prompting Problem
When an agent misses a step, the usual fix is a stricter prompt. The failure is more often in how completion is detected.
MCP Might Matter More Than Another Model Release
A model can reason well and still be useless inside a company if it cannot reach the files, repositories and tools where work lives.
Computer Use Is the Missing Layer Between Models and Software
Most integrations assume useful software exposes the right API. Much of real software never did.
Inference-Time Compute Is a New Scaling Axis
o1 improves when it is allowed to spend longer on a problem. A benchmark score without a compute budget is an incomplete number.
The Final Pixel Won't Come From the Renderer
Geometry, camera and scene structure stay reliable ground truth. More of final appearance is moving into learned systems.
Open Models Are Becoming Research Infrastructure
Llama 3.1 gets discussed as a benchmark result. The licence terms change which experiments are possible at all.
The Model Is Becoming a Runtime
Function calling, code execution and structured output turn inference into a loop. The model stops being a text generator and starts being a control layer.
Multimodality Changes the Architecture, Not Just the Interface
GPT-4o is easy to read as a faster interface. Training one model end to end across text, vision and audio is an architectural change.
Benchmark Scores Are Not Model Capability
Claude 3 posts 86.8% on MMLU and 50.4% on GPQA Diamond. The chart is useful and it is not the same thing as capability.
Long Context Is Not Memory
Gemini 1.5 makes a million tokens usable. A larger working set is not a system that decides what should survive the session.