{"slug": "how-u-mobile-built-agentic-telco-operations-with-amazon-bedrock-agentcore", "title": "How U Mobile built agentic telco operations with Amazon Bedrock AgentCore", "summary": "U Mobile's Information Systems Division built AiDaH, an AI-Driven Agentic Helpdesk on Amazon Bedrock AgentCore with AWS and AWS Partner Axrail, and within a year of starting the journey the system 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. The Malaysian 5G network provider began conceptualization in late 2025 with two pilot agents on Amazon Bedrock Knowledge Bases, choosing AgentCore for its managed agent runtime and built-in memory that carries conversational context without a separate state store.", "body_md": "## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# How U Mobile built agentic telco operations with Amazon Bedrock AgentCore\n\nU 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.\n\nWhen 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.\n\nTraditional 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.\n\nU 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.\n\nIn 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.\n\n## The problem: Too many systems, too much friction\n\nU 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.\n\nBefore 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.\n\nThe ISD team’s strategy rested on three pillars.\n\n1. **Reach** : agents that coordinate across backend systems in real time.\n2. **Depth** : chain-of-thought reasoning for multi-step root cause analysis.\n3. **Community** : a secure multi-tenant framework with role-based access control and built-in guardrails, available to every division.\n\n## The journey: From knowledge base to agentic platform\n\nAiDaH 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.\n\n## What agentic means in practice\n\nThe difference between traditional AI assistance and agentic AI is best illustrated through a real example.\n\nWith 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.\n\nWith 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.\n\nIn 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.\n\n## Architecture: Six layers, one interface\n\nAiDaH 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.\n\nThe following diagram shows how the layers fit together.\n\nAs shown in Figure 1, the platform is organized into six layers.\n\n**Layer 1: Staff interface**\n\nStaff 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.\n\n**Layer 2: Orchestration**\n\nThe 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.\n\n**Layer 3: Specialist agents**\n\nEight 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.\n\n**Layer 4: Gateways and backend APIs**\n\nAgentCore 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.\n\n**Layer 5: Data and knowledge**\n\nAmazon 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-tier role-based access control model and session metadata.\n\n**Layer 6: Operational systems**\n\nU Mobile’s on-premises and cloud operational systems are reached over AWS Transit Gateway and AWS Site-to-Site VPN, an IPsec-encrypted tunnel with no public internet exposure.\n\n### How a request flows through the layers\n\nTracing a single request makes the interaction between the layers concrete. Consider a support agent who types a port-in status question into the AiDaH channel in Microsoft Teams.\n\n1. **Interface:** The Teams message reaches an AWS Lambda function, which forwards the request and the caller’s federated identity to the orchestrator.\n2. **Pre-flight check:** The orchestrator resolves the caller against the six-tier role-based access control model held in Amazon DynamoDB, validates the token issued by AgentCore Identity, a capability of Amazon Bedrock AgentCore, and applies Amazon Bedrock Guardrails to the incoming prompt. A request that fails any of these checks stops here.\n3. **Routing:** The orchestrator selects the cheapest tier that can handle the request. A recognized phrase such as “port-in status” matches deterministically and skips model invocation entirely. An ambiguous phrasing goes to the lightweight classifier. A novel or multi-part question goes to the full orchestrator.\n4. **Agent instantiation:** The selected specialist agent runs as a session in AgentCore runtime, a capability of Amazon Bedrock AgentCore. AgentCore memory rehydrates the conversation so the agent inherits the subscriber number and any prior findings from earlier turns, instead of asking the user to repeat them.\n5. **Tool discovery and invocation:** The agent queries AgentCore Gateway for the tools it is entitled to use. Each gateway publishes its backend as MCP tools with typed inputs and outputs, so the agent picks a tool by name and schema rather than by hand-coded integration logic. Amazon Cognito brokers the OAuth authorization for the call.\n6. **Backend call:** The gateway’s Lambda function or MCP server translates the tool call into a request against the target system, traversing AWS Transit Gateway and the Site-to-Site VPN tunnel to reach the on-premises number portability platform. Sensitive fields are masked on the way back, before the response reaches the model.\n7. **Reasoning and collaboration:** If the answer spans domains, the agent delegates over the Agent2Agent protocol. A port-in query that turns out to be a billing block, for example, hands off to the business support systems agent, and the results are merged into one narrative.\n8. **Response and audit:** The agent grounds its explanation against Amazon Bedrock Knowledge Bases, then returns the finding and proposed remediation to Teams for human confirmation. AgentCore Observability, a capability of Amazon Bedrock AgentCore, writes the full trace of prompts, tool calls, token counts, and latencies to Amazon CloudWatch, and AWS CloudTrail records the corresponding API activity.\n\nOnboarding a new operational domain adds a gateway and its MCP tool definitions at step 5. Steps 1–4, and steps 7 and 8, are unchanged. The stable core is what keeps the marginal cost of each new domain low.\n\n### Amazon Bedrock AgentCore capabilities in production\n\nThe following table maps each AgentCore capability to the job it does in AiDaH.\n\n| **Capability** | **Role in AiDaH** | \n| Runtime | Hosts AiDaH and its sub-agents as managed containers that scale automatically, with no servers to provision | \n| Memory | Maintains conversational context such as subscriber number, order IDs, and prior findings across turns | \n| Identity | Issues short-lived access tokens so only authorized users can invoke agents | \n| Gateway | Connects agents to U Mobile backends through a unified, secure MCP interface | \n| Observability | Streams every prompt, tool call, token count, and latency measurement to Amazon CloudWatch | \n\n## Securing the foundation\n\nDeploying an agentic AI platform that reaches subscriber data, billing systems and network infrastructure demands more than application-level security. It requires a secure cloud foundation. U Mobile took a two-pronged approach: validating and enhancing the underlying AWS Landing Zone, and building on the security capabilities in Amazon Bedrock AgentCore.\n\n**Landing Zone security –** Before scaling AiDaH to production, U Mobile engaged AWS to run a Well-Architected Security Review of the Landing Zone hosting the platform. The review validated the environment against AWS security best practices. Infrastructure protection came first, through AWS Control Tower guardrails and AWS Organizations service control policies. The review then examined centralized identity federation and network security controls for ingress and egress. Consolidated security findings in AWS Security Hub and encryption standards across every architecture tier completed the assessment. The outcome was twofold: confidence that every AiDaH component operates on an independently validated foundation, and a prioritized roadmap for continuous improvement.\n\n**Application-layer security –** Every agent action traces to a specific authenticated user. Staff federate through Microsoft Entra ID, and AgentCore Identity issues the short-lived token that authorizes agent invocation. Amazon Cognito brokers OAuth authorization at the gateway. An agent can therefore reach only the systems its invoking user is entitled to see. A six-tier role-based access control model enforces permissions per agent, per tool, and per data source. Sensitive subscriber data is masked at the gateway before it reaches the model, with Amazon Bedrock Guardrails enforcing content policies.\n\nEvery prompt, tool invocation and response is streamed to Amazon CloudWatch Logs through AgentCore Observability, and AWS CloudTrail records the underlying API activity. That audit trail matters: AiDaH is now written into U Mobile’s L2 support standard operating procedures and is subject to operational audit. All compute runs in private VPC subnets, on-premises connectivity is exclusively over encrypted VPN, and AWS Key Management Service (AWS KMS) manages encryption keys for data at rest and in transit.\n\n## Over 150 documented operational scenarios\n\nThe scenarios AiDaH covers currently span six domains. The following table summarizes the coverage in each.\n\n| **Domain** | **Coverage** | \n| Customer management | Account details, billing history, payment status, active plans and contracts, SIM information, service status | \n| Order operations and logistics | Order and delivery status, pending orders, resource allocation, tracing workflows, delivery tracking, shipment history | \n| Customer problem management | Root-cause diagnosis for failed add-on purchases, plan changes and top-up failures. Number portability port-in and port-out checks. Service disruption diagnosis across SMS, calls and data | \n| IT infrastructure operations | Server and device status monitoring, IP and hostname lookups, network device inventory | \n| Business intelligence and analytics | Subscriber trend analysis, device take-up trends, revenue trending, anomaly detection, individual subscriber analytics. The analytics agent converts plain-language questions into SQL queries, so no technical skills are required | \n| Knowledge retrieval | Enterprise-wide retrieval with context-aware, grounded responses and citations back to source evidence | \n\n## Measuring progress: An AI competency model\n\nTo track progress and establish a shared vocabulary across the organization, the team adopted an eight-level AI competency model, from basic digital access to autonomous self-healing operations. It draws on industry thinking, including the TM Forum Autonomous Networks maturity levels, adapted to U Mobile’s operational context. The following table lists the eight levels.\n\n| **Level** | **Name** | **Description** | \n| 1 | Digital access | Self-service portals, online tools and dashboards | \n| 2 | Scripted automation | Rules-based workflow triggers and auto-routing | \n| 3 | Basic AI assistance | Simple chatbots, FAQ look-ups, intent classification | \n| 4 | Contextual intelligence | Context-aware suggestions, basic natural language understanding with memory | \n| 5 | Proactive AI | Predictive alerts, anomaly detection, recommendation engines | \n| 6 | Autonomous task execution | AI completes defined tasks end to end with guardrails | \n| 7 | Collaborative multi-agent | Specialist agents collaborate, use tools, retrieve governed knowledge | \n| 8 | Self-healing and adaptive | Autonomous systems that detect, diagnose, remediate, and learn continuously | \n\nAiDaH", "url": "https://wpnews.pro/news/how-u-mobile-built-agentic-telco-operations-with-amazon-bedrock-agentcore", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/how-u-mobile-built-agentic-telco-operations-with-amazon-bedrock-agentcore/", "published_at": "2026-11-04 16:23:33+00:00", "updated_at": "2026-11-04 16:50:04.008977+00:00", "lang": "en", "topics": ["ai-agents", "artificial-intelligence", "ai-products", "ai-tools"], "entities": ["U Mobile", "Amazon Bedrock AgentCore", "AWS", "Axrail", "AiDaH", "Amazon Bedrock Knowledge Bases"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-u-mobile-built-agentic-telco-operations-with-amazon-bedrock-agentcore", "markdown": "https://wpnews.pro/news/how-u-mobile-built-agentic-telco-operations-with-amazon-bedrock-agentcore.md", "text": "https://wpnews.pro/news/how-u-mobile-built-agentic-telco-operations-with-amazon-bedrock-agentcore.txt", "jsonld": "https://wpnews.pro/news/how-u-mobile-built-agentic-telco-operations-with-amazon-bedrock-agentcore.jsonld"}}