OneAdvanced has built a UK-sovereign AI platform running more than 50 specialized agents on infrastructure hosted in the AWS London region, according to an AWS Machine Learning Blog case study. The UK enterprise software provider self-hosted Meta’s Llama 4 Maverick and Llama Guard 4 after the models were not available through the managed AWS services it wanted to use in the region.

The deployment is designed for OneAdvanced’s customers in regulated sectors such as healthcare and legal services, where data residency is a central procurement and compliance requirement. Its architecture combines Amazon SageMaker AI for model serving, Amazon ECS for agent workloads, and a retrieval system built around Amazon Aurora PostgreSQL-Compatible Edition with pgvector.

The project illustrates a practical trade-off for enterprise AI teams: managed model services can accelerate experimentation, but sovereignty requirements may require customers to operate models, GPUs, orchestration, safety controls, and data pipelines themselves.

From Bedrock prototype to self-hosted models

OneAdvanced initially prototyped its AI capabilities with Amazon Bedrock. AWS says the company produced a working sprint covering chat completion, an agent for querying UK statute law, Snowflake integration, and chart generation in two weeks.

That approach did not satisfy the company’s requirement that models run exclusively in its own UK-based AWS accounts. At the time of the engagement described by AWS, Llama 4 Maverick and Llama Guard 4 were not available through the relevant managed services in the UK region. OneAdvanced therefore moved to a self-hosted design using UK infrastructure it could control directly.

The resulting UK-sovereign AWS platform serves Llama 4 Maverick and Llama Guard 4 through vLLM on Amazon SageMaker AI endpoints. The models run on p5.48xlarge instances in the London region, using Hugging Face models and AWS Deep Learning Containers. AWS says OneAdvanced initially used p4d.24xlarge instances before moving to P5 hardware for production and longer context requirements.

The company targets context windows of roughly 120,000 to 128,000 tokens for large-document analysis and multi-turn conversations. AWS reports that load testing during its advisory engagement validated the throughput requirements, although the case study does not provide latency, request-volume, availability, or cost figures.

How the agent platform works

The core agent layer consists of more than 50 task-specific agents built with the Strands Agents SDK and deployed on Amazon ECS. Each agent has its own system prompt and tool configuration, while optional input forms support users who may not want to interact through an open-ended chat interface. Agent configuration is stored in Amazon DynamoDB.

AWS says OneAdvanced grew from its first agent to more than 50 in three weeks, with most agents created in less than a day. The library covers areas including healthcare, legal work, human resources, marketing, logistics, and education. Examples cited by AWS include a care incident response assistant, a clinical safety bulletin generator, a document comparison tool, a performance review assistant, and an AWS Architect Agent.

The workflow begins when Llama Guard 4 screens a user request for harmful content. If the request passes, it is routed to the appropriate agent on Amazon ECS. The agent can call specialist tools, retrieve relevant information from documents stored in Amazon S3, and search a vector index backed by pgvector.

Documents uploaded to S3 are converted to Markdown, divided into chunks, and embedded for retrieval. This Retrieval Augmented Generation, or RAG, layer is intended to keep responses grounded in an organization’s own materials rather than relying solely on the model’s internal knowledge.

What the evidence shows—and what it does not

The detailed technical account comes from AWS, which advised OneAdvanced and published the architecture as a customer case study. The strongest adoption and speed claims—including the scale of the agent library, the three-week build period, and the claim that most agents took less than a day—are therefore vendor-reported rather than independently audited.

The same qualification applies to the reported load-testing results. AWS says the deployment met OneAdvanced’s throughput requirements, but the source does not disclose the test methodology, traffic profile, response-time targets, failure rates, or production utilization. It also does not state how many of the more than 50 agents are actively used by customers or provide a breakdown of their business impact.

The sovereignty outcome is more concrete as an architectural description. AWS says the solution keeps model hosting and customer data within the UK environment and helped support OneAdvanced’s ISO 42001 certification for AI governance. That should not be read as proof that every downstream compliance obligation is automatically met: residency, access control, retention, auditability, and supplier governance still depend on how the full service is configured and operated.

OneAdvanced’s CTO, Andrew Henderson, described UK data sovereignty as a hard requirement for many public-sector and regulated customers. That executive rationale explains the central design choice, but it remains a company position rather than an independent assessment of the platform’s compliance posture.

Why the deployment matters to AI builders

For product teams, the case highlights the engineering cost hidden behind a requirement as simple as “keep data in the country.” When the desired models are absent from a local managed-service catalog, teams may need to secure model licenses, obtain scarce GPU capacity, deploy inference servers, implement scaling, and maintain safety and retrieval layers themselves.

The architecture also separates responsibilities that are often bundled together in a hosted AI API. SageMaker AI handles model endpoints, ECS runs the agents and tools, S3 stores source documents, Aurora PostgreSQL provides the vector database, and DynamoDB stores agent configuration. That modularity gives OneAdvanced control, but it creates more operational interfaces to monitor, secure, and troubleshoot.

The move from Llama Guard 3 to Llama Guard 4 is another practical signal. AWS says OneAdvanced observed high false-rejection rates with the earlier model and replaced it. Screening requests serially before the main model can reduce some risks, but it also adds a gate that must be tested for false positives, false negatives, latency, and language or domain coverage.

For enterprise buyers, the agent count is less important than the governance model behind it. A library of 50 agents can make specialized workflows easier to package, but each agent introduces prompts, tools, permissions, retrieval sources, and potentially different failure modes. A no-code agent builder may expand access to nontechnical users, while increasing the need for approval workflows, testing, version control, and usage oversight.

What to watch next

The next useful signals will be operational rather than headline agent counts. OneAdvanced could disclose production usage, response-time and reliability targets, GPU utilization, or the cost difference between self-hosting and managed inference. Those figures would help buyers assess whether sovereignty justified the added infrastructure burden.

It is also worth watching whether the relevant Llama models become available through managed AWS services in the UK and whether that changes OneAdvanced’s architecture. A local managed option could reduce platform maintenance while preserving residency requirements, though the company might retain self-hosting for control over model versions and configuration.

Further evidence should also show how the agents are governed after deployment: who can publish new tools, how retrieval sources are approved, how harmful-content decisions are audited, and whether ISO 42001 processes cover the full agent lifecycle. These details will matter more to regulated customers than the speed of the initial prototype.

Creati.ai perspective

OneAdvanced’s deployment is notable not because “50 agents” is a universal measure of AI maturity, but because it exposes the practical boundary between an AI demo and a sovereign enterprise platform. The company used managed services for early experimentation, then accepted the operational complexity of self-hosting when regional model availability did not match its data requirements.

For builders, the lesson is to treat residency, model availability, safety screening, retrieval quality, and GPU economics as one architecture decision. For buyers, AWS’s account is useful evidence of a workable pattern, but the missing production metrics mean it should be evaluated as an implementation blueprint—not yet as an independently validated benchmark.