Los mejores casos de uso de agentes pueden ser sus playbooks de siempre. AWS lo demuestra con la migración

Cuando se pregunta por dónde empezar con agentes, muchos equipos buscan problemas abiertos que parecen exigir inteligencia. La mejor respuesta suele ser la contraria: trabajo largo, con muchas herramientas, que las personas ya ejecutan siguiendo un playbook, con pasos, comprobaciones y responsables conocidos. La migración a la nube es un caso de manual, y AWS publicó una arquitectura para ella el 1 de octubre.

Qué describe AWS

El artículo, firmado por Nikhil Jha, Kaushal Agrawal, Tarun Tarun y Vyasamaharshi Garigipati, presenta cuatro agentes sobre Amazon Bedrock AgentCore, construidos con el SDK Strands Agents:

• Agente de entrada. Lee la información de partida de la migración en documentos mediante herramientas MCP y propone una arquitectura de destino.
• Agente de infraestructura como código. Genera el código de infraestructura combinando módulos internos aprobados, en lugar de escribir la infraestructura desde cero.
• Agente de inteligencia y gobernanza de la migración. Elabora informes de la cartera, evaluaciones y vistas de gobernanza sobre las aplicaciones.
• Agente de SRE. Vigila las cargas tras el cambio y aplica remediaciones automatizadas.

La base es AgentCore: Runtime, Gateway, Memory para el estado de sesión y el contexto compartido entre agentes, Identity para la autenticación, Policy aplicando reglas Cedar y Observability. Amazon Bedrock Guardrails bloquea las salidas no conformes. Las bases de datos y los servidores se trasladan con AWS DMS y AWS Transform. Los autores indican que las acciones automatizadas requieren aprobación humana explícita antes de ejecutarse.

El artículo afirma que el desarrollo del código de infraestructura pasó de tres o cuatro semanas por aplicación a minutos, en una cartera de más de 300 aplicaciones, según el seguimiento interno del proyecto. Es una cifra comunicada por los propios autores, no un benchmark independiente.

Por qué la migración encaja con los agentes

1. Entrada: leer información, proponer destino
2. El arquitecto aprueba el destino
3. IaC a partir de módulos aprobados
4. Comprobaciones del pipeline y aprobación
5. Cambio con plan de rollback
6. El agente de SRE vigila y propone arreglos

• Planificar: Entrada: leer información, proponer destino · El arquitecto aprueba el destino
• Construir: IaC a partir de módulos aprobados · Comprobaciones del pipeline y aprobación
• Operar: Cambio con plan de rollback · El agente de SRE vigila y propone arreglos

Trabajo del agentePuerta de aprobación humana

La descomposición ya existe. Descubrimiento, diseño, construcción, cambio y operación son fases conocidas. Cada agente recibe una fase, lo que mantiene acotados sus herramientas y permisos. Es la primera prueba de nuestro marco para encontrar dónde encaja un agente: un proceso que ya existe, con pasos claros.

La salida se puede comprobar. El código de infraestructura pasa por el mismo pipeline, las mismas comprobaciones de políticas y las mismas revisiones que el código escrito por personas. Combinar módulos aprobados es una buena decisión de diseño: el agente ensambla piezas en las que el equipo de plataforma ya confía, y la revisión se centra en las decisiones, no en cada línea.

El estado dura mucho. Las migraciones duran semanas. La memoria compartida entre agentes es lo que permite al agente de gobernanza hablar de toda la cartera. También significa que esa memoria guarda detalles de arquitectura e inventarios, que merecen el mismo control de acceso que la CMDB.

La política está fuera de los agentes. Las reglas Cedar de AgentCore Policy las evalúa la plataforma, no el modelo. Es el lugar adecuado para “este agente no toca la red de producción”, como defendimos en nuestro análisis sobre la contención de agentes.

Qué falta y qué debe añadir usted

Rollback. El artículo no trata el rollback de forma explícita. En una migración, es el control que más importa el día del cambio. Escríbalo en el playbook antes de que un agente toque los pasos del cambio: qué lo activa, quién decide y cuánto tarda.

Resiliencia y salida. Para una entidad financiera española, DORA exige gestionar el riesgo de los proveedores TIC, con planes de continuidad y estrategias de salida para los servicios críticos. Un agente que acelera la migración a un proveedor de nube no reduce esas obligaciones: hace que el plan de salida tenga que estar escrito antes. El código de infraestructura generado por agentes y las remediaciones que propongan necesitan las mismas solicitudes de cambio, aprobaciones y evidencias que los cambios hechos por personas.

Dónde se ejecuta. Compruebe qué componentes de AgentCore están disponibles en las regiones europeas que usa (y, en Latinoamérica, cuáles se ejecutarían fuera del país). La memoria compartida guarda el inventario de su entorno; su ubicación es una decisión de custodia.

La autoridad del agente de SRE. La remediación automatizada tras el cambio es donde la autonomía exige más cuidado. Vale la misma escalera de permisos que en el DevOps Agent de la propia AWS: leer libremente, proponer con generosidad, actuar solo con una concesión explícita.

Qué hacer ahora

1. Elija un playbook que sus equipos ya ejecuten (migración, alta de usuarios, parches, revisiones de accesos), no un problema abierto.
2. Asigne a cada agente una fase, con sus propias herramientas y permisos.
3. Limite la generación a piezas aprobadas siempre que pueda: módulos, plantillas, runbooks.
4. Ponga aprobación humana en las fronteras entre fases y regístrela como evidencia.
5. Escriba el rollback y las condiciones de parada antes de automatizar cualquier paso que cambie producción.
6. Mida por fase: tiempo ahorrado, retrabajo y defectos detectados en cada puerta.

En resumen

El diseño de AWS funciona por un motivo que tiene poco que ver con la IA: la migración ya era una secuencia disciplinada y comprobable. Los agentes aceleran cada paso sin cambiar quién decide entre pasos. Busque esa forma en su propia operación antes de buscar problemas que solo parecen requerir inteligencia.