{"slug": "how-dxc-technology-built-a-multi-model-ai-substrate-on-amazon-bedrock", "title": "How DXC Technology built a multi-model AI substrate on Amazon Bedrock", "summary": "DXC Technology built DXC OASIS, a harness for mission-critical IT operations, on an Amazon Bedrock model substrate that gives it access to Anthropic Claude, Amazon Nova, Meta Llama and open-weight models through a single managed interface, with Bedrock Guardrails enforcing content filtering, PII redaction and denied-topic policies across every model. Since general availability in March 2026, DXC OASIS has cut resolution time by 95% on average across 56 measured use cases, according to the AWS blog co-written with DXC's Nick Tamburro. DXC, which employs more than 115,000 people across 70 countries, keeps inference traffic inside the customer's VPC via AWS PrivateLink and keeps prompts and completions from being shared with third-party model providers or used to train foundation models.", "body_md": "## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# How DXC Technology built a multi-model AI substrate on Amazon Bedrock\n\n*This post is co-written with Nick Tamburro of DXC Technology.*\n\nWhen 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.\n\n[Amazon Bedrock](https://aws.amazon.com/bedrock/) provides that substrate. Through a single managed interface, it gives DXC OASIS access to multiple foundation models: Anthropic Claude, [Amazon Nova](https://aws.amazon.com/ai/generative-ai/nova/), Meta Llama, and open-weight families. [Amazon Bedrock Guardrails](https://aws.amazon.com/bedrock/guardrails/) enforce content filtering, personally identifiable information (PII) redaction, and denied-topic policies uniformly across every model. [AWS PrivateLink](https://aws.amazon.com/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](https://dxc.com/) 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.\n\nModel availability varies by AWS Region. See [Supported models by AWS Region in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html).\n\nDXC 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.\n\nIn 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.\n\nAcross 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.\n\n*“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.”*\n\n— Dan Gray, President, GIS, DXC Technology\n\n## Solution overview\n\nDXC 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.\n\nThe design goals were:\n\n1. Resilience: No single point of failure at the model layer.\n2. Flexibility: Route each task to the most appropriate model on cost, latency, and capability.\n3. Regulatory sovereignty: Meet the data-handling expectations of regulated tenants.\n4. 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.\n\nThe 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.\n\nEngineers and operators reach the system through Amazon Route 53 and an Application Load Balancer inside the customer’s [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/). The DXC OASIS agent runtime runs on [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/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)](https://aws.amazon.com/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)](https://aws.amazon.com/iam/), [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/), TLS 1.2, Amazon CloudWatch, VPC Flow Logs, AWS CloudTrail, and OpenTelemetry provide security and observability across every layer.\n\n## Building the DXC OASIS substrate\n\nDXC 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:\n\n1. Establish governed, multi-model access through Amazon Bedrock.\n2. Engineer resilience into every layer of the architecture.\n3. Route each workload to the most appropriate model.\n4. Draw the line between the substrate and the harness.\n\n### Establish governed, multi-model access through Amazon Bedrock\n\nEvery 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](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html).\n\n### Engineer resilience into every layer\n\nResilience 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.\n\n| **Resilience control** | **What it does for DXC OASIS** | \n| 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. | \n| Serverless model layer | Amazon Bedrock is serverless and the Amazon EKS control plane is AWS managed, removing single points of failure. | \n| 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. | \n| 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. | \n| Elastic capacity | Amazon EKS autoscaling with per-tenant namespaces makes onboarding a new tenant a capacity-planning exercise. | \n\nBeyond 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.\n\n### Route each workload to the most appropriate model\n\nThe 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 capability, and adopts new frontier models as they arrive without re-plumbing the system.\n\n#### Model choice as a workload decision\n\nEach task’s capability, latency, and cost requirements determine which model it uses, not system constraints.\n\n**Intelligent prompt routing –** A single serverless endpoint predicts response quality and routes requests between models in the same family. It sends simpler prompts to lower-cost models and complex reasoning to more capable ones. Prompt caching further cuts latency and cost. For more information, see [Intelligent prompt routing](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html) in the Amazon Bedrock documentation.\n\n**Custom model import –** With [Custom Model Import](https://docs.aws.amazon.com/bedrock/latest/userguide/model-customization-import-model.html), the same governance and tooling extend to models that DXC or its clients bring themselves.\n\n#### Open and closed models together\n\nAmazon Bedrock supports open-weight models alongside proprietary ones, so DXC pairs frontier reasoning with open-weight models a client can adapt and deploy under one set of guardrails.\n\n### Draw the line between the substrate and the harness\n\nEvery enterprise agent needs six capabilities. Some are substrate capabilities Amazon Bedrock provides directly. Others are things only the harness can provide because they depend on DXC’s operational context and accountability model. This boundary is also where agent safety is won or lost. Guardrails on model inputs and outputs are necessary, but only the harness can limit what an agent is allowed to do. The following table draws that line.\n\n| **Capability** | **What Bedrock provides** | **What the harness adds** | \n| Orchestration | A foundational service layer the harness calls, wraps, or extends. | Supervisor and capability-agent delegation across tools, systems, and multi-step workflows, built on the open source LangGraph runtime. | \n| Context | Knowledge-base infrastructure and prompt caching for retrieval. | 60 years of runbooks, escalation logic, and live IT service management (ITSM) data. | \n| Governance | AWS IAM, regional inference controls, and tenant-isolated model access. | Per-request policy enforcement, persona-based authorization, and field-level constraints. | \n| Guardrails | Amazon Bedrock Guardrails: content filters, denied topics, PII filters. | Operational-policy enforcement above the substrate filters: tiered knowledge hierarchy, scoped and auditable agent roles, and customer-specific rules on what an agent can act on. | \n| Human oversight | Not a substrate function. | Four authority tiers (observe, propose, act with approval, act within scope), with every persona starting read-only, plus approval gates and escalation paths. | \n| Assurance | Encryption, auditable infrastructure, and VPC Flow Logs. | OpenTelemetry traces for every action, each with a unique execution ID, giving end-to-end traceability from intent to action. | \n\n## How a workload flows through DXC OASIS\n\nTo make the architecture concrete, the following use cases come from the DXC OASIS demo environment. The environment is built around AnyCompany Airlines, a fictional mid-sized airline running a hybrid on-premises and AWS estate.\n\n1. **Incident resolution:** Diagnose and fix an at-risk production server, from alert to resolution in under 10 minutes.\n2. **Problem management:** The ITSM agent ranks the top five incident categories and suggests how to reduce each, work that takes 2–3 hours by hand.\n3. **Cloud cost analysis:** For the AWS cloud engineer, the Metrics agent breaks down a 90-day cost trend by service and region, then investigates spending peaks on request.\n\nThe incident-resolution workflow shows how the substrate and the harness work together:\n\n1. **Alert in business terms –** A runbook fails to clear disk space on the FlightOps server. The CIO sees the alert as a business risk: Flight Operations scheduling might be affected within 4 hours. At the same moment, the Linux engineer sees the same alert with the technical detail needed to act.\n2. **Plan and delegate –** The engineer opens AI Assist from the dashboard widget, and the metric carries into the chat as context. A supervisor agent breaks the request into a plan and delegates to capability agents (DXC OASIS Metrics, Linux System, and ITSM), with every model call made through Amazon Bedrock.\n3. **Grounded diagnosis –** The DXC OASIS Metrics agent confirms the server is 99% full and cites the knowledge base articles behind its answer. The Linux System agent traces the problem to a single 5 GB temporary file.\n4. **Human approval –** The agent presents its full execution plan, and nothing runs until the engineer confirms it. In this workflow, the agent operates at the act-with-approval tier: it can diagnose freely, but it can’t change the production server without an explicit, recorded approval.\n5. **Governed execution –** The fix runs, and DXC OASIS records what ran, on which server, who approved it, and when. The audit trail comes from the harness, not from the agent’s own account of what it did.\n6. **Learn and observe –** The engineer can turn the conversation into a draft knowledge article. The Query Metrics view shows the agent timeline, delegatio", "url": "https://wpnews.pro/news/how-dxc-technology-built-a-multi-model-ai-substrate-on-amazon-bedrock", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/how-dxc-technology-built-a-multi-model-ai-substrate-on-amazon-bedrock/", "published_at": "2026-11-11 20:45:45+00:00", "updated_at": "2026-11-11 20:51:19.251381+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-agents", "ai-infrastructure", "large-language-models"], "entities": ["DXC Technology", "Amazon Bedrock", "DXC OASIS", "Amazon Web Services", "Anthropic Claude", "Amazon Nova", "Meta Llama", "Dan Gray"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-dxc-technology-built-a-multi-model-ai-substrate-on-amazon-bedrock", "markdown": "https://wpnews.pro/news/how-dxc-technology-built-a-multi-model-ai-substrate-on-amazon-bedrock.md", "text": "https://wpnews.pro/news/how-dxc-technology-built-a-multi-model-ai-substrate-on-amazon-bedrock.txt", "jsonld": "https://wpnews.pro/news/how-dxc-technology-built-a-multi-model-ai-substrate-on-amazon-bedrock.jsonld"}}