A subscriber tried to buy the same data add-on more than 30 times, across several channels, over three days. Every attempt came back with the same error: “Subscriber has pending order.” Somewhere in the stack, an unfinished order was blocking every new one. U Mobile has published this as an illustration of the failure class its internal platform is built to investigate. It is not a closed case. The account never says the order was cleared, how long that took, or what the subscriber saw afterward.
That scavenger hunt is the real cost in telco support. Finding the block used to mean a person walking interface logs, business-support APIs, eligibility rules, and policy notes before anyone could write a useful reply. A polished email does not clear a stuck order. If an agent cannot see the pending order, it will apologize for the wrong failure.
U Mobile, Malaysia’s newest 5G network provider, built AiDaH (AI-Driven Agentic Helpdesk) to do that hunt. Its Information Systems Division built the platform with AWS and AWS Partner Axrail on Amazon Bedrock AgentCore. The users are internal: L2 call center, branch, and other divisional staff. This is not a subscriber-facing chatbot, and it is not the company’s 5G network or wholesale build. Any effect on customers is indirect, through cleaner internal handling.
Most requests should never meet the expensive model
The cost control sits in the routing. That is the part worth stealing before you open the architecture diagram. As U Mobile describes the design, roughly 70 percent of requests resolve through deterministic keyword matching with no model invocation, about 20 percent are classified by a lightweight model, and only about 10 percent reach the full orchestrator. No sample size or measurement window is published for that split, so treat it as the cascade they designed, not as a benchmark you can drop into a board pack on its own.
The principle still travels. Call the cheapest path that can handle the request with confidence. AI automation that wakes a large model for every “where is my SIM” is a billing choice dressed up as intelligence. AI agents earn their keep on the minority of cases that actually cross systems. Everything else should stay a lookup.
Drafting was never the bottleneck
U Mobile already ran lean operations and had plenty of automation. What AI usually gets asked to do in a contact center is finish the sentence. Take a familiar complaint: mobile data not working overseas. A writing assistant can suggest roaming checks and a courteous reply. The human still confirms status, checks eligibility, raises the ticket, and sends it.
AiDaH, as U Mobile and its AWS partners describe it, is meant to cross those systems, find the failure point, and assemble a remediation plan. The estate looks like most modern telecom IT: CRM and business-support systems, mobile number portability, analytics, and infrastructure monitoring, split between on-premises and cloud. Before this platform, each new operational domain tended to need its own integration. Expansion was expensive because the glue was bespoke.
Translated out of slide titles, the program had three jobs. The agent should query the systems a person used to open by hand. It should follow a fault across more than one system, not stop at the first portal. And a second division should not need a new integration project to get the same front door. They started with pilots, not a company-wide switch-on.
One front door, tools exposed once
Staff mostly stay in Microsoft Teams, with a web portal alongside it. That choice is easy to skip and hard to recover from. New AI for business dies when it asks people to abandon the tool they already live in.
Behind that door, the account describes eight specialist agents: customer relationship management, customer problem management, number portability, order and SIM operations, infrastructure monitoring, big data analytics, cloud cost management, and finance operations. When a case crosses domains, one specialist can hand a subtask to another and merge the result (the Agent2Agent pattern, in plain terms a structured handoff rather than a second human opening a second portal). An analytics agent turns a plain-language question into SQL. Knowledge sits in Amazon Bedrock Knowledge Bases, with a shared enterprise store and a separate finance corpus.
The account says the platform went from a two-agent proof of concept to eight specialists covering more than 150 documented operational scenarios, across six business divisions, in under a year. Those two lists are not presented as the same map. Six divisions and eight agents both appear. The write-up does not line them up row by row. The calendar underneath the “under a year” line is more useful than the headline. Conceptualization began in late 2025 with two pilot agents and knowledge bases. A first-quarter 2026 pilot put the internal IT helpdesk online with four agents and 20 scenarios. Three-tier routing arrived through 2026, with six agents by mid-year. In the third quarter, AiDaH went live to 50 L2 call center and branch users with eight agents. It runs in the Asia Pacific (Singapore) Region.
Backends are not wired into each agent one by one. AgentCore Gateway exposes them through a Model Context Protocol interface: a standard way to offer tools with typed inputs and outputs, so a new domain does not require new agent logic. Functions at the gateway translate intent into the call a given system actually understands. On-premises and cloud systems are reached over a private, encrypted path, with no public internet route described.
That boundary is what makes the second division cheap. A new domain is a new gateway, tool definitions, and access rules. The interface, the routing, the security checks, and the audit trail stay put. AWS documents the general pattern: existing APIs, databases, and functions can be wrapped as tools without a rewrite of the estate. U Mobile’s story is one operator applying it, not proof that every telco stack will behave.
In AWS’s documentation, Amazon Bedrock AgentCore is for building, deploying, and operating agents at scale with any framework and foundation model, without the customer running the agent infrastructure. U Mobile cites two reasons for the choice: a managed runtime, and built-in memory so conversational context does not need a separate state store. The public account does not name the models. On this platform that silence is normal. Runtime is designed to work with models inside and outside Bedrock. Architecture and model vendor are not the same decision.
A write is a different risk class from a draft
Before anything changes a live subscriber account, the person on the desk reviews and confirms. That is the rule, and it is a process choice, not a slogan. A draft can be wrong in public. A write can be wrong in the billing system. AWS’s AgentCore documentation describes agents taking actions across tools under permissions and governance. It does not require a human confirm. U Mobile’s described design keeps one. Fully unattended repair is a different risk class, and it is not what they say is running.
Access is a six-tier role model, enforced per agent, per tool, and per data source. Staff come in through Microsoft Entra ID, the identity system they already have, rather than a new user store. Sensitive subscriber data is masked before it reaches a model. Amazon Bedrock Guardrails apply content policies. Prompts, tool calls, and API activity are logged. Compute sits on private network paths, with encryption for data at rest and in transit.
Before production scale-up, AWS ran a Well-Architected Security Review of the landing zone that hosts the platform. The reported outcome was confidence and a prioritized roadmap. That is a security review of the hosting environment. It is not a sign-off on ticket reductions or model accuracy.
U Mobile also built an eight-level internal competency scale, from basic digital access up to self-healing operations, drawing on ideas from TM Forum Autonomous Networks and adapted for its own use. That is an internal yardstick, not a formal TM Forum rating. The account says AiDaH reached Level 7 (specialist agents collaborating, using tools, retrieving governed knowledge, and supporting operational decisions) within nine months of the first pilot. Read that next to the rollout, not instead of it. If the first pilot is the late-2025 pair, nine months lands around the middle to third quarter of 2026, the same stretch in which the account is still adding agents and only then putting the platform in front of 50 L2 and branch users. Level 7 is U Mobile’s label for collaborative multi-agent work. It is not evidence that the full helpdesk was settled in production for most of that window. Level 8, systems that detect, diagnose, remediate, and learn without a person, is the target. It is not the current state.
Alignment with NIST SP 800-53, the OWASP Top 10 for LLM Applications, the CSA AI Trust Framework, MITRE ATLAS, Malaysia’s Personal Data Protection Act, and Malaysian Communications and Multimedia Commission rules is described as continuing work. Aligning is not the same as certified. The account also does not show two controls that exist on the same platform family as switched on: rules that can block a tool call before it runs, and routine scoring of traces for accuracy rather than only latency and token count. Those are available directions. They are not a description of AiDaH today, and they are not a claim about what every serious operator already does.
Read the percentages against the calendar
U Mobile’s internal measurements, for January through September 2026, are the figures that will get forwarded around a leadership team. Provisioning and network tickets fell 84.5 percent. General inquiries dropped 81.6 percent. Billing and charging fell 48.7 percent. The broader claim is that trouble-ticket volumes fell by as much as 84.5 percent in key categories. An internal survey rated ease of use 4.6 out of 5. AiDaH is now written into L2 support procedures and is subject to operational audit.
Those ticket figures are not independently audited results. Set them beside the rollout before you treat them as the effect of the live platform. A four-agent IT pilot landed in the first quarter. Six agents by mid-year. Go-live to 50 L2 and branch users only in the third quarter. The January-to-September window therefore includes months when AiDaH was a pilot, a narrower IT tool, or not yet in front of those users at all. The account does not say whether the percentages describe the live platform, a pilot subset, or a period that includes months before this system could have caused the change. It also does not publish baselines, seasonality controls, or how much other automation contributed.
“Up to 84.5 percent” is not a company-wide deflection rate. Billing moved far less than provisioning. If you are assessing risk to a support P&L, quote the category, the window, and the owner of the measurement. Do not promote an internal telco dashboard into a universal case for AI agents.
The pending-order example shows the kind of diagnosis the platform is for. It does not show a result. The account says progress was not linear, and that there were setbacks and recalibrations. It does not describe them. It also does not report accuracy, hallucination rate, time saved per ticket, or whether that stuck order was cleared. That measurement gap belongs next to the percentages, not in a footnote.
Adoption was a workflow problem
People already had escalation paths that worked well enough. The tactics in the account are ordinary and specific: directed prompt templates for common scenarios, so staff were not staring at a blank “ask anything” box; an internal channel for sharing what the system got right; visible accuracy; and, eventually, a place in the standard operating procedure. Trust followed use, not a launch memo.
On the build side, the useful habit was spec-driven development in Kiro, AWS’s agentic IDE. Requirements, design, and task breakdown were written and reviewed before code generation, especially at the boundary between agents and tools. A small team moved from two use cases to more than 150 documented ones on a 12-week sprint cadence. Specs at that boundary are less glamorous than a demo. They are also how a new scenario stays a tool definition instead of becoming another one-off integration.
Questions worth asking before you copy this
Is this a chatbot for customers?
No. The users described are internal L2, branch, and divisional staff. Any effect on subscribers is indirect, through faster or cleaner internal handling. Do not confuse it with U Mobile’s 5G network announcements.
Did tickets really fall 84.5 percent?
U Mobile reports that figure for provisioning and network tickets from January to September 2026, as an internal measurement. General inquiries fell 81.6 percent and billing and charging 48.7 percent in the same window. The broader “as much as 84.5 percent” line is category-specific, not company-wide. The window overlaps a pilot and a Q3 go-live, and the account does not separate those phases. Treat the numbers as operator-reported and unverified by an outside audit.
Why not stop at a writing assistant?
Because the expensive work was cross-system diagnosis. A draft still leaves eligibility checks, logs, and policy lookups on the human. The pending-order error is the picture: thirty failed purchases, one block in the stack, and a reply that cannot see it is just a faster apology.
Do agents change live accounts by themselves?
Not in the design described. A person reviews and confirms before a change to a live subscriber account. Fully unattended repair is Level 8 on U Mobile’s internal scale, and it is still a target.
How do they keep model cost from eating the savings?
By a three-tier cascade: keyword match first, a light classifier second, the full orchestrator only when needed. The roughly 70/20/10 split is how that design is described. It is not a published benchmark with a sample size or a measurement window.
What failed, and what is still unmeasured?
The account acknowledges setbacks and recalibrations and does not describe them. It does not report accuracy or hallucination rates, handle time, how many escalations still reach backend IT, or whether the stuck order in the example was actually cleared. Those gaps are part of the evidence. The percentages do not outrank them.
What would another company actually reuse?
A managed agent runtime, a standard tool protocol at the integration boundary, role-based access, masking before the model, a security review before scale-up, a cheap path for routine requests, and a human confirm on anything that writes to production. The telco system names do not have to travel with the pattern.
If it cannot see the order, it will apologize for the wrong failure
The transferable lesson is not “put AI agents on the helpdesk.” Fragmented operations are a tool-use problem. Gateway-style access, private connectivity, and an audit trail are what make the investigation real. A stable core, with a new domain added as tools and permissions rather than a fresh integration project, is what makes the second team affordable.
There is a governance line worth sitting with, and then not crossing by accident. Collaborative agents with a person confirming writes are an operating model. Self-healing without that person is a different risk class. The operators who get value from this kind of AI for business will be the ones who can point at a stuck order, show which system answered, and explain who was allowed to clear it. Everyone else will have a faster way to draft the apology.