Dependencies remain steerable

In 30 seconds

Model, cloud and platform dependencies must remain steerable — without complicating the architecture through excessive abstraction. Portability arises from clear contracts, your own evaluation data and deliberately chosen dependencies.

Why it matters

Models, clouds and frameworks change quickly. Whoever builds without the option to switch pays later with lock-in, rising costs or a lack of sovereignty.

At the same time, total provider independence is expensive. The goal is not maximum abstraction, but a deliberate, documented decision per dependency.

Editorial assessmentPortability does not mean “making everything exchangeable”, but knowing what must be exchangeable. A Model Gateway and your own evaluation data deliver more than a generic abstraction layer over everything.

The core architecture questions

• Which dependencies are deliberately chosen — and which arose creepingly?
• Can we change the model provider without rebuilding the application?
• Is the agent state portable or bound to a provider?
• Do we know the cost per business outcome, not just per token?
• Do we evaluate quality before and after a provider change?

Typical patterns

• Model Gateway: one controlled point for model selection and switching.
• Portable Agent State: state not bound to proprietary services.
• Cloud Exit & Data Residency: deliberate decisions about location and exit.
• FinOps for AI: cost and value management of AI workloads.
• Cost per Outcome: economic viability measured by business outcome.

Common misconceptions & anti-patterns

• Direct binding to proprietary provider memory with no way out.
• Abstraction over everything — complexity without real benefit.
• Costs considered only per token, never per business outcome.
• Provider change without before-and-after evaluation.

Practical review questions

1. Could we switch the main model provider within a reasonable time?
2. Is the agent state exportable?
3. Do we know the cost per business outcome?
4. Do we have our own evaluation data for a switching comparison?

Link to the end-to-end worked example

Which provider dependencies exist, what does one transaction cost — and which data leaves the house?

• The model provider can be swapped via a model gateway, without rebuilding the application.
• Costs are measured per case handled (business outcome), not just per token.
• It is a deliberate decision which data may reach external services and which stays in-house.
• Your own evaluation data enables a before-and-after comparison when switching provider.

To the full worked example: service agent →

Link to the reference architecture

This mission concerns the lower layers (Core Systems, Cloud) and the Control Plane (Model Routing, Cost & Usage). It keeps the integrations built in 003 economical and sovereign.

Primary sources

Change history

• 25.06.2026 — Editorial Structured according to the mission template.
• 24.06.2026 — Editorial (subject matter) Initial publication with primary sources.