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.

This is not hypothetical. On 19 July 2024, one vendor's faulty update took down millions of machines within hours. The analytics firm Parametrix estimated the direct financial loss to United States Fortune 500 companies alone at $5.4 billion, and projected that cyber insurance would cover only 10 to 20 percent of it. None of those companies chose the outage, and none could halt the failing component on their own schedule. That is the operational meaning of running something you cannot turn off: your worst day gets scheduled by someone else.

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.

The clearest place this shows up is the bill for leaving. Moving your own data out of a major cloud is metered by the incumbent you are trying to exit, which quietly turns the exit path into a toll road.

Exit is priced by the party you are exiting. AWS's published S3 pricing charges $0.09 per GB to move data out to the internet for the first 10 TB each month, tiering down to $0.05 per GB only above 150 TB, after a 100 GB monthly free allowance. Pulling 10 TB of your own operational record out is roughly a $900 line item at the headline rate, before any of the engineering cost of reshaping it to run somewhere else. An exit that exists only in a contract, with the meter running the whole way out, is not much of an exit.

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.