Run it where you can turn it off

There is a moment in every infrastructure decision where the question stops being about features. Someone senior asks what happens if the vendor is acquired, or changes terms, or has an outage during the week that matters, or is required to hand something over. The answer to that question is a real property of the architecture, and it is usually decided long before anyone thinks to ask.

Agent infrastructure makes this sharper than most software, because an agent stack ends up holding three things at once: the credentials to act inside your systems, the accumulated record of how your work is done, and the audit trail that proves what happened. Losing access to any of the three is not an inconvenience.

Sovereignty is not a feature you turn on. It is the answer to a question you should ask before you build.

Four things people mean by it

The word gets used loosely, so it is worth separating what is actually being asked for.

• Where it runs. Whose machines execute the work, in which jurisdiction, and under whose control plane.
• Where the data sits. Not just at rest, but which systems it transits and what is retained where.
• Which models. Whether you can change providers without rebuilding, and whether you can run something locally when you need to.
• Whether you can leave. If you stopped paying tomorrow, what do you keep, and in what shape.

These come apart in practice. A system can be self-hosted and still be captive to one model provider. It can be portable across models and still be impossible to export. Answering only one of the four and calling it sovereignty is common and misleading.

The model layer is the tightest lock

Of the four, model portability is where lock-in accumulates most quietly. It rarely comes from the API surface, which is shallow enough to swap. It comes from everything built around a specific model's behavior: prompts tuned to its quirks, evaluations calibrated to its failure modes, workflows that assume its latency and cost.

The defence is not vendor neutrality as a slogan. It is measurement. If you can run the same task across several providers and compare the results, switching becomes an engineering decision with a number attached instead of a rewrite with an unknown cost. Teams that measure across models keep their options open almost as a side effect. Teams that do not, discover the true depth of the coupling on the day they need to move.

Self-hosting is a spectrum, not a switch

Self-hosting is often framed as all or nothing, which serves nobody. The useful version is a spectrum, and most organizations want a specific point on it rather than either end. Fully managed, single-tenant on the vendor's infrastructure, deployed into the customer's cloud account, or fully air-gapped are four genuinely different products with different operational burdens.

What matters is that moving along that spectrum does not require rewriting the application. If the self-hosted build is a different codebase with a subset of the features, the option is theoretical. The test is whether the same application runs unchanged in both places, with the deployment target as configuration.

Why this is not only about paranoia

It would be easy to read all of this as risk management, and it partly is. But there is a positive case that matters more. Systems you fully control are systems you can inspect, instrument, and modify. That is what makes it possible to measure your own stack honestly, to keep the accumulated record of your own work, and to build on top of it without asking permission.

The organizations that will get the most out of this technology over a decade are the ones that treated their own operational record as an asset from the start. That is hard to do on infrastructure you cannot see into.

How we think about it

We build the platform so it can run as a single-tenant deployment on infrastructure the customer controls, running the same application rather than a reduced one. Models are addressed through a provider-agnostic layer, so switching is a configuration change and comparing providers is a normal operation rather than a project. Data and audit records are exportable, because an exit path that exists only in a contract is not an exit path.

We would rather be chosen repeatedly than be difficult to leave. Those are different business models, and the second one is not the one worth building.