Sovereignty is a placement decision.

There is one cloud we operate, and it is in the United Kingdom. Everywhere else the same platform is installed into infrastructure you run, in your own jurisdiction. Where it sits, who operates it and who holds the keys are your decisions, and everything else about sovereignty follows from them.

See where it goes Ask about a jurisdiction

Two ways to run it #

Knowing which of the two you are buying is the first thing worth settling. A platform whose sovereignty rests on a policy document is only as sovereign as the policy, and policies get rewritten by whoever holds the leverage. One whose sovereignty is a consequence of where its accelerators, its storage and its key material physically sit does not have that problem.

There is one cloud we operate, and it is in the United Kingdom.

Managed: our United Kingdom sovereign cloud #

One cloud, operated by us, resident in the United Kingdom.

Accelerators, object storage, model artefacts and operations all sit in the UK, and we run them. It is the route United Kingdom government work takes, and the fastest way to have a sovereign platform in service without standing up infrastructure of your own first.

The United Kingdom cloud

Deployed: the same platform, in your infrastructure #

Outside the United Kingdom, sovereignty means installation rather than a region of ours.

The identical platform is installed into infrastructure you or your partner operates, in your jurisdiction, on-premises or fully disconnected. You hold the hardware, the identity, the keys and the policy, and we are alongside for as much or as little of it as you want.

In-country deployment

Where the platform goes #

One cloud we operate, in the United Kingdom. Everywhere else the platform installs into infrastructure somebody already holds. The platform is the same in each; what changes is who owns the metal underneath it.

United Kingdom: The one cloud we operate ourselves, and where our government work is focused. The same platform is equally available as a deployment into infrastructure you run in the UK.
United States: Deployment rather than a region of ours. The platform installs into infrastructure held in country, with identity, key custody and tenant policy in the hands of the people accountable for them.
The Caribbean: In country, and frequently at the end of a link nobody should build a dependency on. The platform serves from the models it already holds and reconciles when the link returns.
Europe: Country by country rather than continent-wide, because Europe is a geography and not a single legal system. The country settles placement, contracting and support.
New Zealand: In country, where the distance to anywhere else is itself the argument for serving models locally instead of sending every request to the other side of the world.

Where we actually are

Agentycs is pre-revenue and signing its first deals with its first customers. These are the geographies that work is in; we collect the evidence as it goes rather than borrowing someone else's. Because a deployment is the same declared platform wherever it lands, adding a jurisdiction is an installation rather than a product decision.

Ask about a jurisdiction

United Kingdom

The United Kingdom is the one place Agentycs operates the cloud itself.

Our sovereign cloud is UK-resident: the accelerators, the object storage, the model artefacts and the operations behind them. It is built for United Kingdom government work first, and the same platform is available as a deployment into infrastructure you run in the UK.

Read the detail →

Europe

Europe is not one jurisdiction and not a cloud of ours, so a European deployment is installed in the country you choose.

There is no managed Agentycs region in Europe. The same platform is installed into infrastructure you or your partner operates, in the country you name, and the country settles placement, contracting and support. The platform itself does not vary.

Read the detail →

Somewhere else

The platform is portable by construction, not by exception.

The platform is not tied to the geographies this work has reached so far. Tell us where you need it and what constrains the decision, and we will tell you what standing it up there actually involves.

Start a conversation →

What you actually choose #

Six decisions, each of which has a concrete technical consequence. Together they are what people mean when they say sovereign.

Where the instance runs #

In our United Kingdom cloud, or on infrastructure you operate wherever you need it. Either way an instance can be geo-distributed across data centres for latency and for surviving the loss of one location.

Where data comes to rest #

Datasets rest on platform-operated, S3-compatible object storage, or on a storage backend you bring. Which zones hold which tenant's data is a per-tenant setting, not a platform-wide assumption.

Who operates it #

We operate it in the United Kingdom, you operate it, or you operate it with our platform team alongside under an access path you define. Where it runs and who runs it are separate decisions.

Who holds the keys #

Secrets live in the instance's own vault, or the secrets gateway brokers them from a vault you already run. Writes are forwarded to a secret's home region rather than fanned out.

Whether anything may leave #

Tenant policy decides which models and providers may serve a request, and whether data may leave the cluster at all. It is enforced before any work is dispatched, not audited afterwards.

Who can see what happened #

Every data access is recorded in a redacted audit ledger correlated to the identity and the query behind it, inside the instance, exportable to you.

How placement actually works #

None of this is configuration you have to assemble. Placement, replication, routing and model distribution are declared once and reconciled by the operator, which is why moving a platform is a change of declaration rather than a project.

Instance placement

A platform instance runs on Apex accelerators, on capacity in our United Kingdom cloud, or on hardware of your own, in the jurisdiction you name, and can span data centres within it.

Storage replication

Object storage starts single-zone in the cluster and expands in place to multi-zone, geo-distributed replication, with scheduled off-site backups.

Traffic routing

Load-balanced DNS and edge routing send each request to a healthy site, giving geographic failover and shorter round trips without pinning users to one location.

Private inter-site names

Mesh-internal DNS and a zero-trust overlay let clusters and services in different buildings reach each other by name, with policy on who may talk to whom.

Model placement

Weights are held in the instance's own artefact store and mirrored to the workers and edge sites that need them, so inference never depends on an external model host.

Identity

Your own OIDC provider authenticates people; the instance mints its own short-lived tokens. Membership stays in step through directory sync.

Where an instance sits and how it is operated are two decisions, not one. Any jurisdiction you can place hardware in supports on-premises, edge, multi-site, hybrid and fully air-gapped operation. Compare the patterns