AWS está realizando un cambio de compatibilidad que es importante para los equipos que crean infraestructura de agentes sobre Amazon Bedrock AgentCore. Según la documentación de AWS, AWS Agent Registry se encuentra actualmente en versión preliminar pública en el espacio de nombres bedrock-agentcore, pero a partir del 6 de agosto de 2026, el servicio se traslada al espacio de nombres agent-registry.
Este no es el lanzamiento de un nuevo modelo básico ni un anuncio de precios. Es un cambio de fontanería. Pero para los desarrolladores que operan agentes, catálogos de herramientas, integraciones de estilo Model Context Protocol o registros internos, los cambios de plomería suelen ser los que primero rompen los scripts de producción.
AWS dice que los usuarios deben actualizar los puntos finales, las políticas de IAM, los clientes SDK, los scripts CLI y los datos de registro como parte del movimiento. Eso hace que este sea un evento de migración real en lugar de un cambio de nombre cosmético. Cualquier sistema que llame directamente al antiguo espacio de nombres, le otorgue permisos o automatice las operaciones de registro a través de la línea de comandos o flujos de trabajo del SDK puede necesitar cambios antes de poder funcionar limpiamente con la nueva identidad del servicio.
Qué cambió en el Registro de agentes de AWS
AWS Agent Registry está documentado como un servicio de vista previa pública asociado con Amazon Bedrock AgentCore. El registro está destinado a ayudar a los equipos a administrar y descubrir agentes, incluidas tarjetas de agentes y metadatos relacionados utilizados en ecosistemas de agentes. Hasta ahora, la vista previa se encontraba bajo el espacio de nombres bedrock-agentcore.
El cambio del 6 de agosto separa el registro en el espacio de nombres agent-registry. En términos prácticos, eso significa que las integraciones deberían dejar de asumir que el registro es solo una subparte del espacio de nombres más amplio de Bedrock AgentCore. La documentación de AWS señala varias áreas que requieren atención: puntos finales de servicio, políticas de administración de acceso e identidad, clientes SDK, scripts CLI y datos de registro.
Esas categorías cubren la mayoría de los lugares donde la infraestructura de los agentes se vuelve complicada. Los puntos finales pueden estar integrados en la configuración del servicio. Los permisos de IAM pueden ser administrados por equipos de seguridad en lugar de desarrolladores de aplicaciones. Los clientes del SDK pueden estar anclados en bibliotecas internas. Es posible que los scripts de CLI se estén ejecutando en canalizaciones de CI o en runbooks de operaciones. Es posible que sea necesario migrar o volver a registrar los datos de registro dependiendo de cómo un equipo utilice el servicio de vista previa.
Por qué esto es importante para las herramientas de agentes y MCP
El momento es notable porque la infraestructura de los agentes se está volviendo más formal. Los cambios recientes en el mercado han alejado a los desarrolladores de las demostraciones únicas y se han acercado a sistemas gobernados: registros, servidores de herramientas, informes de uso, controles de acceso y pistas de auditoría. En ese contexto, un cambio en el espacio de nombres del registro es una señal de que AWS está tratando el descubrimiento y la administración de agentes como una superficie de infraestructura distinta.
Para los equipos que experimentan con agentes, esta puede ser una pequeña tarea de mantenimiento. Para las empresas que crean plataformas internas en torno a catálogos de agentes, el trabajo es más amplio. Las llamadas de registro pueden estar detrás de portales de desarrolladores, sistemas de revisión de seguridad, capas de orquestación, flujos de trabajo de aprobación o implementaciones automatizadas. Si esos sistemas se crearon durante el período de versión preliminar, es posible que contengan suposiciones que ahora deben revisarse.
El cambio también es relevante para las implementaciones del protocolo de contexto modelo y otros patrones de interoperabilidad de agentes. Los registros de agentes pueden convertirse en el lugar donde las plataformas descubren qué es un agente, qué herramientas puede utilizar, qué puntos finales expone y qué límites de confianza se aplican. Si una puerta de enlace, un orquestador o una plataforma de socios exponen agentes respaldados por AWS a los clientes, necesita saber si está analizando el espacio de nombres antiguo, el nuevo o ambos durante un período de transición.
Quién se ve afectado
Los usuarios más directamente afectados son los desarrolladores y los equipos de plataformas que ya utilizan AWS Agent Registry durante la versión preliminar pública. Deben auditar cualquier código o infraestructura que haga referencia a bedrock-agentcore para las operaciones de registro. Esto incluye código de aplicación, plantillas de infraestructura como código, políticas de IAM, trabajos de CI, scripts CLI, contenedores de SDK, herramientas de desarrollo local y documentación utilizada por los equipos de soporte.
Los equipos de seguridad y gobierno de la nube también se ven afectados. Los cambios de IAM pueden tardar más que los parches de aplicaciones porque a menudo requieren revisión, comprobaciones de privilegios mínimos y flujos de trabajo de aprobación. Un movimiento de espacio de nombres puede requerir nuevos permisos, referencias de servicios actualizadas y plantillas de políticas actualizadas. Si las organizaciones tienen controles internos que bloquean espacios de nombres de servicios desconocidos de forma predeterminada, es posible que sea necesario agregar el nuevo espacio de nombres agent-registry antes de que los desarrolladores puedan continuar.
Los proveedores de automatización y puertas de enlace API tienen un problema diferente: la confusión del cliente. Recientemente, AWS también trasladó a Bedrock Agents a una ruta "clásica" para la disponibilidad de nuevos clientes, dirigiendo el nuevo trabajo hacia AgentCore. La migración del espacio de nombres del Registro de agentes es independiente del corte anterior de Bedrock Agents Classic, pero ambos eventos afectan la misma categoría amplia de infraestructura de agentes. La documentación, los flujos de incorporación y las respuestas de soporte deberían dejar clara esa distinción.
Pasos prácticos de migración
Los equipos deben comenzar con un inventario. Busque repositorios, manifiestos de implementación, archivos de políticas y scripts de CI para llamadas relacionadas con el registro en el antiguo espacio de nombres Bedrock AgentCore. Luego identifique qué referencias son críticas para el tiempo de ejecución y cuáles son solo documentación o ejemplos.
A continuación, actualice las políticas de IAM y pruébelas en una cuenta que no sea de producción. Los cambios en el espacio de nombres a menudo revelan permisos demasiado amplios o dependencias ocultas. Una prueba controlada puede mostrar si las nuevas referencias de servicios son suficientes antes de que los agentes de producción o los registros dependan de ellas.
El uso de SDK y CLI debe comprobarse por separado. Algunos equipos llaman a los servicios en la nube a través de clientes SDK oficiales; otros desembolsan comandos CLI dentro de las canalizaciones de compilación. Ambos caminos pueden fallar de manera diferente. Los clientes del SDK pueden necesitar actualizaciones de versión o nuevos constructores de servicios. Los scripts CLI pueden necesitar nuevos nombres de comandos, indicadores de puntos finales o suposiciones de autenticación.
Los datos del registro merecen su propio plan de migración. La documentación de AWS dice que los datos de registro deben actualizarse, pero el impacto operativo dependerá de cómo cada equipo haya modelado agentes, identificadores y metadatos. Los equipos deben verificar si los registros de agente, las tarjetas de agente, las versiones o las referencias permanecen estables después de la migración y si los sistemas posteriores almacenan en caché esos identificadores.
Para las empresas que utilizan una API multimodelo o una puerta de enlace API AI, la lección más importante es que la infraestructura de agentes ahora necesita la misma disciplina de gestión de cambios que el enrutamiento de modelos. Es posible que una puerta de enlace como Model Gate no esté directamente involucrada en la migración de AWS Agent Registry, pero el patrón operativo es familiar: las superficies de API del lado del proveedor cambian y los equipos necesitan configuración centralizada, visibilidad de uso, controles clave y propiedad clara para evitar roturas dispersas.
Lo que sigue siendo incierto
La información disponible proviene de la documentación de AWS en lugar de un blog de lanzamiento separado o un anuncio más amplio. Eso no hace que el cambio sea menos procesable, pero sí limita el contexto público en torno a la hoja de ruta de AWS para el registro. La documentación confirma la migración del espacio de nombres y las categorías de actualizaciones requeridas; En el material recuperado, no proporciona una explicación detallada del posicionamiento en el mercado ni una confirmación independiente de otra fuente de AWS.
Dado que AWS Agent Registry está en versión preliminar pública, los equipos también deben asumir que es posible realizar más cambios en la interfaz. Los servicios de vista previa son útiles para una adopción temprana, pero requieren límites de abstracción más estrictos que las API maduras. Si las operaciones de registro están dispersas en muchas aplicaciones, este es un buen momento para consolidarlas detrás de bibliotecas internas o servicios de plataforma para que el próximo cambio sea más fácil de absorber.