.png)
AWS published a case study on how OneAdvanced deployed more than 50 AI agents on UK-sovereign AWS. OneAdvanced, a UK enterprise software provider, built the stack to keep customer data in the UK while self-hosting the open-weight models they wanted, rather than waiting for managed regional availability.
The interesting part is not that they “used agents,” but that they turned sovereignty constraints into an architecture decision: host the models themselves on Amazon SageMaker AI, keep retrieval in Aurora PostgreSQL with pgvector, and run the agent/tool layer on Amazon ECS. That combination lets them ship enterprise AI without routing sensitive data outside UK infrastructure.
The trigger here is straightforward: OneAdvanced wanted Llama 4 Maverick and Llama Guard 4, but those models were not yet available through managed services in the UK region. For a vendor serving healthcare, legal, and other regulated customers, waiting for a managed rollout was not a viable product strategy.
So they went with self-hosted inference on AWS they control. That is the right call when regional availability and residency guarantees matter more than operational convenience. It also avoids the common trap where an “enterprise AI” rollout quietly depends on a service boundary that is still outside the jurisdictional or contractual requirements of the buyer.
The tradeoff is obvious: you inherit model serving, scaling, patching, and rollout responsibility. In return, you get control over where weights run, where prompts and retrieval context flow, and how traffic is isolated. For a sovereignty-first deployment, that is usually the correct exchange.
OneAdvanced backed retrieval with Amazon Aurora PostgreSQL-Compatible Edition and the pgvector extension. That is a sensible choice when the retrieval store must stay close to existing relational data, security controls, and operational processes.
The architectural win here is consolidation. Instead of introducing a separate vector service just to support RAG, they keep vector search inside a managed PostgreSQL control plane already familiar to enterprise teams. That simplifies data governance, IAM integration, backups, and auditability. It also makes it easier to join retrieval logic with structured application data when the application needs more than nearest-neighbor search.
For sovereignty-sensitive workloads, that matters as much as latency. Every new system boundary is another place where data movement, replication, or logging can undermine the residency story if teams are not careful.
The agent layer uses Strands Agents SDK, with the tool layer running on Amazon ECS. The important detail is the scale and specialization: over 50 agents, not one general-purpose planner trying to do everything.
That is usually the right design for enterprise workflows. A broad “do-everything” agent tends to become hard to evaluate, hard to secure, and hard to reason about when tool access expands. A fleet of narrower agents lets teams separate concerns: different policies, different tools, different prompts, different failure domains.
Running tools on ECS also keeps the operational surface area explicit. The model runtime is one tier, the agent orchestration layer is another, and the side-effecting tools are isolated in their own containerized services. That separation is valuable when you need to audit which component touched which system and when.
The one caution I would raise is that agent count is not a success metric by itself. Fifty agents can be cleaner than five if the boundaries are real, but it can also become taxonomy theater if the workflows are overlapping. What matters is whether each agent has a narrowly defined responsibility and a measurable success criterion.
The model pairing makes sense. Llama 4 Maverick handles the generation side, while Llama Guard 4 provides the safety layer. In a regulated enterprise setting, separating generation from policy enforcement is a practical design choice because it lets you update guardrails without reworking the application logic around the core model.
Self-hosting both also keeps moderation and inference inside the same sovereignty boundary as the rest of the stack. That matters when the policy is not just “avoid bad outputs,” but “avoid exporting data to services outside the UK.”
If you are evaluating a similar design, the real questions are not about whether the models are capable in the abstract. They are:
OneAdvanced’s architecture answers those questions in the simplest possible way: keep the whole control plane in-region and under direct AWS account control.
The larger lesson is that data sovereignty is an architecture constraint, not a compliance checkbox. If the customer requirement is “nothing leaves the UK,” then the retrieval store, orchestration layer, model hosting, and tool execution all need to be designed around that boundary from the start. OneAdvanced did that, and the result is a pattern other regulated SaaS teams can adapt without waiting for managed services to catch up.
