DXC OASIS Deploys Governed Multi-Model AI Agents on Amazon Bedrock

Summary:DXC Technology has built the multi-model substrate for DXC OASIS on Amazon Bedrock, separating governed model access from the orchestration and assurance harness that controls agent actions. The architecture uses Amazon EKS in private subnets, AWS PrivateLink, IAM, KMS, Bedrock Guardrails, tiered permissions, approval gates, and OpenTelemetry traces to support regulated production workloads. DXC reports that OASIS reduced average resolution time by 95% across 56 measured use cases. The case ill

---

DXC Technology runs DXC OASIS on Amazon Bedrock with an explicit separation between a governed multi-model substrate and a trusted harness that governs how agents operate. The substrate provides model access, networking and platform-level controls; the harness adds orchestration, operational context, authorization, approval gates and action-level auditability.

The deployment targets regulated IT environments. DXC reports that OASIS has reduced average resolution time by 95% across 56 measured use cases since reaching general availability in March 2026. The result is vendor-reported and does not include enough detail about task selection, baselines or independent reproduction to treat it as a general benchmark.

Why the substrate and harness must remain separate

DXC separates three decisions that are often incorrectly bundled together:

1. Model selection: OASIS currently accesses Anthropic Claude, Amazon Nova, Meta Llama and open-weight model families.
2. Orchestration framework: Its harness uses the open-source LangGraph runtime, with a supervisor agent delegating work to capability agents for Linux, AWS and ITSM operations.
3. Deployment target: The agent runtime runs on Amazon EKS, while model requests reach Bedrock through VPC interface endpoints and AWS PrivateLink.

This separation makes model changes less invasive. A provider outage or model deprecation can become a routing decision instead of a platform rewrite. A common API, however, does not imply consistent behavior. DXC requires each candidate model to pass OASIS task suites before it enters production routing.

Multi-model routing

The system selects models based on capability, latency and cost. Amazon Bedrock Intelligent Prompt Routing separates simpler requests from more complex reasoning within the same model family, while prompt caching reduces repeated-prefix computation and transfer overhead.

Custom Model Import extends the same access and governance path to models supplied by DXC or its customers. The important constraint is that routing must remain tied to quality assurance. Switching models solely to reduce cost can introduce behavioral drift in instruction following, tool use, structured output or safety behavior.

Private networking and tenant isolation

Requests enter through Route 53 and an Application Load Balancer inside the customer VPC. The OASIS agent runtime runs in a private subnet on Amazon EKS. Model calls leave the subnet through a VPC interface endpoint and AWS PrivateLink rather than the public internet.

The security stack includes:

• AWS IAM for identity and access management;
• AWS KMS and TLS 1.2 for encryption at rest and in transit;
• Bedrock Guardrails for content filtering, denied topics and PII redaction;
• CloudWatch, CloudTrail, VPC Flow Logs and OpenTelemetry for operations and auditing;
• Tenant namespaces on EKS with GitOps-managed deployment.

Bedrock removes the need to operate GPU clusters, but it does not make the overall system free. Inference, long prompts, multi-turn tool calls, observability storage and private endpoints all contribute to the total cost of ownership.

Four authority tiers constrain production actions

DXC's central design choice is that input and output Guardrails cannot determine what an agent is allowed to do in a production system. Every agent persona starts with read-only authority and can be elevated deliberately:

• Observe: read information only;
• Propose: generate a plan without executing it;
• Act with approval: execute only after explicit human approval;
• Act within scope: act automatically inside predefined boundaries.

In the production-server workflow, a metrics agent confirms disk utilization and identifies a temporary file, while the Linux agent proposes a remediation plan. Nothing executes until an engineer confirms the plan. The runtime records the target system, command, approver and timestamp.

This is more reliable than asking a model in a prompt not to cause damage because enforcement occurs at the tool-execution layer. Even a faulty plan can be blocked if it exceeds the agent's permissions. In practice, approval should bind an immutable execution plan, arguments, short-lived credentials and an idempotency key; otherwise, approved parameters could be changed before execution.

End-to-end traceability

OpenTelemetry assigns a unique execution ID to every agent run and links intent, model calls, delegation, tool execution and outcomes. The harness records what actually ran rather than relying on the agent's self-description.

For production operations, this external evidence trail is more useful than a natural-language summary generated by the model. It supports incident analysis, accountability and policy regression testing. It also creates operational cost: retaining prompts, tool arguments and raw outputs requires sensitive-data filtering and retention policies.

Reported results and their limitations

DXC reports the following operational measurements:

| Task | Before | After | Time saved | |---|---:|---:|---:| | Filesystem incident | 53–90 minutes | 3–6 minutes | ~89%–97% | | Database performance incident | 2–3 hours | 5–12 minutes | ~90%–97% | | Cloud policy validation | 4–8 hours | 15–30 minutes | ~88%–97% | | Patching validation | 45–90 minutes | 5–10 minutes | ~85%–90% | | Complex problem management | 2–6 days | 8–10 minutes | ~99% |

DXC also reports diagnostic accuracy of at least 92%, validated against senior-engineer judgment rather than a public standard benchmark. Its illustrative workflow uses a fictional airline environment, so these numbers should be treated as deployment evidence, not a general-purpose model leaderboard.

Deployment guidance

Organizations adopting a similar architecture should:\n

1. Define action boundaries first: distinguish read-only, write-capable and approval-gated agents.
2. Separate model choice from orchestration: model routing changes should not require workflow rewrites.
3. Admit models through testing: validate tool use, refusals, output formats and safety behavior before production routing.
4. Use external evidence for audits: rely on runtime traces and system logs rather than model-generated summaries.
5. Calculate full workload cost: include repeated inference, caching, tool calls, logs and human approvals.
6. Increase autonomy gradually: begin with read-only and approval-gated execution, then widen bounded automation after accumulating verifiable traces.

The main contribution of DXC OASIS is not a new foundation model. It is a production architecture in which model portability, private inference, bounded authority, human approval and external auditability are treated as separate but complementary engineering concerns.

---

Source: AWS Machine Learning Blog (2026-11-11)

— END —

Tags: #DXC OASIS Follow #Amazon Bedrock Follow #Multi-Model Routing Follow #Agent Governance Follow #Private Cloud Deployment Follow