Architecture
Udal, inside your environment.
Your people ask. Your rules decide. Your agents do the work. Udal connects those steps without handing control of your business to an external platform.
Runs on AWS, Azure, Google Cloud or your own servers · The AWS reference deployment is described below, based on the October 2026 platform architecture
The big picture
Three jobs. One governed system.
The platform separates deciding what is allowed, doing the work and accessing resources. That separation makes it easier to control risk and see what happened.
Inside your environment
Decide what is allowed
Control plane
Checks who is asking, applies your rules and records the work. Your teams decide which agents, models and tools each person can use.
Request handling · Policy · Approvals
Run the work safely
Execution
Each project has its own isolated worker. Work survives restarts and can pause for a person to approve a sensitive action.
Isolated workers · Durable workflows
Reach only what is needed
Capabilities
Controlled gateways connect agents to approved models, business systems and documents. Access is checked, rather than left to the agent's judgement.
Models · Tools · Document retrieval
Where it runs
AWS, Azure, Google Cloud — or your own servers.
Udal is installed where your systems already are. The control plane, the policy and the audit trail are the same in every case; only the underlying services change.
AWS
The documented reference deployment: Helm on EKS in your own account, with private networking and AWS-managed data services.
Azure
Installed in your Azure tenant, using the managed services, identity and keys you already run there.
Google Cloud
Installed in your Google Cloud project, using the managed services, identity and keys you already run there.
Your own servers
Installed on your own hardware or private cloud, including sites with no internet connection at all.
Sizing, networking and model choices are agreed for your environment during onboarding. The technical detail further down this page describes the AWS reference deployment.
From request to result
What happens when an agent runs?
The same checks apply whether work starts in the console or in one of your applications.
- 01
A person or application asks
Staff use the internal console. Your own applications can submit work through the same governed entry point.
- 02
Udal checks permission
The request is checked against your policy and recorded. A new installation grants no permissions until you define them.
- 03
An isolated worker takes the job
The worker for that project runs the workflow. Sensitive actions are policy-checked, and work can wait for human approval.
- 04
Approved models and tools do the work
The model gateway chooses the configured model. Tool access and document retrieval follow the same policy and audit controls.
- 05
Results return with a record
Results and tamper-evident audit records are stored. Your teams can review what happened, who authorised it and which resources were used.
Where the work goes
Model choice without losing sight of the boundary.
Not every model connection means the same thing. Udal records where a model runs and routes requests according to your configuration and policy.
In your cluster
Self-hosted open-weight models run on your own optional GPU pool. Document embeddings also stay in the cluster. This is the route for work that must stay on infrastructure you operate.
In your cloud region
The AWS reference deployment uses Claude through Amazon Bedrock over private connections in your region; managed equivalents are available on Azure and Google Cloud. These are managed services, not models hosted in your cluster. Your teams approve their use and data handling.
Outside your environment
Other model providers are opt-in and labelled external. Only explicitly approved connections are enabled; private connectivity is not a substitute for deciding whether data may leave.
Control at every step
The safeguards are part of the path.
Private by default
The reference deployment sits in private networks. Connections are denied unless explicitly allowed; internet access is optional.
Projects stay separate
Each project's code runs in its own sandboxed worker and image. One project's work does not share an execution worker with another.
People keep authority
Your identity groups and roles determine access. Work can pause for approval, with notifications through Teams, Slack, email or webhooks.
Costs have a stop
Model usage is metered. A hard budget stop halts work that exceeds its budget.
Evidence survives scrutiny
Audit records form a tamper-evident chain with locked checkpoints. Sealed evidence reports and exports support your assurance process.
Secrets and data are protected
Documents and records are encrypted. Secrets are managed separately, and services receive their own access roles in the environment you choose.
For technical teams
The reference deployment, in detail.
This is the AWS reference architecture, not a requirement to use AWS — the platform also runs on Azure, Google Cloud or your own servers, with equivalent services in place of the AWS ones named below. Sizing, networking, model choices and integrations are agreed for your environment during onboarding.
Deployment and network
Installed with Helm on Amazon EKS in your AWS account. A dedicated VPC spans three Availability Zones, with private subnets and an internal TLS 1.3 load balancer. General compute scales automatically; a separate GPU pool is optional. AWS services are reached through private VPC endpoints.
Workflows, identity and policy
The console issues short-lived Caller tokens to the runner API. Temporal manages durable workflows; Open Policy Agent maps identity-provider groups and roles to permitted tool scopes and model classes. The runner and project workers use gVisor sandboxes. The operator reconciles agent definitions, while the releaser manages versioned builds and releases.
Models, tools and documents
Agents ask for a logical model class. The gateway maps that class to a configured backend, so provider changes do not require agent changes. Model adapters accept traffic only from the gateway. The tool server, connectors and MCP servers mediate business-system access. Document ingestion stores files in S3 and retrieval data in PostgreSQL; embeddings run in the cluster.
Storage, audit and operations
RDS PostgreSQL holds runs, workflow state, audit records and vectors, with Multi-AZ available as an option. KMS-encrypted S3 stores documents and release bundles; Object Lock protects audit checkpoints. Secrets Manager supplies secrets, and ECR stores images. Metrics, dashboards and OpenTelemetry tracing support operations. Scheduled jobs handle backups and evidence exports; audit events can be forwarded to your monitoring systems.
Options agreed for your environment
Execution can use development mode, a sandboxed pod per run or durable project workers. PostgreSQL can be managed or in-cluster. Document processing can be disabled, extraction-only or full retrieval. Internal ingress is the default; application-facing access is optional. The hardened profile checks required security settings at startup and can require signed-image verification. An optional EU AI Act module supports classification and an AI system register; it is not a guarantee of compliance.
Start with one process. See the results in 30 days.
We'll run a governed pilot on a real workflow in your environment and hand you a board-ready summary of risk, cost and results. A human replies within one working day.
- Sovereign AI
- Smarter organisations
- Brighter tomorrows