Replaceable

The property

Replaceable asks a single question: can one component be swapped without rebuilding the system?

Note what it does not ask. It does not ask whether the component is open source, whether it uses standard formats, or whether an alternative exists. Those are inputs to the answer rather than the answer. A system built entirely from open source components can be completely unreplaceable if every component assumes the others.

The property is a statement about coupling, not about licensing. It is measured in how much work a substitution would be, and the honest unit of measure is engineer-weeks rather than yes or no.

Why it matters more for agents

Every architecture benefits from loose coupling. Agentic architecture benefits unusually, for three reasons specific to this moment.

The components change quickly. Model capability moves in months. Harness design is still being worked out. Standards are young. A system that cannot absorb component change will be rebuilt or will fall behind, and both are expensive.

The layers have very different lifetimes. Storage and table decisions last years. Model decisions last months. A system where a model change requires touching the data layer has coupled a fast-moving decision to a slow-moving one, which is the wrong way round.

The pressure toward suites is strong. Vendors offer models, tools, harnesses, memory, and hosting together, and the bundle genuinely reduces time to a working system. The cost is not paid at adoption. It is paid at the point of change, in proportion to how many bundled pieces you came to depend on.

Where replaceability actually fails

Teams worry about the wrong things. The API key is not the problem. The client library is not the problem. Both are trivially swapped. Replaceability fails in five quieter places.

Definitions stored in a product

Skills entered into a web interface. Tool configurations in a proprietary format. Agent definitions in product state rather than in files. When these live inside a component, moving means re-entering them, and re-entering them means someone reconstructs them from memory and misses something.

Prompts tuned to one model

Phrasing refined over months against a specific model's behavior. This is a real form of lock-in that appears in no contract and no dependency list, and nobody schedules the work to undo it.

Designs that assume capability

An agent given vague instructions and thirty tools works on a frontier model and falls apart on anything else. The design, not the integration, is what pins you. This is the hardest form to notice because it looks like the system working.

Absent evaluation

Without a recorded evaluation set, nobody can tell whether an alternative is adequate. So the alternative is never seriously considered, and the incumbent stays by default rather than by decision.

Accumulated state with no export

What an agent has learned is the part that cannot be recreated. If memory lives only in a hosted store with no export path, that is the thing that actually holds you, regardless of how portable everything else is.

What replaceable means per layer

The question has a different shape in each layer, and the difficulty is not evenly distributed.

The execution layer is the hard one, and it is worth being explicit about why. Data formats and model APIs have converged enough to be reasonably portable. Harnesses have not. A great deal of what a team builds in that layer is harness-specific unless they deliberately push definitions out into portable forms, which is the entire reason the standards layer exists.

A worked example

The property is easier to judge against a concrete change. Take a team that decides to move its primary model from one provider to another, for a reason that is entirely ordinary: pricing changed, or a better model appeared, or a data residency requirement arrived.

In a system with poor replaceability, the work looks like this. Provider client calls appear in thirty-one files, several with provider-specific parameters. Tool schemas were written in one vendor's dialect and have to be translated. Prompts were tuned against the old model's behavior over eight months, and several stop working. There is no evaluation set, so nobody can say whether the new arrangement is better or worse, which means the change cannot be approved. The project stalls, and the team stays where it is for reasons nobody would defend if stated aloud.

In a system with good replaceability, the same change looks like this. One configuration file names the model per role. The evaluation set runs against both, producing a comparison across quality, cost, and latency. Two roles improve, one regresses slightly, and the regression is investigated and traced to a structured-output difference that is fixed in the schema translation layer. The change ships in three days with evidence.

Nothing in the second scenario required foresight about which provider would be chosen. It required four habits adopted early: one call site, roles rather than model names, portable schemas, and an evaluation set. Each of those is an afternoon of work at the beginning and a month of work retrofitted.

Measuring it honestly

The useful measurement is not a score. It is an answer to a specific question, written down.

This takes an hour and produces something that no amount of architectural discussion produces: a specific, reviewable number per component. It also tends to surface surprises. Teams routinely find that the component they worried about is easy to replace and the one nobody thought about is not.

The answers fall into three useful categories. A configuration change plus a round of evaluation is healthy. A week of focused work is acceptable for a component you chose deliberately. A project measured in months means the coupling is real and should be either reduced or consciously accepted.

Consciously accepted is a legitimate outcome. The failure is not depending on something. It is depending on something without knowing.

Exercising it, not just claiming it

Replaceability that is never exercised quietly stops working. Interfaces drift, assumptions accumulate, and the alternative path rots.

The practices that keep it real are small and have to be habitual:

• Run a second model family occasionally. Even for a small share of traffic. This catches prompt coupling and provider-specific assumptions while they are still cheap to fix.
• Develop against a local endpoint. Prompts that only work on one frontier model reveal themselves immediately.
• Run your evaluation set against alternatives on a schedule. Not to switch, but to know whether you could.
• Load your skills and profiles in a second harness. Even once. The projection report tells you what would actually survive.
• Read a table with a second engine. Occasionally. Format compatibility claims are easier to make than to verify.

