How DXC Technology built a multi-model AI substrate on Amazon Bedrock

This post is co-written with Nick Tamburro of DXC Technology. When an AI agent can act on a production server at a bank or a hospital, access to a capable foundation model is only the starting point. Recent public incidents, in which autonomous agents took destructive actions their operators never intended, show that the real risk is rarely the model alone. It’s an agent holding more authority than its task requires, with nothing in the architecture to stop it. Avoiding that starts with a substrate that governs model access at the infrastructure level. Amazon Bedrock provides that substrate. Through a single managed interface, it gives DXC OASIS access to multiple foundation models: Anthropic Claude, Amazon Nova , Meta Llama, and open-weight families. Amazon Bedrock Guardrails enforce content filtering, personally identifiable information (PII) redaction, and denied-topic policies uniformly across every model. AWS PrivateLink keeps inference traffic within the customer’s virtual private cloud (VPC), and serverless scaling avoids self-managed GPU infrastructure as a failure point. Because these are system-level controls rather than bolt-ons, they gave DXC Technology a governed foundation for what no model layer can deliver on its own: a trusted harness that orchestrates, governs, and audits AI agents across enterprise IT operations at scale. Model availability varies by AWS Region. See Supported models by AWS Region in Amazon Bedrock . DXC Technology runs managed IT services for some of the world’s most regulated organizations: banks, hospitals, and government agencies. With more than 115,000 employees across 70 countries, DXC operates mission-critical systems where resilience and governance are non-negotiable. When DXC set out to build DXC OASIS, the harness for mission-critical IT operations, the team separated the problem into two layers. The first is a governed model substrate built on Amazon Bedrock. The second is the trusted harness built on top: DXC’s own orchestration, governance, and assurance layer. In this post, we explore how DXC built the resilient, flexible model substrate beneath DXC OASIS on Amazon Bedrock. We also show where DXC drew the line between what the substrate provides and what the harness must provide. Since general availability in March 2026, DXC OASIS has reduced resolution time by 95% on average across 56 measured use cases. Across every model, customer data stays within the AWS data boundary: prompts and completions are not shared with third-party model providers and are not used to train the underlying foundation models. “Our customers operate complex, business-critical environments and need both choice and resilience in how they adopt AI. Amazon Bedrock provides access to a broad ecosystem of models with the governance, security, and operational controls required at enterprise scale. That flexibility allows us to use the right model for the right task, adapt as technology evolves, and stay focused on delivering measurable business outcomes for our customers.” — Dan Gray, President, GIS, DXC Technology Solution overview DXC OASIS separates the question of which model from the question of how work gets done. Amazon Bedrock is the substrate: a governed gateway to foundation models (FMs), reachable through one consistent API, with security and networking controls that keep traffic inside the AWS perimeter. The harness is everything DXC builds on top: orchestration across tools and systems, operational context drawn from 60 years of runbooks and escalation logic, policy enforcement, human-oversight gates, and full auditability of every agent action. The design goals were: Resilience: No single point of failure at the model layer. Flexibility: Route each task to the most appropriate model on cost, latency, and capability. Regulatory sovereignty: Meet the data-handling expectations of regulated tenants. Safety by design: Bound what every agent can do, so that no action with operational impact runs without policy checks and, where required, human approval. The main risk DXC designed against was coupling the system to any single provider, framework, or deployment target. The following diagram shows the key AWS services in the DXC DXC OASIS architecture. Engineers and operators reach the system through Amazon Route 53 and an Application Load Balancer inside the customer’s Amazon Virtual Private Cloud (Amazon VPC) . The DXC OASIS agent runtime runs on Amazon Elastic Kubernetes Service (Amazon EKS) in a private subnet. There, a supervisor agent delegates to capability agents that draw on a knowledge base, AWS Secrets Manager, Amazon EventBridge, and Amazon Simple Storage Service (Amazon S3) . Every model call leaves the subnet through a VPC interface endpoint and AWS PrivateLink to reach Amazon Bedrock, so inference traffic doesn’t traverse the public internet. AWS Identity and Access Management (AWS IAM) , AWS Key Management Service (AWS KMS) , TLS 1.2, Amazon CloudWatch, VPC Flow Logs, AWS CloudTrail, and OpenTelemetry provide security and observability across every layer. Figure 1: The DXC OASIS architecture on AWS Building the DXC OASIS substrate DXC began building DXC OASIS as a prototype in early 2025. A cross-functional team reached general availability in March 2026, scaling toward 130 customer environments on Amazon EKS with per-tenant namespaces and GitOps rollout. Building the substrate involved the following tasks: Establish governed, multi-model access through Amazon Bedrock. Engineer resilience into every layer of the architecture. Route each workload to the most appropriate model. Draw the line between the substrate and the harness. Establish governed, multi-model access through Amazon Bedrock Every model DXC OASIS uses (Anthropic Claude, Amazon Nova, Meta Llama, and open-weight families) is reached through Amazon Bedrock model inference. A provider outage or deprecation therefore becomes a routing decision, not a system rebuild. Uniform access isn’t the same as uniform behavior, however: models differ in capability, response style, and failure modes. Substituting one model for another is an assurance activity as much as a routing change. Before a model enters production routing, the harness (not the API) evaluates it against DXC OASIS task suites. For more information, see Getting started with Amazon Bedrock . Engineer resilience into every layer Resilience in DXC OASIS isn’t one control but the compounding of several. The following table summarizes the resilience controls and what each does for DXC OASIS. Resilience control What it does for DXC OASIS No single-provider dependency Every model is reached through Amazon Bedrock model inference. A provider outage or deprecation is a routing decision rather than a system rebuild, with the harness assuring behavioral differences between models before a switch goes live. Serverless model layer Amazon Bedrock is serverless and the Amazon EKS control plane is AWS managed, removing single points of failure. Scope-of-impact containment Amazon Bedrock Guardrails apply content filters, denied topics, PII filters, and contextual controls consistently regardless of model, containing the scope of any single failure. Private, encrypted paths Amazon VPC and AWS PrivateLink keep model traffic off the public internet. TLS 1.2 in transit and AWS KMS at rest protect data. Elastic capacity Amazon EKS autoscaling with per-tenant namespaces makes onboarding a new tenant a capacity-planning exercise. Beyond resilience, DXC OASIS also addresses data residency and sovereignty. Regional inference controls and AWS PrivateLink keep inference within approved AWS Regions and off the public internet, meeting the data-handling expectations of regulated tenants. Route each workload to the most appropriate model The strategic reason DXC built on Amazon Bedrock is optionality. Because every model sits behind the same API, the team routes each task to the most appropriate model on cost, latency, and