#

Key takeaways

• AWS published a case study on U Mobile's AiDaH helpdesk.

• The platform was built with partner Axrail and uses Amazon Bedrock AgentCore and Knowledge Bases.

• Eight specialist agents cover more than 150 documented operational scenarios.

• A three-tier routing design handles requests with different levels of automation.

• Human support agents still confirm actions before changes reach a live account.

What AWS described

AWS published a case study on November 4, 2026 about AiDaH, U Mobile's AI-Driven Agentic Helpdesk. The case study says U Mobile is a Malaysian telecommunications operator. It also says the platform was built with AWS and partner Axrail on Amazon Bedrock AgentCore.

The system covers more than 150 documented operational scenarios across six domains. It uses eight specialist agents. Staff interact with the helpdesk through Microsoft Teams and a web portal. The deployment is hosted in the Asia Pacific Singapore Region.

How the architecture is organized

The case study describes a layered architecture. It combines AgentCore runtime, memory, identity, gateways, and observability. Retrieval is handled through Amazon Bedrock Knowledge Bases. The design also uses Model Context Protocol for gateway exposure of backend tools.

The agents cooperate through Agent2Agent. That suggests the system is built for coordinated task handling rather than a single monolithic workflow. The source presents this as part of the platform design, not as a separate product claim.

Routing and control flow

AWS says AiDaH uses a three-tier routing design. Deterministic keyword matching handles roughly 70 percent of requests. A lightweight classifier handles 20 percent. The full orchestrator handles the remaining 10 percent, according to the case study.

This routing split shows a deliberate balance between speed and orchestration depth. Simpler requests can be handled with lighter logic. More complex requests can move to the orchestrator when needed.

The case study also says role-based access controls and authenticated identities constrain tool access. That is an important operational safeguard. It limits which agents or users can reach specific backend tools.

Human oversight in the workflow

In an illustrated support workflow, the system investigates a subscriber problem and proposes remediation. A support agent then confirms the actions before any change reaches a live account. That detail matters because it shows the platform is not fully autonomous in this example.

The source also says the longer-term goal of self-healing operations remains a roadmap objective. That means the case study presents self-healing as an intended direction, not as a completed state. The current workflow still includes human approval for live changes.

Reported operational measurements

U Mobile's internal measurements between January and September 2026 show declines in several ticket categories. Monthly provisioning and network tickets declined 84.5 percent. General inquiries declined 81.6 percent. Billing and charging tickets declined 48.7 percent.

The case study presents these as customer-reported measurements in an AWS case study. It does not establish an independently verified causal comparison. So the figures should be read as reported internal results within the source material.

Editorial reading of the case study

The strongest signal in the source is the combination of routing, access control, and human confirmation. Those elements suggest a controlled deployment rather than a fully automated support replacement. The architecture appears designed to route routine work efficiently while keeping sensitive actions under review.

The source also emphasizes operational breadth. More than 150 documented scenarios across six domains is a substantial support surface. Eight specialist agents and layered routing appear to support that breadth.

What the source supports, and what it does not

The case study supports a description of AiDaH as an agentic helpdesk built on AWS services. It supports the use of Amazon Bedrock AgentCore, Knowledge Bases, MCP-based tool exposure, and Agent2Agent cooperation. It also supports the reported ticket declines and the human-in-the-loop workflow.

It does not support broader claims beyond the described deployment. The source frames the measurements as internal and customer-reported. It also frames self-healing as a roadmap objective, not a finished capability. Those distinctions are important when reading the case study as a product and operations example.