U Mobile 如何与 Amazon Bedrock 代理公司建立代理泰尔科操作

中文版正在随流水线自动整理，稍后刷新即可；可先阅读下方英文原文。

本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Artificial Intelligence

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.

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.

- Interface: The Teams message reaches an AWS Lambda function, which forwards the request and the caller’s federated identity to the orchestrator.

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

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

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

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

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

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

- 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, throug

Auto-fetched and translated by AI Atlas. All rights belong to the original author.