ZICQ
中 Log in / Sign up
Newsroom Agentic #Amazon Bedrock AgentCore #Multi-Agent Systems #MCP #Telco Operations #Enterprise AI

U Mobile Builds an Agentic Telco Operations Platform on Bedrock AgentCore

Avatar of Mr.Xu

By Mr.Xu Compiled & Reviewed by Editorial

Published:

中文阅读 (Chinese) English Version

Summary:Malaysian telecom operator U Mobile has deployed AiDaH, an agentic operations platform built on Amazon Bedrock AgentCore. The system hosts eight specialist agents, exposes operational backends through standardized MCP gateways, and coordinates cross-domain work via the Agent2Agent protocol. It now covers more than 150 documented scenarios across six business divisions. According to U Mobile’s internal measurements, trouble-ticket volumes in selected categories fell by as much as 84.5% between Ja


From Copilot to Operational Agent

U Mobile has put AiDaH (AI-Driven Agentic Helpdesk) into production on Amazon Bedrock AgentCore. Rather than merely drafting customer-service responses, the platform queries logs, verifies subscriber status, retrieves business policies, identifies failure points, and proposes remediation plans. Actions that could change a live subscriber account still require human confirmation before execution.

Nine months after production launch, AiDaH covers more than 150 documented scenarios across six business divisions. U Mobile reports that between January and September 2026, provisioning and network tickets fell 84.5%, general inquiries fell 81.6%, and billing tickets fell 48.7%. These are internal measurements rather than independently controlled benchmarks. Ticket classification, seasonality, and other process changes would need to be disclosed before attributing the full improvement to agentic AI.

A Six-Layer Architecture for Fragmented Telco Systems

AiDaH runs in the AWS Asia Pacific (Singapore) Region while reaching deeply into U Mobile’s on-premises IT estate. Its six layers are:

  1. Staff interface: Microsoft Teams and a web portal, with an AWS Lambda backend and REST API for programmatic triggers.
  2. Orchestration: Amazon Bedrock AgentCore routes each request after identity validation, six-tier RBAC, and Bedrock Guardrails checks.
  3. Specialist agents: Eight agents cover CRM, customer problem management, number portability, orders and SIM operations, infrastructure monitoring, big-data analytics, cloud cost, and finance.
  4. Gateways and backend APIs: AgentCore Gateway exposes backends as MCP tools, implemented through Lambda functions or MCP servers.
  5. Data and knowledge: Bedrock Knowledge Bases and OpenSearch Serverless provide governed RAG; AgentCore Memory preserves conversational context, while DynamoDB stores RBAC and session metadata.
  6. Operational systems: On-premises and cloud systems are connected through Transit Gateway and an IPsec Site-to-Site VPN without public exposure.

A request begins in Teams, where AgentCore Identity issues a short-lived token and Cognito brokers downstream OAuth authorization. The selected specialist discovers the tools it is allowed to use, queries the appropriate backend, and delegates cross-domain work to other agents over A2A. Bedrock Knowledge Bases grounds the final explanation, while proposed remediation returns to Teams for confirmation.

Tiered Routing to Control Cost and Latency

AiDaH does not send every request to a large model. Approximately 70% are handled through deterministic keyword matching, 20% are classified by a lightweight model, and only 10% reach the full orchestrator.

The architectural benefit is the separation of capability from inference. Common structured requests such as port-in status avoid unnecessary model calls, reducing latency, token expenditure, and nondeterminism. Only ambiguous or multi-system requests are escalated.

Routing percentages alone do not establish quality, however. Insufficient keyword coverage can misroute difficult requests, while classifier errors can create unnecessary inference or miss escalation. Production monitoring should therefore track routing accuracy, escalation rate, end-to-end latency, cost per resolved ticket, and blocked-error rates rather than relying on the model-call ratio.

MCP, A2A, and a Stable Core

The platform standardizes both tool connectivity and inter-agent coordination. MCP provides named tools with typed schemas, so onboarding a new domain mainly means adding a Gateway and tool definitions. A2A allows specialists in number portability, CRM, and billing to delegate subtasks and merge results. This is more scalable than hard-coding a separate integration path for every backend.

