Stop building agents that can’t change models

No one can predict which AI provider will win the next benchmark cycle. The smarter approach is to build an architecture that can adapt as models change. One with a stable contract between agents and models, tools and state that exist outside any single provider, and evaluations that make each model change a measurable decision. The goal isn’t to avoid choosing a preferred model. It’s to ensure that when the next model emerges, changing that choice doesn’t require rebuilding the system around it.

For example, on June 15, 2026, Anthropic retired Claude Sonnet 4 and Claude Opus 4 from its API, after giving developers notice on April 14. Any application still calling those model IDs started receiving errors. Claude Opus 4.1 followed on August 5. Later that month, OpenAI shut down its entire Assistants API and pointed developers to its Responses API. None of this was a surprise. Each provider published dates and migration guides well ahead of time.

The problem sits on the builder’s side. Many teams designed agents where the model is the foundation and not a component, so when the foundation moves, the whole building moves with it. The model market is moving too fast for that design, and enterprises should treat models as replaceable compute behind stable interfaces. By doing so, they can change providers for cost, capability, privacy or performance without rebuilding their agents.

The market refuses to sit still, and the rising costs of tokens

According to Menlo Ventures, OpenAI held 50% of enterprise large language model (LLM) API usage in 2023. By the end of 2025, that share had fallen to 27%. Anthropic climbed from 12% to 40%, and Google went from 7% to 21%. The data clearly indicates that leadership in this market changes hands faster than most enterprise software contracts renew.

Prices move faster still, as Stanford’s 2025 AI Index found that GPT-3.5-level performance on the MMLU benchmark cost $20 per million tokens in November 2022 and $0.07 by October 2024. Epoch AI found that the price of reaching a fixed performance level fell between 9x and 900x per year, depending on the task.

The best model for a task today will not be the best model for that task in 18 months, and architectures that assume otherwise are betting against the most consistent trend in the industry.

Most teams upgrade instead of switching

Menlo’s mid-2025 survey found that only 11% of teams had changed model providers in the prior year, while 66% upgraded within their existing vendor. What might be concluded here is that portability does not matter. However, many read it the other way. A low switching rate in a market with this much movement indicates switching is harder than it looks. And upgrading within one vendor is also a migration, because a new version changes output style, tool-calling behavior, latency and cost. An architecture that makes a cross-vendor switch cheap makes a same-vendor upgrade inexpensive too.

Where agents get welded to one model

In this case, lock-in builds up through small, reasonable shortcuts such as:

• Provider SDK types in business logic. Every file that imports them becomes part of the migration.
• Provider-hosted state. Threads, file stores and vector indexes inside a provider’s platform are the hardest things to move. The Assistants API shutdown made that clear.
• Prompts tuned to one model’s quirks. Those workarounds become dead weight on a different model.
• Fine-tuned models. A tuned variant stops working when its base model retires.
• No independent evaluation. Without a test suite, nobody knows whether a replacement is good enough, so fear keeps teams on old models.

What a stable interface looks like

The fix is an old systems idea. Put a stable contract between parts that change often and parts that should not. For example, here is a minimal sketch in Python:

from dataclasses import dataclass, field
from typing import Protocol

@dataclass
class ToolSpec:
    name: str
    description: str
    json_schema: dict

@dataclass
class ModelRequest:
    system: str
    messages: list[dict]
    tools: list[ToolSpec] = field(default_factory=list)
    task: str = "default"

@dataclass
class ModelResponse:
    text: str
    tool_calls: list[dict]
    input_tokens: int
    output_tokens: int
    model_id: str

class ModelClient(Protocol):
    def complete(self, request: ModelRequest) -> ModelResponse: ...

Tools use plain JSON Schema, and each provider adapter translates that into its own format. The “Task” label lets a router pick a model per task and lets the evaluation suite group results. The response records token counts and the “model_id that served the call, which makes cost tracking and regression analysis possible after a switch.

The agent never imports a provider SDK. A configuration file maps each task to an adapter. Changing providers becomes a configuration change followed by an evaluation run. Open-source gateways and

Read the original article:

Stop building agents that can’t change models