Amazon Web Services ha puesto su servicio de agente administrado original para Amazon Bedrock en modo de mantenimiento para una nueva adopción. El servicio anteriormente conocido como Amazon Bedrock Agents ahora está documentado como Amazon Bedrock Agents Classic y AWS dice que ya no estará abierto a nuevos clientes a partir del 30 de julio de 2026.
Eso no significa que las implementaciones existentes dejen de funcionar. AWS dice que los clientes actuales pueden continuar usando Bedrock Agents Classic y afirma por separado que los modelos, bases de conocimiento y Guardrails de Amazon Bedrock no se ven afectados por el cambio. Pero la dirección para las cargas de trabajo de nuevos agentes es clara: AWS recomienda Amazon Bedrock AgentCore como la ruta comparable para aplicaciones de agentes nuevas o migradas.
Para los equipos que se basan en Bedrock, esto es más que un cambio de nombre de servicio. Cambia la arquitectura predeterminada para los agentes alojados en AWS de la interfaz anterior de Bedrock Agents a un tiempo de ejecución y una pila de herramientas más nuevos centrados en AgentCore. Para las plataformas que proporcionan una puerta de enlace API de IA, una capa de enrutamiento LLM o una infraestructura de agente empresarial, el límite crea una pregunta de compatibilidad y migración que se suma a la selección de modelo ordinaria.
Lo que cambió el 30 de julio
La documentación de AWS ahora identifica a Amazon Bedrock Agents como Amazon Bedrock Agents Classic. La misma guía sobre el modo de mantenimiento dice que Bedrock Agents Classic está cerrado para nuevos clientes a partir del 30 de julio de 2026, mientras que los clientes existentes pueden seguir usándolo.
El significado práctico depende de la cuenta de AWS del cliente y del uso actual. Los sistemas de producción existentes construidos en Classic no deberían suponer un cierre inmediato basándose únicamente en el aviso de mantenimiento público. Sin embargo, los nuevos equipos, las nuevas cuentas y las organizaciones que estandaricen la futura infraestructura de agentes deberían tratar a Classic como una ruta heredada en lugar del servicio de agente predeterminado de Bedrock.
AWS dirige a los clientes nuevos y migratorios a Bedrock AgentCore. La compañía describe AgentCore como soporte de orquestación administrada y un conjunto más amplio de capacidades de agentes de producción, incluida la exposición de herramientas a través del Protocolo de contexto modelo, memoria, identidad, observabilidad y seguimiento. Esas características sugieren que AWS está pasando de un creador de agentes administrados más limitado a un tiempo de ejecución de agentes más general para aplicaciones de larga duración que utilizan herramientas.
Un límite también es importante: el cambio tiene que ver con la capa de orquestación de agentes administrados de Bedrock, no con toda la plataforma Bedrock. AWS dice que los modelos Bedrock, las bases de conocimiento y los Guardrails no se ven afectados. Un equipo aún puede usar la inferencia del modelo Bedrock o los componentes de seguridad y recuperación incluso si necesita revisar el servicio de orquestación de agentes que los rodea.
Por qué esto es importante para los creadores de agentes
La infraestructura del agente se ha vuelto más difícil de tratar como una envoltura delgada alrededor de una llamada de modelo. Un agente de producción a menudo necesita permisos de herramientas, reglas de memoria, mapeo de identidad, registro, evaluación y atribución de costos. Cuando cambia la capa de orquestación administrada, es posible que los desarrolladores necesiten revisar cómo se conectan entre sí las indicaciones, los esquemas de herramientas, la recuperación, las barreras de seguridad y el monitoreo.
Esto es especialmente cierto para las empresas que adoptaron Bedrock Agents Classic como una alternativa administrada para crear su propia orquestación. Si esas empresas ahora crean entornos adicionales, incorporan nuevas unidades de negocios o reconstruyen en nuevas cuentas de AWS, pueden encontrar una disponibilidad y una arquitectura recomendada diferentes a las utilizadas por sus implementaciones existentes.
El límite también afecta a los proveedores y equipos de plataformas internas que abstraen Bedrock detrás de una interfaz unificada. Una plataforma multinube o multimodelo no puede tratar esto simplemente como una "ruta hacia un modelo de AWS". Es posible que necesite saber si un cliente está invocando una inferencia de modelo simple, un flujo de trabajo de la base de conocimientos, una política de Guardrails, un agente clásico o una carga de trabajo alojada en AgentCore. Se trata de superficies operativas diferentes con diferentes riesgos de migración.
Para los usuarios de Model Gate y clientes de gateways similares, la lección es que el enrutamiento API LLM ya no se trata solo de precio, latencia y calidad del modelo. La ubicación del agente también es importante. Una puerta de enlace puede ayudar a centralizar la administración de claves API, análisis de uso, controles de equipo y visibilidad de gastos, pero aún así debe respetar las capacidades y el estado del ciclo de vida de los servicios del proveedor subyacente.
Quién se ve afectado
El grupo más directamente afectado son los clientes de AWS que planean nuevas compilaciones de agentes administrados en Bedrock. Si no han utilizado Bedrock Agents Classic anteriormente, deben esperar que AgentCore sea la ruta recomendada. Los equipos que ya ejecutan agentes clásicos pueden seguir usándolos, según AWS, pero deben planificar la postura de mantenimiento del servicio al tomar decisiones sobre la hoja de ruta a largo plazo.
Los arquitectos de la nube se ven afectados porque las arquitecturas de referencia pueden necesitar actualización.La documentación, los módulos de Terraform, las rutas doradas internas y las revisiones de seguridad que asumieron Bedrock Agents Classic como la capa de agente administrada estándar deben compararse con las API, el modelo de identidad, las características de observabilidad y los requisitos operativos de AgentCore.
Los equipos de seguridad y gobernanza también están dentro del alcance. El énfasis de AgentCore en la identidad, la exposición de herramientas, la observabilidad y el rastreo refleja los problemas que las empresas ahora están tratando de resolver: qué usuario o servicio está actuando, a qué herramientas puede llamar un agente, qué datos puede recuperar, cómo se puede auditar una decisión y cómo se detectan bucles de herramientas fuera de control o costosas llamadas de modelos.
Los proveedores de software que construyen sobre Bedrock pueden necesitar un período de soporte dual. Es posible que los clientes existentes todavía estén en Classic, mientras que los nuevos clientes pueden necesitar AgentCore. Eso puede significar pruebas adicionales, indicadores de funciones, lógica de implementación específica del cliente y documentación más clara sobre qué ruta del agente Bedrock es compatible.
Consecuencias prácticas y preguntas abiertas
El primer paso práctico es el inventario. Los equipos deben identificar si utilizan Bedrock Agents Classic, API de modelo simple de Bedrock, bases de conocimientos, barreras de seguridad u orquestación personalizada fuera de Bedrock. El aviso del modo de mantenimiento afecta a esas categorías de manera diferente.
El segundo paso es mapear las dependencias de migración en lugar de asumir un levantamiento y cambio directo. Las cargas de trabajo de los agentes pueden depender de las definiciones de herramientas, la configuración de recuperación, las plantillas de mensajes, los permisos de IAM, los registros de auditoría y el manejo de errores específicos de la aplicación. Pasar a AgentCore puede ser una oportunidad para mejorar la observabilidad y los controles de identidad, pero aún puede requerir trabajo de integración.
El tercer paso es la revisión de costos y gobernanza. Los nuevos tiempos de ejecución de agentes a menudo facilitan la conexión de más herramientas y la ejecución de flujos de trabajo más autónomos. Eso aumenta el valor del análisis de uso, la atribución a nivel de solicitud y los controles presupuestarios. En un entorno de puerta de enlace, los equipos deben decidir qué llamadas fluyen a través de una capa de política central y cuáles permanecen dentro de la orquestación administrada por AWS.
Algunos detalles siguen siendo específicos de la cuenta. Comentarios independientes han sugerido que la elegibilidad puede depender del uso anterior de la cuenta y que algunos modelos posteriores al corte recientemente lanzados pueden no estar disponibles a través de Classic. Esos puntos deben verificarse con la cuenta de AWS del cliente y la documentación actual del modo de mantenimiento de AWS antes de ser tratados como política.
La señal más amplia es bastante clara: AWS no está saliendo de los agentes de Bedrock, pero está alejando el trabajo de los nuevos agentes de la interfaz original de Bedrock Agents. Para los desarrolladores y equipos de plataforma, la suposición segura es que la inversión futura en agentes de AWS se concentrará en AgentCore, mientras que Bedrock Agents Classic se convierte en una preocupación de compatibilidad para las implementaciones existentes.