U Mobile 如何基于 Amazon Bedrock AgentCore 构建智能体电信运维系统 AiDaH

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.

1. Reach: agents that coordinate across backend systems in real time.
2. Depth: chain-of-thought reasoning for multi-step root cause analysis.
3. 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-tier role-based access control model and session metadata.

Layer 6: Operational systems

U 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.

How a request flows through the layers

Tracing 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.

1. Interface: The Teams message reaches an AWS Lambda function, which forwards the request and the caller’s federated identity to the orchestrator.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.

Onboarding 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.

Amazon Bedrock AgentCore capabilities in production

The following table maps each AgentCore capability to the job it does in AiDaH.

Securing the foundation

Deploying 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.

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.

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.

Every 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.

Over 150 documented operational scenarios

The scenarios AiDaH covers currently span six domains. The following table summarizes the coverage in each.

Measuring progress: An AI competency model

To 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.

AiDaH reached Level 7 within nine months of the first pilot: specialist agents collaborate, use tools, retrieve governed knowledge, and support operational decision-making across domains. Level 8, where problems are detected, diagnosed, and resolved without human involvement, is the current target.

Driving adoption: From tool to teammate

Deploying AiDaH was one challenge. Getting people to trust and use it was another.

ISD recognized early that adoption isn’t a technology problem but a behavior change challenge. Staff were accustomed to established workflows, trusted tools, and familiar escalation paths. Introducing AiDaH meant asking them to change deeply embedded habits. It also meant trusting an AI to retrieve information, diagnose problems, and propose next steps on their behalf.

The team leaned on directed prompting. Rather than expecting open-ended exploration, ISD provided structured prompt templates for common scenarios. Those templates turned “ask AiDaH anything” into “here is exactly how to ask for a billing check or a port-in status.” That reduced hesitation and produced immediate, tangible results. When responses proved fast, accurate, and actionable, word spread. An internal survey rated the platform 4.6 out of 5 for ease of use, and daily use is now routine among frontline teams.

The clearest signal came when AiDaH was formally incorporated into U Mobile’s L2 support standard operating procedures. Moving from optional tool to auditable SOP is what marked the shift from experimentation to operations.

ISD’s approach was never about buying a finished solution. It was about owning the journey: building internal AI capability, encouraging responsible experimentation, and embedding practical AI fluency into the daily operating rhythm. Beyond AiDaH itself, ISD maintains a dedicated internal AI channel where teams share use cases, techniques, and early experiments. The goal isn’t to concentrate AI expertise in one team but to distribute it, so every division can use AI confidently within governed guardrails. Progress was not linear. The path involved setbacks and recalibrations, and each one made the platform and the team stronger.

Results

According to U Mobile’s internal measurements, monthly trouble ticket volumes declined across three major categories between January and September 2026:

• Provisioning and network tickets fell 84.5 percent.
• General inquiries dropped 81.6 percent.
• Billing and charging reduced by 48.7 percent.

How the team built it: Spec-driven development with Kiro

U Mobile accelerated AiDaH’s development using Kiro, the AWS agentic IDE built around spec-driven development. In Kiro, a new capability begins as a spec rather than a prompt: requirements, design, and task breakdown are written down and reviewed first, and code generation works against that agreed artifact. For AiDaH, this mattered most at the agent and tool boundary. Each new operational domain means a new gateway, a set of MCP tool definitions, and the role-based access control entries that decide who might call them. Writing those down first made each new domain a repeatable unit of work rather than a fresh design exercise.

The supporting toolchain is conventional. The team used Kiro IDE for local development, with agent hooks and MCP integrations, alongside Kiro CLI for pipeline automation. Source control runs on GitLab, with AWS CodePipeline and AWS CodeBuild driving continuous integration, container images published to Amazon Elastic Container Registry (Amazon ECR), and SonarQube providing continuous code quality scanning. Specifications drove the code generation. The discipline let a small team grow from a two-use-case proof of concept to over 150 documented use cases on a 12-week sprint cadence.

Key architectural decisions

Several choices shaped how AiDaH scaled from proof of concept to production platform. Four stand out, each one reducing the cost of adding the next operational domain or keeping the platform governable as it grew.

AgentCore as managed infrastructure – Rather than building a custom agent framework, the team used the built-in scaling, identity, memory, and observability capabilities in Amazon Bedrock AgentCore. AWS manages the underlying provisioning, scaling, and patching, which removed an entire layer of infrastructure engineering.

MCP for universal tool connectivity – Standardizing on the Model Context Protocol means AiDaH can onboard new backend systems without rebuilding agent logic. Each new operational domain needs a new gateway, not a new integration architecture.

A2A for specialist collaboration – The Agent2Agent protocol lets domain specialists delegate subtasks to each other. A query spanning customer records, interface logs and billing data routes naturally across the relevant agents.

Secure foundation first – Running the Well-Architected Security Review on the Landing Zone before scaling to production means security controls are inherited by every new agent and gateway, rather than bolted on afterwards.

What’s next

U Mobile’s roadmap focuses on expanding both breadth and depth: onboarding additional operational domains and backend integrations, while evolving the platform’s capabilities from single-system queries toward multi-system correlated diagnosis. The longer-term goal, Level 8 on the competency model, is to move from informing support agents to autonomously resolving issues.

Security governance matures in parallel. The team is aligning practices with NIST SP 800-53, the OWASP Top 10 for LLM Applications, the CSA AI Trust Framework, and MITRE ATLAS. Compliance with Malaysia’s Personal Data Protection Act and Malaysian Communications and Multimedia Commission regulations continues alongside it.

Conclusion

AiDaH shows what changes when AI stops assisting and starts acting. In under a year, U Mobile went from a two-agent proof of concept to eight specialist agents serving over 150 documented operational scenarios. According to U Mobile’s internal measurements, trouble tickets fell by up to 84.5 percent in key categories, and U Mobile has now written the platform into its formal L2 support procedures.

We walked through the six layers, followed a request from Teams to an on-premises system and back, and described the Well-Architected Security Review that preceded the production scale up. The technical foundation mattered, but so did the less glamorous work. That meant validating the Landing Zone before scaling, writing structured prompts so staff knew how to start, and treating adoption as a behavior change problem rather than a deployment milestone. Teams facing similar system fragmentation might find the same pattern useful. Start with a managed agent runtime, add a standard tool protocol at the integration boundary, and run a security review before the scale up rather than after it.

The direction remains clear: expand securely, automate responsibly, and move steadily toward autonomous, self-healing operations, one deliberate and governed step at a time.

To learn more, visit Amazon Bedrock AgentCore and the Amazon Bedrock AgentCore Developer Guide. To explore spec-driven development, see Kiro.

About the authors