DXC brought AI agents into banking and hospital IT: incident resolution times fell by 95%

When an agent can access a bank’s production server, the question of which model to choose becomes secondary. Public incidents in which autonomous agents took destructive actions nobody requested show that the model itself is rarely the issue. The problem is an agent with more permissions than its task requires, and an architecture that fails to stop it. IT services provider DXC Technology—115,000 employees across 70 countries, serving banks, hospitals and government organizations—described on the AWS blog how it built these controls for its DXC OASIS platform.

Two layers: substrate and harness

The idea is simple: separate the question of which model to use from the question of how work gets done. DXC calls the lower layer the substrate. This is Amazon Bedrock: a single API for Claude, Amazon Nova, Meta Llama and open-weight model families. Bedrock Guardrails sits on top, applying the same content filtering, personal data removal and topic restrictions across all models. Inference traffic flows through PrivateLink within the customer’s VPC, while the serverless approach eliminates a company-managed GPU fleet as a point of failure.

The upper layer is DXC’s own harness. Orchestration is built on open-source LangGraph: a supervisor agent breaks down tasks and assigns them to specialist agents. The harness also holds operational context drawn from 60 years of runbooks and ITSM data, checks policies on every request and maintains an action log.

One important detail is where the boundary lies. Guardrails filters model inputs and outputs, but cannot limit what an agent is authorized to do to a server. Only the harness can do that, because those controls depend on each customer’s context and responsibilities.

What a single incident looks like

In a demo environment for a fictional airline, the FlightOps server is running out of disk space, and the runbook does not help. The CIO sees the alert as a business risk, while a Linux engineer receives the same data with technical details. The supervisor builds a plan and brings in the Metrics, Linux System and ITSM agents. The first confirms that the disk is 99% full and references knowledge base articles; the second finds a single 5 GB temporary file.

Then comes the critical step: the agent displays the complete plan, and nothing executes until the engineer approves it. It can diagnose freely, but changes to production require recorded approval. The harness generates the log—what ran, where, who approved it and when—rather than relying on the agent’s own account.

Permissions follow four stages: observe, propose, act with approval and act within a defined scope. Every persona starts in read-only mode, and each increase in permissions is a deliberate, one-stage-at-a-time decision.

The numbers and how to interpret them

Since reaching general availability in March 2026, OASIS has supported 12 operational personas covering Linux, Windows, SAP, networking, backups, AWS, Azure and other areas. DXC says average resolution times fell by 95% across 56 measured scenarios. A file system incident that previously took 53–90 minutes now takes 3–6 minutes. Database problems went from 2–3 hours to 5–12 minutes. Complex problem management went from 2–6 days to 8–10 minutes. Diagnostic accuracy is 92% or higher when assessed against senior engineers’ evaluations.

These figures deserve caution. This is a joint post by AWS and the vendor, with no independent verification. The before-and-after measurement methodology has not been disclosed, and 92% accuracy means the diagnosis could be wrong in roughly one in twelve cases. Human approval is therefore more than a formality here.

Practical takeaways for teams building agents for production:

• Keep model selection, orchestration and the deployment environment as independent decisions. A provider outage or deprecation then becomes a routing change. But a common API does not mean identical behavior: before adding a new model to routing, run it through your own task suites.
• Do not trust the model to constrain itself. Permissions, levels of autonomy and auditing must live outside the model, in code and policies.
• Start with read-only access and expand autonomy by task, rather than by default.
• Account for platform dependence: the entire architecture relies on Bedrock, and the available model lineup varies by AWS region.

The main lesson is not about a particular cloud service. An agent’s safety is determined by what it is allowed to do, rather than how intelligent its model is. Until that boundary is explicitly defined, it is too early to scale agents across production systems.