DXC says its OASIS agents cut IT resolution time 95% on Amazon Bedrock

DXC Technology and AWS published an account on 11 November 2026 of how DXC built DXC OASIS, its agent system for managed IT operations, on Amazon Bedrock. The post says OASIS has been generally available since March 2026 and has reduced resolution time by 95% on average across 56 measured use cases. It is co-written by an AWS solutions architect and DXC's chief architect for OASIS, so treat it as vendor-published.

DXC runs IT for banks, hospitals and government agencies. The interest for anyone putting agents near production systems is less the headline number than where DXC says it put the controls.

What runs where

• The agent runtime runs on Amazon EKS in a private subnet, with a namespace per tenant and GitOps rollout. The post says DXC is "scaling toward 130 customer environments"; it does not say how many are live.
• A supervisor agent splits a request into a plan and delegates to capability agents, built on the open-source LangGraph runtime.
• Every model call goes to Amazon Bedrock over AWS PrivateLink. The post names Anthropic Claude, Amazon Nova, Meta Llama and open-weight families, with Bedrock's intelligent prompt routing and prompt caching to hold down cost.
• Bedrock Guardrails apply the same content filters, denied topics and PII redaction to every model.
• Every action gets an OpenTelemetry trace with a unique execution ID.

The line DXC draws

The post separates a "substrate" (what Bedrock provides: model access, guardrails on inputs and outputs, networking, encryption) from a "harness" (what DXC built). Its argument is that guardrails on model text are necessary, but only the harness can limit what an agent is allowed to do. Human oversight, the post says, is "not a substrate function".

In the harness, DXC defines four authority tiers: observe, propose, act with approval, and act within scope. Every persona starts read-only and gains authority one tier at a time. In the worked example, on a demo environment built around a fictional airline, an agent traces a server that is 99% full to one 5 GB temporary file, presents its plan, and runs nothing until an engineer approves. The record of what ran, on which server and who approved it comes from the harness, "not from the agent's own account of what it did".

Swapping models is treated as a test exercise, not a config change. Before a model enters production routing, the post says, the harness evaluates it against OASIS task suites, because models behind one API still differ in capability and failure modes.

The numbers DXC reports

• Filesystem incident: 53 to 90 minutes before, 3 to 6 minutes after.
• Database performance incident: 2 to 3 hours before, 5 to 12 minutes after.
• Cloud policy validation: 4 to 8 hours before, 15 to 30 minutes after.
• Patching validation: 45 to 90 minutes before, 5 to 10 minutes after.
• Complex problem management: 2 to 6 days before, 8 to 10 minutes after.
• Diagnostic accuracy: "92% or better, validated against senior engineer judgment".

What the post leaves out

• Cost. There is no figure for token spend, cost per incident or what the platform costs a tenant.
• How the 56 use cases were chosen and measured, and whether the "after" times include the wait for a human approval. The post calls the table "representative".
• Failures. No count of wrong diagnoses acted on, rejected plans or rollbacks, and no detail on how many cases sit behind the 92% figure.
• The mix of authority. The post does not say what share of production work runs at act-within-scope, without a per-action approval.
• Which model handles which task.

DXC says it is evaluating Amazon Bedrock AgentCore alongside its current orchestration layer. The reusable part for other teams is the checklist: start every agent read-only, record approvals outside the agent, and re-test before a model swap.