How U Mobile built agentic telco operations with Amazon Bedrock AgentCore

U Mobile, Malaysia’s newest 5G network provider, has always run its telco operations lean, doing more with less through continuous automation. When new AI capabilities became available, U Mobile explored how to enhance operational efficiency beyond basic productivity gains. The real opportunity was further upstream, in how operations teams diagnose and resolve problems in the first place. The same lean operating discipline shaped the foundation for AiDaH: not a one-off technology initiative, but the next step in a long-running journey to simplify operations and scale capability without adding complexity. When a subscriber can’t purchase a data add-on, resolving it isn’t a single problem. It’s a coordination problem. A customer service agent needs to pull interface logs for error codes. The same agent must then query business support system APIs for subscriber eligibility, and cross-reference internal knowledge bases for applicable business policies. All of that happens across multiple systems, before drafting a single word of response. And when that fails, the ticket escalates to backend IT teams and the subscriber waits even longer. Traditional automation tools can help agents write better responses. What they can’t do is navigate multiple systems, analyze the results, and propose corrective action. Closing that gap takes an agentic architecture built on Amazon Bedrock AgentCore. U Mobile’s Information Systems Division (ISD) built exactly that. Working with AWS and AWS Partner Axrail, they created AiDaH, the AI-Driven Agentic Helpdesk, on Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. Two capabilities decided the choice. The managed agent runtime meant there was no agent infrastructure to operate. Built-in memory carried conversational context across turns without standing up a separate state store. Within a year of starting the journey, AiDaH handles over 150 documented operational scenarios across six business divisions. U Mobile’s internal measurements show trouble ticket volumes falling by up to 84.5 percent in key categories. In this post, we walk through the six-layer architecture behind AiDaH. We then describe the security foundation beneath the platform, and close with a brief note on the spec-driven method the team used to build it. The problem: Too many systems, too much friction U Mobile’s IT landscape reflects the complexity typical of modern telecommunications: business support and customer relationship management systems, mobile number portability platforms, big data analytics, and infrastructure monitoring tools, running hybrid across on-premises and cloud. Before AiDaH, this fragmentation meant that even routine diagnoses required manually checking logs, querying subscriber eligibility, and consulting knowledge bases for business policies, across separate systems and portals. Each lookup was a context switch, each context switch was time lost, and each unresolved query became an escalation to a backend IT team. Expanding coverage to additional operational domains compounded the problem, because every new system typically required a bespoke integration. The ISD team’s strategy rested on three pillars. Reach : agents that coordinate across backend systems in real time. Depth : chain-of-thought reasoning for multi-step root cause analysis. Community : a secure multi-tenant framework with role-based access control and built-in guardrails, available to every division. The journey: From knowledge base to agentic platform AiDaH started with a principle: think big, start small. U Mobile began conceptualization in late 2025 with two pilot agents and Amazon Bedrock Knowledge Bases, a fully managed Retrieval Augmented Generation (RAG) capability. A Q1 2026 pilot brought the internal IT helpdesk online with 4 agents and 20 operational scenarios. Through 2026 the platform hardened and expanded, adding three-tier routing and reaching 6 agents by mid-year. AiDaH went live to 50 L2 call center and branch users in Q3 2026 with 8 agents, and now covers more than 150 documented operational scenarios. What agentic means in practice The difference between traditional AI assistance and agentic AI is best illustrated through a real example. With a traditional AI assistant, a support agent handling “mobile data not working overseas” gets help drafting a response and some suggested troubleshooting steps, but still manually checks roaming status, verifies eligibility, raises tickets, and sends the final reply. With AiDaH, the system independently checks the subscriber’s roaming configuration, verifies international data eligibility, and identifies the specific point of failure. It then assembles a remediation plan: which services to reset, what configuration to push, and whether a network ticket is warranted. The support agent reviews and confirms, and the actions execute. The investigation that used to consume the agent’s time now happens before they read the first line. The human decision point is preserved where it matters: at the moment something changes on a live subscriber account. In one production case, a subscriber reported being unable to purchase an add-on. AiDaH traced the failure to an error code, “Subscriber has pending order.” It also revealed that the customer had attempted the same purchase more than 30 times across multiple channels over three days, every attempt blocked by the same underlying pending order. AiDaH surfaced the root cause and the remediation steps in a single response. Previously that would have required manual investigation across several systems. Architecture: Six layers, one interface AiDaH runs on a layered architecture built on Amazon Bedrock AgentCore, deployed in the Asia Pacific (Singapore) Region. Staff interact through Microsoft Teams, a deliberate choice to meet most users where they already work, with no new application to learn and no portal switching. The following diagram shows how the layers fit together. Figure 1: AiDaH’s layered architecture As shown in Figure 1, the platform is organized into six layers. Layer 1: Staff interface Staff reach AiDaH through Microsoft Teams and a web portal served by Amazon CloudFront and protected by AWS WAF, with an AWS Lambda backend and a REST API for programmatic triggers. Layer 2: Orchestration The routing brain on Amazon Bedrock AgentCore. Every request passes a pre-flight security check covering role-based access control, identity validation, and guardrails, then enters a cost-optimized routing tier. Roughly 70 percent of requests resolve through deterministic keyword matching with no model invocation, 20 percent are classified by a lightweight model, and only 10 percent require the full orchestrator. The cheapest path that can confidently handle the request is the one that runs. Layer 3: Specialist agents Eight experts spanning customer relationship management, customer problem management, number portability, order and SIM operations, infrastructure monitoring, big data analytics, cloud cost management, and finance operations. They communicate over the Agent2Agent (A2A) protocol, which lets them delegate subtasks and complete cross-system workflows no single agent could handle alone. Layer 4: Gateways and backend APIs AgentCore Gateway, a capability of Amazon Bedrock AgentCore, exposes U Mobile’s backends to agents through a unified Model Context Protocol (MCP) interface. Behind each gateway sit AWS Lambda functions and MCP servers that translate agent intent into calls against a specific system. Layer 5: Data and knowledge Amazon Bedrock Knowledge Bases, the fully managed RAG capability, grounds agent responses in governed content, using an Amazon OpenSearch Serverless vector store. Content spans a shared enterprise knowledge base and a separate finance corpus. AgentCore memory, a capability of Amazon Bedrock AgentCore, maintains conversational context across turns, and Amazon DynamoDB holds the six