Think agentic development and digital sovereignty together

Digital sovereignty as an architecture objective#

Digital sovereignty means retaining the ability to decide where and how an enterprise processes data, develops software, and runs applications. This freedom matters as soon as a cloud provider changes prices, contract terms, or its service portfolio. The enterprise must then be able to replace services or move operations rather than being forced to stay.

Server location is only one part of that decision. The European Commission's Cloud Sovereignty Framework also considers strategic, legal, operational, and technical aspects. Enterprises must assess the legal regime governing providers and contracts, the dependencies created by external cloud services, and whether a critical application could continue on different infrastructure. How far they prepare that option depends on the application's importance and tolerated downtime.

Managed services can still be the right choice because they save time and operating effort. They also bind applications to a provider's APIs, data models, licences, and prices. The question is whether their business or economic benefit justifies the potential switching cost. The Data Act does make contract changes and data exports easier, but it does not perform the migration. Enterprises still need their own build, test, and deployment processes. This is where digital sovereignty meets agentic development.[1][2][3][4][5]

A containerised foundation for both objectives#

Coding agents need a containerised environment with the required tools for each task. Automated builds and tests immediately show whether a change works.

When development teams, agents, and continuous integration use the same environments and tests, AI-generated code does not follow a separate path. The resulting delivery process can run at a hyperscaler, a European cloud provider, or on owned infrastructure. This does not make every cloud service interchangeable. It does, however, keep development and delivery from becoming tied to one provider.[8][9][10][11]

The target architecture: an agentic application foundry#

This shared technical foundation leads to the target architecture of an agentic application foundry. It is not a single product, but an enterprise-defined product lifecycle in which people and agents plan, develop, and bring software into production.

The foundry connects product discovery and planning with technical delivery and operations. Everyone works with the same codebases, environments, and automated tests. A confirmed product idea can therefore become a running application through repeatable steps and be deployed across different cloud infrastructures without creating a new delivery process for each destination.

The Application Foundry in the toolbox shows what an initial part of this architecture can look like. The open-source project takes a confirmed business requirement to a running application in a development environment.[12][13]

Shorter time to market and less work when changing cloud#

Such a product lifecycle shortens the path from idea to release. Agentic development extends the existing software process instead of creating a second toolchain with separate rules.

The same architecture reduces the work required for a later cloud move. If builds, tests, and deployments are already portable, the enterprise does not need to reorganise software delivery before it can assess another provider. Migration can focus on the parts that are genuinely provider-specific.

The strategic leverage therefore lies in a stack that connects the entire product lifecycle through proven open-source tools and open standards. People and agents can work in the same process without tying it to one cloud provider's infrastructure. Databases and proprietary managed services still require migration work. The more critical the application, the more deliberately the enterprise should limit their number and importance.[11][8][14][6][7]