Each of these is an afternoon. Together they turn a claimed property into a tested one, which is the only kind worth relying on.

The cost of replaceability

Being honest about the cost is what separates a useful principle from a slogan.

Abstraction layers add indirection, which adds latency and code to maintain. Portable formats mean working with the intersection of what implementations support rather than the best any one offers. Provider-specific capabilities arrive late or not at all. Evaluation sets take time to build and keep current. Running a second path occasionally costs money and attention.

These are real costs, and the payoff is contingent on a future you cannot predict. That asymmetry is why replaceability loses arguments in the moment and wins them over a few years.

The reasonable position is not to maximize it everywhere. It is to pay for it where the component is likely to change, where the consequences of being stuck are high, and where the cost is low. A routing abstraction costs an afternoon and buys a great deal. A custom abstraction over a stable database costs weeks and buys very little.

Bundles and accumulated dependence

The most common way replaceability is lost is not a decision. It is accumulation.

A team adopts a platform for model access, which is easy to leave. Then they use its tool integrations, because assembling those separately is real work. Then they define their agents in its format, because that is what its interface offers. Then they run on its hosting, because operating a process is a burden they did not want. Then their agents accumulate memory in its store, because that is where memory lives.

No step was wrong. Each was a reasonable local decision with an immediate benefit. Collectively they produce a system that cannot move, and the team discovers this only when they want to.

The counter-practice is not avoiding platforms, which would be both impractical and often worse. It is keeping a short written answer to what you would have to rebuild, updated whenever you start depending on a new piece. That takes minutes and converts an unnoticed accumulation into a series of visible decisions.

Two of the five steps above are worth defending harder than the others. Agent definitions and accumulated memory are the artifacts that cannot be recreated from anything else. Model access, tool integrations, and hosting can all be rebuilt from knowledge you still have. A definition entered into a web form and a memory store with no export are the two that genuinely pin you, which makes them the two worth insisting live in portable formats even when everything else is convenient.

When not to pay for it

Some components should be depended on wholeheartedly, and treating everything as replaceable produces a system that is uniformly mediocre.

Depend fully on things that are genuinely stable, widely implemented, and unlikely to change: the filesystem, HTTP, your programming language, a mature open format. Abstracting over these adds complexity with no realistic payoff.

Depend fully on a component when the alternative is not shipping. A prototype that proves an idea has more value than an architecture that never gets built. Replaceability can be added later at the layers where it matters, provided the definitions were kept in files.

And depend fully when the capability is genuinely unique and the dependency is bounded. Using a frontier model for the hardest reasoning is a reasonable decision, provided the rest of the system does not assume it.

Objections worth taking seriously

Replaceability attracts two objections that are usually dismissed and are actually correct in specific cases.

Abstraction is premature complexity

The argument is that building for a switch you may never make adds indirection now for a benefit later, and that this is the definition of speculative generality. In many cases it is right. A custom abstraction over a database you will never change is pure cost.

Where it is wrong is when the abstraction is nearly free. One function that every model call goes through is not an architecture, it is a habit. It costs an afternoon, adds one indirection, and converts a potentially multi-week change into a configuration edit. The test is whether the abstraction is cheap and whether the underlying component is genuinely likely to change. For models in 2026, both are true.

The intersection is worse than any specific option

The argument is that portable systems work at the lowest common denominator, giving up the best capability of every component. This is real. A provider-agnostic harness cannot immediately exploit a capability only one provider offers.

The resolution is not to reject the constraint but to place it deliberately. Use provider-specific capabilities where they matter and the dependency is bounded, and keep the surrounding structure portable. Prompt caching is a good example: adopting the design rule it implies, which is stable content first, costs nothing on providers that do not offer it and pays substantially on those that do. Capability adopted in a way that degrades gracefully is not lock-in.

There is a third objection that is simply true and rarely stated: replaceability has a maintenance cost even when nothing changes. Abstractions drift from what they abstract. Evaluation sets go stale. A second path that is never exercised stops working. If you are not going to exercise it, be honest that you have written documentation rather than built a capability.

Practices that preserve it

1. One internal function for model calls. The highest-value habit in the whole list, and it costs an afternoon.
2. Definitions in files, in version control. Skills, profiles, plans, and tool configurations. If it lives in a product's database, it does not move.
3. Protocols rather than plugins. An integration written as a server outlives the harness that first used it.
4. Structure prompts rather than tuning phrasing. Clear separation of instructions, facts, tools, and task transfers between model families.
5. Keep an evaluation set. Twenty real tasks with known answers. Without it, replaceability is untestable.
6. Design for the model you have, not the best one. A system that degrades gracefully on a weaker model is a system with options.
7. Know your exit for each component. Written down, kept current, reviewed when a dependency changes.

What it is not

Replaceable is not the same as replaced. Nobody benefits from switching components for its own sake. The value is in having the option, which changes negotiating position, risk exposure, and the ability to respond when circumstances change.

Replaceable is not the same as open source. Open source that nothing else implements is not replaceable in practice, and a proprietary component behind a widely implemented interface often is.

Replaceable is not free, and it is not a moral position. It is an engineering property with a cost, worth buying where the risk justifies it and not elsewhere.