What happened
AWS’s announcement, co-written with DXC Technology, describes DXC OASIS, a harness for mission-critical IT operations built on Amazon Bedrock. DXC began the prototype in early 2025 and reached general availability in March 2026. The company says it is scaling toward 130 customer environments on Amazon EKS, with per-tenant namespaces and GitOps rollout. DXC operates managed IT services for regulated organizations, including banks, hospitals and government agencies.
The architecture separates a model substrate from the harness above it. Bedrock provides a consistent API to Anthropic Claude, Amazon Nova, Meta Llama and open-weight model families. AWS says Bedrock Guardrails apply content filtering, personally identifiable information redaction and denied-topic policies across models. DXC routes inference through AWS PrivateLink from a private virtual private cloud, rather than across the public internet. The announcement says prompts and completions remain within the AWS data boundary, are not shared with third-party model providers and are not used to train the underlying foundation models. Model availability varies by AWS Region.
DXC’s harness supplies what the company says depends on its operational context and accountability model: orchestration across tools and systems, runbooks and live IT service-management data, per-request policies, scoped roles, human approval gates and auditability. A supervisor agent delegates work to capability agents. DXC says its harness runs on Amazon EKS and uses LangGraph for orchestration. Each persona starts read-only; the described authority tiers progress from observing and proposing to acting with approval or within a defined scope. In the example incident workflow, an engineer must explicitly approve a proposed production change, and the system records what ran, where, who approved it and when.
The announcement describes model selection as a workload decision based on cost, latency and capability. Intelligent prompt routing can send simpler prompts to lower-cost models and more complex reasoning to stronger models; prompt caching is also used to reduce latency and cost. DXC says it evaluates candidate models against task suites before production routing because a common API does not make model behavior interchangeable. The post does not state a DXC OASIS price.
DXC reports that the platform serves 12 operational personas across areas including Linux, Windows, SAP, virtualization, patching, AWS, Azure and network operations. Across 56 measured use cases, the company says resolution time fell by 95% on average and diagnostic accuracy was at least 92%, validated against senior engineer judgment. Examples include filesystem incidents dropping from 53–90 minutes to 3–6 minutes, and complex problem management from 2–6 days to 8–10 minutes.
What the archive adds
New Runtime's earlier coverage has described regional model availability on Amazon Bedrock, including Claude in India (September 30, 2026), and Kimi K3.1 Pro on Bedrock (November 11, 2026). Those notes concern model access, not DXC's architecture. This is a new enterprise case study rather than a new access change.
Trend signal
DXC's design supports the pattern that agent security is enforced at runtime boundaries: the harness scopes operational authority, requires approval for consequential changes and records execution, instead of relying on model behavior alone. See Agent security moves to runtime boundaries. The case illustrates the pattern, but does not independently establish how well the controls perform under attack or at scale.
Why now
DXC says the platform reached general availability in March 2026 and presents the results as evidence from its subsequent deployment. Its stated next step is evaluating Amazon Bedrock AgentCore alongside the existing orchestration layer, while expanding to additional regulated workloads.
Why it matters
For teams connecting agents to production infrastructure, model choice is only one part of the design. A managed model gateway can centralize access and provide network and content controls, but it does not by itself determine whether an agent may restart a server, edit a configuration or close an incident. Those permissions need to live in a layer that understands the task, user, environment and approval policy.
DXC's account offers a useful boundary to examine: use the substrate for model access and infrastructure controls, and make the harness responsible for tool permissions, human review and an auditable record of each action. That separation can also make model changes less disruptive, although DXC explicitly treats substitution as an assurance exercise because different models can fail differently. The reported time savings are promising, but they are not a controlled comparison; builders should measure their own baseline, review quality and risk before treating them as expected outcomes.
Limits and uncertainty
The performance figures, deployment scale and diagnostic accuracy come from DXC's account published with AWS; the announcement does not provide independent validation, a control group or the detailed evaluation protocol for the 56 use cases. It does not break down results by task, customer or model, or report failure rates, incidents, false approvals or the cost of operating the system. The customer environments are described as scaling toward 130, rather than as 130 completed deployments. Regional model availability varies. The stated data-boundary protections describe the AWS configuration in this case and should not be read as a blanket guarantee for every Bedrock deployment.
Skill to build now
Map one consequential agent workflow into two lists: controls supplied by your model platform, and controls your own harness must enforce. For each tool action, specify the allowed scope, whether approval is required, what evidence is logged and how the action is reversed. Start with read-only access, then test a narrow approval-gated action before expanding authority.
Reader takeaway
A multi-model API can make model routing flexible, but it does not make operational autonomy safe. DXC’s central architectural claim is to keep model access in the substrate and put task permissions, human approval and auditable execution in the harness. Treat its reported performance as a case-specific claim to test against your own workflows.