MCP does not, however, guarantee correct business semantics. Ambiguous descriptions, incomplete schemas, and unstable backend error codes can produce successful tool calls that lead to incorrect diagnoses. Each tool still needs a testable contract, idempotency rules, timeout handling, compensating actions, and explicit error classifications. The boundary also needs adversarial testing for prompt injection, tool-description poisoning, and unauthorized cross-tool data movement.

Security Embedded in the Execution Path

Before scaling AiDaH, U Mobile ran a Well-Architected Security Review of its AWS Landing Zone. Infrastructure controls include Control Tower guardrails, Organizations service control policies, Security Hub, centralized identity, and network segmentation. Application controls combine Microsoft Entra ID federation, short-lived AgentCore Identity tokens, Cognito OAuth, six-tier RBAC, gateway-level masking, and Bedrock Guardrails.

AgentCore Observability streams prompts, tool calls, responses, token counts, and latency metrics to CloudWatch, while CloudTrail records API activity. Compute resides in private VPC subnets, on-premises connectivity uses encrypted VPN tunnels, and KMS manages encryption keys.

The important principle is not to let the model roam freely, but to constrain what it can observe and execute. Human confirmation remains in place for changes affecting live subscriber accounts. Moving toward the stated Level 8 self-healing goal will require additional idempotency, action allowlists, maintenance windows, rollback mechanisms, and an independent policy engine.

Spec-Driven Development as a Scaling Mechanism

U Mobile used Kiro to develop AiDaH through a spec-driven workflow: requirements, design, and task decomposition are documented and reviewed before code generation. This is particularly valuable at the agent-tool-permission boundary, where each new domain requires a Gateway, MCP definitions, and corresponding RBAC entries.

The supporting stack includes GitLab, CodePipeline, CodeBuild, ECR, and SonarQube. The team reports expanding from a two-use-case proof of concept to more than 150 use cases over 12-week sprint cycles. Specification does not automatically guarantee correctness, but it makes interface contracts and permission requirements explicit, making the system easier to audit and scale across a team.

How to Interpret the Reported Results

The headline figure—an 84.5% reduction in selected ticket categories—is compelling, but it is not equivalent to model accuracy or full automation. AiDaH remains human-in-the-loop, and ticket reductions may also reflect standardized procedures, improved knowledge retrieval, and a unified Teams entry point. Its inclusion in U Mobile’s L2 support standard operating procedures is stronger evidence of operational adoption than a one-off pilot.

A more rigorous evaluation would report scenario-level diagnosis accuracy and root-cause recall; compare human, rules-only, and agent-assisted paths; ablate routing and remediation components; track P50/P95 latency and cost per ticket; measure repeat contacts and customer wait time; and independently audit financial and network-changing workflows.

Practical Deployment Guidance

Teams considering a similar architecture should:\n

  • Start with frequent, read-only, reversible operations rather than autonomous production-network repair.
  • Define strict schemas, authorization boundaries, idempotency semantics, and error codes for every tool.
  • Put deterministic rules before model inference and continuously monitor escalation rates.
  • Treat identity propagation and auditability as platform capabilities rather than later patches.
  • Mask sensitive fields at the gateway before data reaches the model.
  • Require approval, action budgets, and rollback paths for write operations.
  • Evaluate against business and safety metrics, not dialogue volume or model-call counts.

AiDaH’s production value comes from the surrounding engineering discipline. Standard protocols reduce integration cost, tiered routing controls inference overhead, managed runtime and memory reduce platform burden, and RBAC, masking, and audit constrain risk. The model proposes conclusions; the platform determines what it can see, what it can do, and when authority must return to a human.


Source: AWS Machine Learning Blog (2026-11-04)

— END —

Tags: #Amazon Bedrock AgentCore #Multi-Agent Systems #MCP #Telco Operations #Enterprise AI

Editorial & Fact-Checking Note: This article is compiled from primary research, official release documentation, and source papers by the ZICQ Newsroom pipeline with automated entity verification and human editorial review. If you notice any technical inaccuracy, please submit a correction via our corrections policy or email our editorial desk directly.

Community Comments

Loading live comments and annotations…