U Mobile, el proveedor de red 5G más nuevo de Malasia, siempre ha operado sus operaciones de telecomunicaciones de manera eficiente, haciendo más con menos mediante automatización continua. Cuando nuevas capacidades de IA estuvieron disponibles, U Mobile exploró cómo mejorar la eficiencia operativa más allá de las ganancias básicas de productividad. La verdadera oportunidad estaba más atrás en el proceso, en cómo los equipos de operaciones diagnostican y resuelven los problemas desde el principio. La misma disciplina operativa eficiente dio forma a los cimientos de AiDaH: no una iniciativa tecnológica puntual, sino el siguiente paso en un viaje de larga data para simplificar las operaciones y escalar capacidades sin agregar complejidad.
Cuando un suscriptor no puede comprar un paquete de datos adicional, resolverlo no es un solo problema. Es un problema de coordinación. Un agente de servicio al cliente necesita extraer registros de interfaz para los códigos de error. El mismo agente luego debe consultar las API del sistema de soporte comercial para verificar la elegibilidad del suscriptor, y hacer referencias cruzadas en bases de conocimiento internas para las políticas comerciales aplicables. Todo eso sucede en múltiples sistemas, antes de redactar una sola palabra de respuesta. Y cuando eso falla, el ticket escala a los equipos de TI de back-end y el suscriptor espera aún más tiempo.
Las herramientas de automatización tradicionales pueden ayudar a los agentes a redactar mejores respuestas. Lo que no pueden hacer es navegar por múltiples sistemas, analizar los resultados y proponer acciones correctivas. Cerrar esa brecha requiere una arquitectura agéntica construida sobre Amazon Bedrock AgentCore.
La División de Sistemas de Información (ISD) de U Mobile construyó exactamente eso. Trabajando con AWS y el socio de AWS Axrail, crearon AiDaH, el AI-Driven Agentic Helpdesk, sobre Amazon Bedrock AgentCore, una plataforma para construir, conectar y optimizar agentes a escala, con cualquier framework o modelo. Dos capacidades decidieron la elección. El runtime de agentes administrado significó que no hubo infraestructura de agentes que operar. La memoria integrada mantuvo el contexto conversacional a lo largo de los turnos sin necesidad de un almacén de estado separado. Dentro del primer año del viaje, AiDaH gestiona más de 150 escenarios operativos documentados en seis divisiones de negocio. Las mediciones internas de U Mobile muestran que los volúmenes de tickets de incidencias caen hasta un 84,5 por ciento en categorías clave.
En esta publicación, recorremos la arquitectura de seis capas detrás de AiDaH. Luego describimos la base de seguridad debajo de la plataforma, y cerramos con una breve nota sobre el método basado en especificaciones que el equipo utilizó para construirla.
El problema: demasiados sistemas, demasiada fricción
El panorama de TI de U Mobile refleja la complejidad típica de las telecomunicaciones modernas: sistemas de soporte comercial y gestión de relaciones con clientes, plataformas de portabilidad de números móviles, análisis de big data y herramientas de monitoreo de infraestructura, funcionando de forma híbrida entre instalaciones locales y la nube.
Antes de AiDaH, esta fragmentación significaba que incluso los diagnósticos de rutina requerían revisar registros manualmente, consultar la elegibilidad del suscriptor y buscar en bases de conocimiento las políticas comerciales, a través de sistemas y portales separados. Cada consulta era un cambio de contexto, cada cambio de contexto era tiempo perdido, y cada consulta sin resolver se convertía en una escalación a un equipo de TI de back-end. Ampliar la cobertura a dominios operativos adicionales agravaba el problema, porque cada sistema nuevo típicamente requería una integración a medida.
La estrategia del equipo de ISD se basó en tres pilares.
- Alcance: agentes que coordinan a través de sistemas de back-end en tiempo real.
- Profundidad: razonamiento de cadena de pensamiento para análisis de causa raíz de múltiples pasos.
- Comunidad: un framework multiinquilino seguro con control de acceso basado en roles y salvaguardas integradas, disponible para cada división.
El viaje: de la base de conocimiento a la plataforma agéntica
AiDaH comenzó con un principio: pensar en grande, empezar en pequeño. U Mobile inició la conceptualización a finales de 2025 con dos agentes piloto y Amazon Bedrock Knowledge Bases, una capacidad de Generación Aumentada por Recuperación (RAG) totalmente administrada. Un piloto en el Q1 de 2026 puso en línea la mesa de ayuda interna de TI con 4 agentes y 20 escenarios operativos. A lo largo de 2026 la plataforma se fortaleció y expandió, agregando enrutamiento de tres niveles y alcanzando 6 agentes a mitad de año. AiDaH se lanzó a 50 usuarios de L2 de centros de llamadas y sucursales en el Q3 de 2026 con 8 agentes, y ahora cubre más de 150 escenarios operativos documentados.
Qué significa agéntico en la práctica
La diferencia entre la asistencia de IA tradicional y la IA agéntica se ilustra mejor con un ejemplo real.
Con un asistente de IA tradicional, un agente de soporte que maneja “datos móviles que no funcionan en el extranjero” recibe ayuda para redactar una respuesta y algunos pasos de solución de problemas sugeridos, pero aún debe verificar manualmente el estado de roaming, confirmar la elegibilidad, crear tickets y enviar la respuesta final.
Con AiDaH, el sistema verifica de forma independiente la configuración de roaming del suscriptor, confirma la elegibilidad de datos internacionales e identifica el punto específico de fallo. Luego ensambla un plan de remediación: qué servicios restablecer, qué configuración aplicar y si se justifica un ticket de red. El agente de soporte revisa y confirma, y las acciones se ejecutan. La investigación que antes consumía el tiempo del agente ahora sucede antes de que lea la primera línea. El punto de decisión humano se preserva donde importa: en el momento en que algo cambia en la cuenta de un suscriptor activo.
En un caso de producción, un suscriptor informó que no podía comprar un complemento. AiDaH rastreó el fallo hasta un código de error, "El suscriptor tiene un pedido pendiente". También reveló que el cliente había intentado la misma compra más de 30 veces a través de múltiples canales durante tres días, y cada intento fue bloqueado por el mismo pedido pendiente subyacente. AiDaH mostró la causa raíz y los pasos de remediación en una sola respuesta. Anteriormente, eso habría requerido una investigación manual en varios sistemas.
Arquitectura: seis capas, una interfaz
AiDaH funciona sobre una arquitectura por capas construida en Amazon Bedrock AgentCore, desplegada en la Región de Asia Pacífico (Singapur). El personal interactúa a través de Microsoft Teams, una elección deliberada para encontrarse con la mayoría de los usuarios donde ya trabajan, sin una nueva aplicación que aprender y sin cambios de portal.
El siguiente diagrama muestra cómo se ajustan las capas entre sí.
Figura 1: Arquitectura por capas de AiDaH
Como se muestra en la Figura 1, la plataforma está organizada en seis capas.
Capa 1: Interfaz del personal
El personal accede a AiDaH a través de Microsoft Teams y un portal web servido por Amazon CloudFront y protegido por AWS WAF, con un backend de AWS Lambda y una API REST para activaciones programáticas.
Capa 2: Orquestación
El cerebro de enrutamiento sobre Amazon Bedrock AgentCore. Cada solicitud pasa una verificación de seguridad previa que cubre control de acceso basado en roles, validación de identidad y guardrails, y luego entra en un nivel de enrutamiento optimizado por costos. Aproximadamente el 70 por ciento de las solicitudes se resuelven mediante coincidencia determinista de palabras clave sin invocación de modelos, el 20 por ciento se clasifican con un modelo ligero, y solo el 10 por ciento requieren el orquestador completo. La ruta más barata que puede manejar la solicitud con confianza es la que se ejecuta.
Capa 3: Agentes especialistas
Ocho expertos que abarcan gestión de relaciones con clientes, gestión de problemas de clientes, portabilidad de números, operaciones de pedidos y SIM, monitoreo de infraestructura, análisis de big data, gestión de costos en la nube y operaciones financieras. Se comunican mediante el protocolo Agent2Agent (A2A), que les permite delegar subtareas y completar flujos de trabajo entre sistemas que ningún agente podría manejar solo.
Capa 4: Pasarelas y APIs de backend
AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, expone los backends de U Mobile a los agentes a través de una interfaz unificada de Model Context Protocol (MCP). Detrás de cada pasarela se encuentran funciones de AWS Lambda y servidores MCP que traducen la intención del agente en llamadas contra un sistema específico.
Capa 5: Datos y conocimiento
Amazon Bedrock Knowledge Bases, la capacidad RAG totalmente administrada, fundamenta las respuestas de los agentes en contenido gobernado, utilizando un almacén de vectores de Amazon OpenSearch Serverless. El contenido abarca una base de conocimiento empresarial compartida y un corpus financiero separado. AgentCore memory, una capacidad de Amazon Bedrock AgentCore, mantiene el contexto conversacional entre turnos, y Amazon DynamoDB almacena el modelo de control de acceso basado en roles de seis niveles y los metadatos de sesión.
Capa 6: Sistemas operativos
Los sistemas operativos locales y en la nube de U Mobile se alcanzan a través de AWS Transit Gateway y AWS Site-to-Site VPN, un túnel cifrado con IPsec sin exposición a internet pública.
Cómo fluye una solicitud a través de las capas
Rastrear una sola solicitud hace concreta la interacción entre las capas. Considere un agente de soporte que escribe una pregunta sobre el estado de una portabilidad de número en el canal de AiDaH en Microsoft Teams.
- Interfaz: El mensaje de Teams llega a una función de AWS Lambda, que reenvía la solicitud y la identidad federada del llamante al orquestador.
- Verificación previa: El orquestador resuelve al llamante contra el modelo de control de acceso basado en roles de seis niveles almacenado en Amazon DynamoDB, valida el token emitido por AgentCore Identity, una capacidad de Amazon Bedrock AgentCore, y aplica Amazon Bedrock Guardrails al prompt entrante. Una solicitud que falle cualquiera de estas comprobaciones se detiene aquí.
- Enrutamiento: El orquestador selecciona el nivel más barato que pueda manejar la solicitud. Una frase reconocida como "estado de portabilidad" coincide de forma determinista y se salta por completo la invocación de modelos. Una redacción ambigua va al clasificador ligero. Una pregunta novedosa o de varias partes va al orquestador completo.
- Creación de instancias del agente: El agente especialista seleccionado se ejecuta como una sesión en AgentCore runtime, una capacidad de Amazon Bedrock AgentCore. AgentCore memory rehidrata la conversación para que el agente herede el número de suscriptor y cualquier hallazgo previo de turnos anteriores, en lugar de pedir al usuario que los repita.
- Descubrimiento e invocación de herramientas: El agente consulta a AgentCore Gateway por las herramientas que tiene derecho a usar. Cada pasarela publica su backend como herramientas MCP con entradas y salidas tipadas, de modo que el agente elige una herramienta por nombre y esquema en lugar de mediante lógica de integración codificada a mano. Amazon Cognito intermedia la autorización OAuth para la llamada.
- Llamada al backend: La función de Lambda de la pasarela o el servidor MCP traduce la llamada a la herramienta en una solicitud contra el sistema objetivo, atravesando AWS Transit Gateway y el túnel de Site-to-Site VPN para llegar a la plataforma local de portabilidad de números. Los campos sensibles se enmascaran en el camino de vuelta, antes de que la respuesta llegue al modelo.
- Razonamiento y colaboración: Si la respuesta abarca varios dominios, el agente delega mediante el protocolo Agent2Agent. Una consulta de portabilidad que resulta ser un bloqueo de facturación, por ejemplo, se transfiere al agente de sistemas de soporte empresarial, y los resultados se combinan en una sola narrativa.
- Respuesta y auditoría: El agente fundamenta su explicación en Amazon Bedrock Knowledge Bases y, a continuación, devuelve el hallazgo y la remediación propuesta a Teams para su confirmación humana. AgentCore Observability, una capacidad de Amazon Bedrock AgentCore, escribe el rastro completo de prompts, llamadas a herramientas, recuentos de tokens y latencias en Amazon CloudWatch, y AWS CloudTrail registra la actividad de API correspondiente.
La incorporación de un nuevo dominio operativo añade una gateway y sus definiciones de herramientas MCP en el paso 5. Los pasos 1–4, y los pasos 7 y 8, permanecen sin cambios. El núcleo estable es lo que mantiene bajo el costo marginal de cada nuevo dominio.
Capacidades de Amazon Bedrock AgentCore en producción
La siguiente tabla relaciona cada capacidad de AgentCore con la función que desempeña en AiDaH.
| Capacidad | Función en AiDaH |
| Runtime | Aloja AiDaH y sus sub-agentes como contenedores administrados que escalan automáticamente, sin servidores que aprovisionar |
| Memory | Mantiene el contexto conversacional, como el número de suscriptor, los IDs de pedido y los hallazgos previos, a lo largo de los turnos |
| Identity | Emite tokens de acceso de corta duración para que solo los usuarios autorizados puedan invocar agentes |
| Gateway | Conecta los agentes a los backends de U Mobile a través de una interfaz MCP unificada y segura |
| Observability | Transmite cada prompt, llamada a herramientas, conteo de tokens y medición de latencia a Amazon CloudWatch |
Asegurando la base
Desplegar una plataforma de IA agéntica que accede a datos de suscriptores, sistemas de facturación e infraestructura de red exige más que seguridad a nivel de aplicación. Requiere una base de nube segura. U Mobile adoptó un enfoque de dos vertientes: validar y mejorar la AWS Landing Zone subyacente, y construir sobre las capacidades de seguridad de Amazon Bedrock AgentCore.
Seguridad de la Landing Zone – Antes de escalar AiDaH a producción, U Mobile contrató a AWS para ejecutar una Well-Architected Security Review de la Landing Zone que aloja la plataforma. La revisión validó el entorno frente a las mejores prácticas de seguridad de AWS. La protección de la infraestructura fue lo primero, mediante las guardrails de AWS Control Tower y las políticas de control de servicios de AWS Organizations. La revisión examinó luego la federación de identidades centralizada y los controles de seguridad de red para ingress y egress. Los hallazgos de seguridad consolidados en AWS Security Hub y los estándares de cifrado en cada nivel de la arquitectura completaron la evaluación. El resultado fue doble: la confianza de que cada componente de AiDaH opera sobre una base validada de forma independiente, y una hoja de ruta priorizada para la mejora continua.
Seguridad a nivel de aplicación – Cada acción de un agente se rastrea hasta un usuario autenticado específico. El personal se federa a través de Microsoft Entra ID, y AgentCore Identity emite el token de corta duración que autoriza la invocación de agentes. Amazon Cognito media la autorización OAuth en la gateway. Por lo tanto, un agente solo puede alcanzar los sistemas que el usuario que lo invoca está autorizado a ver. Un modelo de control de acceso basado en roles de seis niveles aplica permisos por agente, por herramienta y por fuente de datos. Los datos sensibles de suscriptores se enmascaran en la gateway antes de llegar al modelo, con Amazon Bedrock Guardrails aplicando políticas de contenido.
Cada prompt, invocación de herramientas y respuesta se transmite a Amazon CloudWatch Logs a través de AgentCore Observability, y AWS CloudTrail registra la actividad de API subyacente. Ese rastro de auditoría es importante: AiDaH ahora está incluido en los procedimientos operativos estándar de soporte L2 de U Mobile y está sujeto a auditoría operativa. Todo el cómputo se ejecuta en subnets privadas de VPC, la conectividad on-premises es exclusivamente mediante VPN cifrada, y AWS Key Management Service (AWS KMS) gestiona las claves de cifrado para los datos en reposo y en tránsito.
Más de 150 escenarios operativos documentados
Los escenarios que AiDaH cubre actualmente abarcan seis dominios. La siguiente tabla resume la cobertura en cada uno.
| Dominio | Cobertura |
| Gestión de clientes | Detalles de cuenta, historial de facturación, estado de pagos, planes y contratos activos, información de SIM, estado de servicios |
| Operaciones de pedidos y logística | Estado de pedidos y entregas, pedidos pendientes, asignación de recursos, flujos de trabajo de trazabilidad, seguimiento de entregas, historial de envíos |
| Gestión de problemas de clientes | Diagnóstico de causa raíz para compras fallidas de complementos, cambios de plan y fallas de recarga. Verificaciones de portabilidad de números port-in y port-out. Diagnóstico de interrupciones de servicio en SMS, llamadas y datos |
| Operaciones de infraestructura de TI | Supervisión del estado de servidores y dispositivos, consultas de IP y nombres de host, inventario de dispositivos de red |
| Inteligencia empresarial y analítica | Análisis de tendencias de suscriptores, tendencias de adopción de dispositivos, tendencias de ingresos, detección de anomalías, analítica de suscriptores individuales. El agente de analítica convierte preguntas en lenguaje natural en consultas SQL, por lo que no se requieren conocimientos técnicos |
| Recuperación de conocimiento | Recuperación en toda la empresa con respuestas contextuales, fundamentadas y con citas que remiten a la evidencia de origen |
Medición del progreso: Un modelo de competencias en IA
Para hacer un seguimiento del progreso y establecer un vocabulario común en toda la organización, el equipo adoptó un modelo de competencias en IA de ocho niveles, desde el acceso digital básico hasta las operaciones autónomas de autorreparación. Se basa en el pensamiento del sector, incluidos los niveles de madurez de Autonomous Networks de TM Forum, adaptado al contexto operativo de U Mobile. La siguiente tabla enumera los ocho niveles.
| Nivel | Nombre | Descripción |
| 1 | Acceso digital | Portales de autoservicio, herramientas en línea y paneles de control |
| 2 | Automatización con scripts | Activadores de flujos de trabajo basados en reglas y enrutamiento automático |
| 3 | Asistencia básica de IA | Chatbots simples, búsquedas de preguntas frecuentes, clasificación de intenciones |
| 4 | Inteligencia contextual | Sugerencias conscientes del contexto, comprensión básica del lenguaje natural con memoria |
| 5 | IA proactiva | Alertas predictivas, detección de anomalías, motores de recomendación |
| 6 | Ejecución autónoma de tareas | La IA completa tareas definidas de extremo a extremo con salvaguardas |
| 7 | Multiagente colaborativo | Agentes especializados colaboran, usan herramientas y recuperan conocimiento gobernado |
| 8 | Autorreparación y adaptabilidad | Sistemas autónomos que detectan, diagnostican, remedian y aprenden continuamente |
AiDaH alcanzó el Nivel 7 en un plazo de nueve meses desde el primer piloto: agentes especializados colaboran, usan herramientas, recuperan conocimiento gobernado y apoyan la toma de decisiones operativas en todos los dominios. El Nivel 8, en el que los problemas se detectan, diagnostican y resuelven sin intervención humana, es el objetivo actual.
Impulsar la adopción: De herramienta a compañera de equipo
Desplegar AiDaH fue un desafío. Lograr que la gente confiara en ella y la utilizara fue otro.
ISD reconoció desde el principio que la adopción no es un problema tecnológico, sino un desafío de cambio de comportamiento. El personal estaba acostumbrado a flujos de trabajo establecidos, herramientas de confianza y rutas de escalación conocidas. Introducir AiDaH significaba pedirles que cambiaran hábitos profundamente arraigados. También significaba confiar en una IA para recuperar información, diagnosticar problemas y proponer los siguientes pasos en su nombre.
El equipo se apoyó en la instrucción dirigida. En lugar de esperar una exploración abierta, ISD proporcionó plantillas de prompts estructuradas para escenarios comunes. Esas plantillas convirtieron el "preguntarle cualquier cosa a AiDaH" en "aquí está exactamente cómo solicitar una verificación de facturación o el estado de una portabilidad". Eso redujo la vacilación y produjo resultados inmediatos y tangibles. Cuando las respuestas demostraron ser rápidas, precisas y accionables, la noticia se difundió. Una encuesta interna calificó la plataforma con 4.6 sobre 5 en facilidad de uso, y el uso diario ya es habitual entre los equipos de primera línea.
La señal más clara llegó cuando AiDaH se incorporó formalmente a los procedimientos operativos estándar de soporte L2 de U Mobile. Pasar de herramienta opcional a SOP auditable fue lo que marcó la transición de la experimentación a las operaciones.
El enfoque de ISD nunca consistió en comprar una solución terminada. Se trató de asumir el recorrido: desarrollar capacidades internas de IA, fomentar la experimentación responsable e integrar la fluidez práctica en IA en el ritmo operativo diario. Más allá de AiDaH en sí, ISD mantiene un canal interno dedicado a la IA donde los equipos comparten casos de uso, técnicas y experimentos tempranos. El objetivo no es concentrar la experiencia en IA en un solo equipo, sino distribuirla, para que cada división pueda usar la IA con confianza dentro de salvaguardas gobernadas. El progreso no fue lineal. El camino involucró contratiempos y recalibraciones, y cada uno hizo más fuertes la plataforma y el equipo.
Resultados
Según las mediciones internas de U Mobile, los volúmenes mensuales de tickets de incidencia disminuyeron en tres categorías principales entre enero y septiembre de 2026:
- Los tickets de aprovisionamiento y red cayeron 84.5 por ciento.
- Las consultas generales disminuyeron 81.6 por ciento.
- La facturación y cobro se redujo en 48.7 por ciento.
Cómo construyó el equipo: desarrollo basado en especificaciones con Kiro
U Mobile aceleró el desarrollo de AiDaH usando Kiro, el IDE agéntico de AWS construido en torno al desarrollo basado en especificaciones. En Kiro, una nueva capacidad comienza como una especificación en lugar de un prompt: los requisitos, el diseño y el desglose de tareas se escriben y revisan primero, y la generación de código trabaja sobre ese artefacto acordado. Para AiDaH, esto fue más importante en el límite entre agentes y herramientas. Cada nuevo dominio operativo significa una nueva pasarela, un conjunto de definiciones de herramientas MCP y las entradas de control de acceso basado en roles que deciden quién puede llamarlas. Escribirlas primero convirtió cada nuevo dominio en una unidad de trabajo repetible en lugar de un ejercicio de diseño nuevo.
La cadena de herramientas de soporte es convencional. El equipo usó Kiro IDE para el desarrollo local, con agent hooks e integraciones MCP, junto con Kiro CLI para la automatización de pipelines. El control de código fuente corre en GitLab, con AWS CodePipeline y AWS CodeBuild impulsando la integración continua, imágenes de contenedor publicadas en Amazon Elastic Container Registry (Amazon ECR), y SonarQube proporcionando escaneo continuo de calidad de código. Las especificaciones impulsaron la generación de código. La disciplina permitió que un equipo pequeño creciera de una prueba de concepto con dos casos de uso a más de 150 casos de uso documentados en una cadencia de sprint de 12 semanas.
Decisiones arquitectónicas clave
Varias decisiones moldearon cómo AiDaH escaló de prueba de concepto a plataforma de producción. Cuatro destacan, cada una reduciendo el costo de añadir el siguiente dominio operativo o de mantener la plataforma gobernable a medida que crecía.
AgentCore como infraestructura administrada – En lugar de construir un marco de agentes personalizado, el equipo usó las capacidades integradas de escalado, identidad, memoria y observabilidad de Amazon Bedrock AgentCore. AWS gestiona el aprovisionamiento, escalado y parcheo subyacentes, lo que eliminó toda una capa de ingeniería de infraestructura.
MCP para conectividad universal de herramientas – Estandarizar en el Model Context Protocol significa que AiDaH puede incorporar nuevos sistemas backend sin reconstruir la lógica de los agentes. Cada nuevo dominio operativo necesita una nueva pasarela, no una nueva arquitectura de integración.
A2A para colaboración de especialistas – El protocolo Agent2Agent permite a los especialistas de dominio delegarse subtareas entre sí. Una consulta que abarca registros de clientes, registros de interfaz y datos de facturación se enruta de forma natural entre los agentes relevantes.
Primero una base segura – Ejecutar la Well-Architected Security Review en la Landing Zone antes de escalar a producción significa que los controles de seguridad son heredados por cada nuevo agente y pasarela, en lugar de añadirse a posteriori.
¿Qué viene después?
La hoja de ruta de U Mobile se centra en expandir tanto la amplitud como la profundidad: incorporar dominios operativos adicionales e integraciones backend, mientras se evoluionan las capacidades de la plataforma desde consultas de un solo sistema hacia el diagnóstico correlacionado multisistema. El objetivo a más largo plazo, el Nivel 8 en el modelo de competencias, es pasar de informar a los agentes de soporte a resolver problemas de forma autónoma.
La gobernanza de seguridad madura en paralelo. El equipo está alineando sus prácticas con NIST SP 800-53, el OWASP Top 10 para LLM Applications, el CSA AI Trust Framework y MITRE ATLAS. El cumplimiento de la Ley de Protección de Datos Personales de Malasia y de las regulaciones de la Comisión de Comunicaciones y Multimedia de Malasia continúa en paralelo.
Conclusión
AiDaH muestra qué cambia cuando la IA deja de asistir y empieza a actuar. En menos de un año, U Mobile pasó de una prueba de concepto con dos agentes a ocho agentes especializados que atienden más de 150 escenarios operativos documentados. Según las mediciones internas de U Mobile, los tickets de incidencia cayeron hasta 84.5 por ciento en categorías clave, y U Mobile ahora ha incorporado la plataforma a sus procedimientos formales de soporte L2.
Recorrimos las seis capas, seguimos una solicitud desde Teams hasta un sistema local y de vuelta, y describimos la Well-Architected Security Review que precedió al escalado a producción. La base técnica importó, pero también el trabajo menos glamoroso. Eso significó validar la Landing Zone antes de escalar, escribir prompts estructurados para que el personal supiera cómo empezar, y tratar la adopción como un problema de cambio de comportamiento en lugar de un hito de despliegue. Los equipos que enfrentan una fragmentación de sistemas similar podrían encontrar útil el mismo patrón. Comenzar con un entorno de ejecución de agentes administrado, añadir un protocolo de herramientas estándar en el límite de integración, y ejecutar una revisión de seguridad antes del escalado en lugar de después.
La dirección sigue siendo clara: expandir de forma segura, automatizar con responsabilidad y avanzar constantemente hacia operaciones autónomas y autorreparables, un paso deliberado y gobernado a la vez.
Para saber más, visite Amazon Bedrock AgentCore y la Amazon Bedrock AgentCore Developer Guide. Para explorar el desarrollo basado en especificaciones, consulte Kiro.