AWS congela Bedrock Agents Classic: qué revisar antes de migrar tus agentes a AgentCore
AWS puso Amazon Bedrock Agents en modo mantenimiento y dejará de aceptar cuentas nuevas el 30 de julio de 2026. La migración a AgentCore cambia el runtime, la identidad y el contrato de herramientas.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
AWS cambió el nombre y el futuro de Amazon Bedrock Agents. Desde el anuncio del 30 de junio de 2026, el servicio se llama Amazon Bedrock Agents Classic, entra en modo mantenimiento y dejará de aceptar clientes nuevos el 30 de julio de 2026. Las cuentas que ya lo usan pueden continuar, pero AWS no añadirá capacidades nuevas al orquestador.
La distinción importa: no se está apagando Bedrock completo. Los modelos, Knowledge Bases y Guardrails de Amazon Bedrock siguen soportados. El componente que pierde el camino de crecimiento es la capa de agentes clásica. Para equipos que todavía están evaluando arquitectura, la decisión práctica es no iniciar un proyecto nuevo sobre una superficie que ya tiene fecha de congelamiento.
Qué cambia para una cuenta existente
AWS dice que las cargas existentes no necesitan una migración inmediata. Sin embargo, el catálogo de modelos disponible para Bedrock Agents Classic queda congelado a partir del 30 de julio. Las plantillas de infraestructura que ya crean o administran agentes continuarán funcionando para cuentas permitidas, pero una cuenta nueva no tendrá una excepción manual para comenzar con el servicio clásico.
Eso crea dos riesgos distintos. El primero es de provisionamiento: una cuenta o entorno nuevo puede fallar porque ya no está en la lista permitida. El segundo es de evolución: una aplicación puede seguir estable hoy, pero no recibirá modelos ni capacidades posteriores a la fecha de mantenimiento. Migrar no es solo cambiar un nombre en Terraform; es decidir qué parte del loop seguirá siendo declarativa y cuál necesita código propio.
AgentCore ofrece dos caminos
La recomendación oficial es Amazon Bedrock AgentCore. Su harness administrado conserva una idea cercana al servicio clásico: declaras el modelo, el prompt y las herramientas, y el runtime gestiona la orquestación, la ejecución de tools, la memoria y la respuesta. Cada sesión puede correr aislada y el sistema añade identidad, sandbox, observabilidad y conectividad con MCP.
El segundo camino es un agente definido por código sobre AgentCore Runtime. AWS lo orienta a casos con colaboración multiagente, supervisores, lógica de orquestación propia o un framework existente. La documentación menciona compatibilidad con Strands, LangChain, OpenAI Agents SDK, Claude Agent SDK y otros enfoques personalizados.
La elección se puede resumir así:
- Harness: útil cuando quieres declarar modelo, instrucciones y tools con poca infraestructura adicional.
- Código: útil cuando necesitas controlar handoffs, retries, supervisors, sesiones o reglas que no caben en la configuración.
- Ambos: se benefician de identidad, aislamiento y trazas del runtime, pero no eliminan la responsabilidad de diseñar herramientas idempotentes.
AWS también indica que el AgentCore CLI puede importar una configuración clásica como punto de partida. No conviene tratar esa importación como una migración automática: el propio documento señala que el skill específico para guiar el paso al harness todavía está en desarrollo.
Checklist de migración sin sorpresa
Antes de tocar producción, haría un inventario del agente actual:
- Orquestación: identifica prompts, action groups, sesiones, reintentos y handoffs que dependan de la implementación clásica.
- Herramientas: mapea cada API, Lambda o Knowledge Base a una tool con esquema, timeout, permisos mínimos y manejo de errores.
- Identidad: separa credenciales de usuario y del agente; define qué puede leer, preparar y escribir.
- Evidencia: conserva trazas, resultados de tools y métricas de calidad para comparar el comportamiento antes y después.
- Despliegue: prueba la cuenta nueva, el modelo elegido y la región objetivo antes de retirar el camino anterior.
El error más caro sería migrar el runtime y mantener el mismo contrato abierto de herramientas. AgentCore agrega controles, pero un agente que puede llamar demasiadas APIs seguirá siendo difícil de auditar. También conviene medir latencia, costo por sesión, memoria y tasa de intervención humana; una migración compatible no necesariamente es una migración equivalente.
La intención de búsqueda es concreta: Bedrock Agents Classic, migrar Bedrock Agents a AgentCore, Amazon Bedrock AgentCore harness y AWS agentes mantenimiento. No hay volumen SEO conectado; la demanda se infiere de la fecha límite oficial, la documentación de migración y el problema de mantener agentes en cuentas nuevas.
Si estás diseñando tu primer flujo de tools y permisos, el curso gratis ayuda a ordenar la base antes de elegir runtime. La lectura corta: Bedrock no desaparece, pero su orquestador clásico dejó de ser una apuesta de futuro.