El descubrimiento en tiempo de ejecución de AWS Agent Registry saca la conexión de herramientas de las compilaciones
AWS detalló el descubrimiento en tiempo de ejecución de AWS Agent Registry el 20 de octubre, mostrando una alternativa a codificar de forma rígida cada capacidad en un agente. El enfoque traslada la selección de herramientas a la aplicación en ejecución, donde un orquestador, el agente que coordina una solicitud, busca en un catálogo antes de elegir conexiones. Este cambio cuestiona una arquitectura que muchos equipos pueden mantener cómodamente hasta que su catálogo de herramientas empieza a expandirse entre departamentos.
La disputa central es entre la conexión durante la compilación y la selección en tiempo de ejecución. La conexión durante la compilación ofrece a los desarrolladores un inventario explícito de las capacidades disponibles. La selección en tiempo de ejecución permite que ese inventario cambie de forma independiente, pero convierte los resultados de búsqueda en parte del comportamiento de la aplicación. La cuestión pasa a ser si los equipos pueden preservar una ejecución predecible mientras permiten que las capacidades evolucionen fuera del ciclo de lanzamiento del orquestador.
Anthropic también ha promovido la carga de herramientas bajo demanda, lo que proporciona a este ejemplo de AWS una referencia reconocible en la industria. AWS lleva el debate a la gestión de catálogos empresariales, donde la aprobación, la propiedad, los detalles de conexión y las reglas de acceso importan junto con el contexto del modelo. Para los desarrolladores y compradores empresariales, el cambio relevante es organizativo: la disponibilidad de una herramienta puede depender de la gobernanza del catálogo en lugar de otro despliegue de la aplicación.
El descubrimiento en tiempo de ejecución de AWS Agent Registry cambia cuándo se eligen las conexiones
El recorrido del descubrimiento en tiempo de ejecución presenta un ciclo de Descubrir, Instanciar y Ejecutar. Su ejemplo conecta un servidor de gestión de pedidos con agentes de precios y atención al cliente. Se trata de escenarios de demostración, no de evidencia procedente de un despliegue empresarial evaluado de forma independiente.
El ejemplo usa MCP, el Model Context Protocol que estandariza cómo las aplicaciones exponen herramientas y contexto a los sistemas de IA. También utiliza A2A, un protocolo de agente a agente para la comunicación entre agentes. Reunir ambos en el mismo ciclo de descubrimiento hace que el ejemplo sea relevante más allá de un catálogo de funciones individuales.
El cambio arquitectónico consiste en que el orquestador selecciona las conexiones después de recibir una solicitud, en lugar de incorporar cada conexión durante su compilación.
Esa distinción merece más atención de la que sugiere por sí sola la palabra «descubrimiento». Un catálogo consultado por desarrolladores ayuda a las personas a elegir integraciones durante la implementación. Un catálogo consultado durante la ejecución ayuda a determinar qué integraciones puede utilizar la aplicación para una solicitud concreta.
Esto cambia el significado de añadir una capacidad. Con la conexión explícita, los desarrolladores suelen decidir dónde corresponde la integración antes de lanzar el orquestador. Con la selección en tiempo de ejecución, una capacidad compatible puede pasar a ser considerada a través del catálogo. La aplicación sigue necesitando reglas para interpretar y utilizar aquello que descubre.
La distinción también cambia lo que los revisores deberían examinar. Revisar el código fuente de un orquestador ya no revela necesariamente su conjunto completo de capacidades futuras. Una revisión útil también debe considerar el catálogo, los permisos de publicación, las prácticas de aprobación y las expectativas de compatibilidad.
Pensemos en un asistente empresarial hipotético que ya gestiona consultas sobre pedidos. Un equipo de soporte incorpora un especialista en reclamaciones de garantía. El beneficio arquitectónico sería permitir que ese especialista pudiera descubrirse sin añadir otra integración nombrada a la aplicación coordinadora.
Ese beneficio depende de la compatibilidad. Un servicio recién publicado con un método de conexión desconocido sigue generando trabajo de integración. El descubrimiento en tiempo de ejecución desplaza algunas decisiones a una etapa posterior; no hace que todos los servicios posibles sean utilizables de inmediato.
Por tanto, el límite importante es el contrato de conexión admitido por la aplicación. Los desarrolladores pueden permitir nuevas capacidades dentro de ese contrato y, al mismo tiempo, conservar el control sobre los protocolos, los métodos de acceso y la política de ejecución. Es una promesa más acotada y útil que la integración universal plug-and-play.
Para quienes evalúan el descubrimiento en tiempo de ejecución de AWS Agent Registry, la primera pregunta debería referirse a qué cambios desacopla realmente la arquitectura. Añadir una capacidad compatible es distinto de cambiar las reglas bajo las cuales se ejecutan las capacidades.
Los equipos de plataforma heredan un problema de publicación de catálogos
AWS describe su catálogo de capacidades gobernado como un servicio de descubrimiento gestionado con flujos de trabajo de publicación y aprobación. Su documentación separa a publicadores, curadores y consumidores. Estos roles hacen visible una consecuencia organizativa importante: el descubrimiento de capacidades exige una propiedad continua.
La selección en tiempo de ejecución traslada el trabajo de coordinación de los lanzamientos individuales de integraciones a la publicación, revisión y mantenimiento del catálogo.
Los ingenieros de plataforma afrontan la presión más directa. Con la conexión durante la compilación, el repositorio de la aplicación proporciona un punto de coordinación evidente. Con un catálogo cambiante, necesitan otra forma de definir qué capacidades pertenecen juntas y qué cambios requieren una revisión más amplia.
Los propietarios de capacidades afrontan una obligación diferente. Un endpoint funcional es insuficiente si los consumidores no pueden entender cuándo seleccionarlo. El propietario debería describir con suficiente claridad la tarea prevista, las exclusiones importantes, las entradas esperadas y las limitaciones operativas para que otro equipo pueda evaluar la conexión.
Esto se parece al mantenimiento de una interfaz compartida entre equipos. La descripción transmite significado, mientras que el contrato de conexión determina lo que el software puede hacer realmente. Una debilidad en cualquiera de los dos puede generar confusión que el agente coordinador no pueda resolver de forma fiable.
La aprobación también necesita un propósito concreto. Una organización podría revisar la postura de seguridad, la propiedad, los compromisos de soporte o la compatibilidad antes de admitir una capacidad. Estas comprobaciones responden a preguntas distintas, por lo que una etiqueta de aprobación no debería convertirse en una abreviatura de toda garantía posible.
Un servicio aprobado podría seguir siendo inadecuado para una solicitud de usuario concreta. Una herramienta de informes de producción podría ser relevante para el tema, pero no estar disponible para el empleado que realiza la solicitud. Una capacidad de soporte podría explicar una política sin tener permiso para modificar un pedido.
Para los compradores empresariales, esto sugiere una conversación de adquisición más específica. Conviene preguntar quién mantiene los registros del catálogo, quién aprueba los cambios y quién responde cuando una capacidad publicada deja de estar disponible. Un servicio de descubrimiento gestionado no puede asignar por sí solo esas responsabilidades internas.
La misma distinción se aplica al conocimiento organizativo. Los equipos necesitan un lugar compartido para decisiones, excepciones y procedimientos operativos junto con registros legibles por máquinas. Una base de conocimiento con búsqueda aborda esa necesidad de documentación, mientras que el registro sirve para el descubrimiento en tiempo de ejecución.
La presión no consiste simplemente en centralizarlo todo. Un catálogo excesivamente amplio puede volverse difícil de gobernar, mientras que los catálogos aislados de forma demasiado estrecha pueden conservar los problemas de coordinación que el descubrimiento debería reducir. Los equipos deberían elegir límites basados en patrones reales de propiedad y consumo.
Una medida útil del progreso sería una menor dependencia entre lanzamientos. Si cada nueva capacidad sigue requiriendo ediciones en el orquestador, aprobaciones coordinadas y actualizaciones manuales de los consumidores, la organización ha obtenido un directorio sin lograr demasiada independencia arquitectónica.
A la inversa, la publicación independiente no debería implicar un cambio de comportamiento invisible. Los consumidores necesitan una forma de entender qué capacidades han entrado en el alcance de su aplicación. La independencia operativa funciona mejor cuando la propiedad y la comunicación de cambios siguen siendo explícitas.
El ciclo separa encontrar, conectar y actuar
El mecanismo que sustenta el descubrimiento en tiempo de ejecución de AWS Agent Registry se vuelve más claro cuando cada etapa se trata como una decisión independiente. Encontrar una capacidad relevante, establecer una conexión y decidir qué acción realizar son tareas relacionadas. Requieren evidencias y controles distintos.
AWS documenta la búsqueda híbrida del registro, que combina la coincidencia semántica, basada en el significado, con la coincidencia por palabras clave. Los nombres, las descripciones y los descriptores de protocolo influyen en la relevancia. Un descriptor es el metadato estructurado que describe una capacidad y sus detalles de conexión.
La documentación de búsqueda también indica que los resultados detectables se limitan a registros aprobados. La indexación de búsqueda es eventualmente consistente, lo que significa que un cambio aprobado no se vuelve visible de inmediato en todas partes. Estas propiedades convierten el descubrimiento tanto en un mecanismo de gobernanza como en una dependencia cambiante en tiempo de ejecución.
La búsqueda reduce el conjunto de candidatos; la aplicación aún debe establecer una conexión válida y elegir una acción apropiada.
En el ejemplo de AWS, el descubrimiento devuelve metadatos de conexión sin credenciales de invocación, el material de autenticación necesario para llamar a una capacidad. La aplicación obtiene las credenciales por separado. Después reúne un agente interno temporal a partir de las capacidades descubiertas y libera sus clientes tras la solicitud.
Esta separación importa porque la relevancia no establece permisos. Un servicio puede ser una excelente coincidencia para una solicitud y seguir siendo inaccesible para la aplicación. A la inversa, una aplicación puede disponer de credenciales válidas para un servicio que no debería gestionar la tarea actual.
Por ello, la etapa de instanciación, en la que la aplicación construye el cliente pertinente, debería entenderse como un límite de integración. El software debe interpretar el descriptor, reconocer el tipo de conexión y aplicar una ruta de autenticación establecida. Los resultados de búsqueda no pueden sustituir esas comprobaciones.
La etapa de ejecución introduce otro límite. Seleccionar una capacidad de soporte no determina si la aplicación debe recuperar información, proponer un cambio o realizar ese cambio. Las organizaciones deberían definir esas distinciones en la política de ejecución en lugar de esperar que la relevancia de recuperación las exprese.
Una solicitud de reembolso hipotética ilustra la diferencia. El descubrimiento podría identificar a un especialista en políticas y un servicio de información de pedidos. La aplicación todavía tendría que establecer la identidad del cliente, recuperar la transacción correcta y distinguir el asesoramiento sobre elegibilidad de la autorización para emitir un reembolso.
La arquitectura resulta atractiva porque puede acotar lo que ve el modelo para una solicitud. También crea una dependencia previa: la capacidad adecuada debe llegar al conjunto de candidatos antes de que el modelo pueda elegirla. Un modelo capaz no puede seleccionar una integración que nunca recibe.
Esto sugiere evaluar las etapas por separado. Un candidato ausente es un problema de descubrimiento. Una conexión rechazada es un problema de autenticación o compatibilidad. Una acción inapropiada tras una conexión satisfactoria es un problema de ejecución. Combinarlas en una única categoría de fallo hace más difícil orientar las mejoras.
El ciclo también aclara dónde el almacenamiento en caché, la reutilización de resultados anteriores, se convierte en una elección de política. Reutilizar resultados de descubrimiento podría reducir el trabajo repetido, pero los equipos deberían decidir cómo afectan a esa elección la actualización y la retirada de capacidades. El equilibrio adecuado depende de las consecuencias de la aplicación.
La búsqueda de herramientas de Anthropic muestra el cambio arquitectónico más amplio
AWS está abordando un problema que va más allá de la gestión de catálogos en la nube. La búsqueda de herramientas bajo demanda de Anthropic describe el aplazamiento de las definiciones de herramientas hasta que resultan pertinentes. La idea común es evitar incluir toda la biblioteca de capacidades en el contexto del modelo, la información disponible durante la generación.
El enfoque publicado por Anthropic marca determinadas definiciones para su carga diferida. Claude puede entonces buscar herramientas relevantes y recibir sus definiciones cuando las necesita. Es un contexto útil para entender la dirección de AWS, sin tratar ambos enfoques como productos intercambiables.
El principio de diseño compartido es la exposición selectiva, mientras que las responsabilidades de integración siguen siendo específicas de cada sistema.
Esta comparación ayuda a separar la elección arquitectónica subyacente del posicionamiento de los proveedores. Un equipo puede coincidir en que cargar todas las herramientas desde el inicio es ineficiente y, al mismo tiempo, preferir conexiones explícitas para sus flujos de trabajo más importantes. La exposición selectiva no exige que todas las decisiones de la aplicación sean dinámicas.
La comparación también evita una afirmación exagerada de novedad. El descubrimiento en tiempo de ejecución forma parte de un esfuerzo más amplio por gestionar bibliotecas de capacidades en crecimiento. El ejemplo de AWS aporta un patrón empresarial concreto, en lugar de demostrar que la industria acaba de descubrir el problema.
Para un equipo de plataforma, la pregunta relevante es dónde debe residir la decisión sobre el catálogo. Algunas aplicaciones necesitan un directorio gobernado centralmente que abarque capacidades mantenidas por separado. Otras necesitan principalmente evitar que una biblioteca de herramientas existente sature el contexto disponible del modelo.
Estos requisitos se solapan, pero no son idénticos. Un prompt más pequeño no proporciona automáticamente un flujo de aprobación. Un catálogo gobernado no determina automáticamente la mejor estrategia de selección para un modelo o una tarea concretos.
El argumento más sólido a favor de la conexión explícita también merece una consideración justa. Cuando un flujo de trabajo tiene una secuencia estable y un conjunto limitado de capacidades, los desarrolladores pueden inspeccionar directamente las conexiones previstas. La recuperación en tiempo de ejecución tendría que aportar un beneficio claro para justificar otro punto de decisión.
Un proceso hipotético de conciliación programada ilustra ese caso. Si la aplicación siempre recupera registros, los compara y redacta un informe aprobado, buscar esas mismas capacidades cada vez puede aportar poco valor. La propia secuencia ya expresa el requisito empresarial.
Un asistente general se enfrenta a una situación diferente. Sus solicitudes pueden abarcar tareas no relacionadas, y sus capacidades disponibles pueden pertenecer a equipos que cambian de forma independiente. La selección en tiempo de ejecución resulta más convincente cuando mantener un inventario completo y explícito genera trabajo recurrente de coordinación.
Esto sugiere un principio práctico de evaluación: comparar arquitecturas frente a las mismas tareas y escenarios de cambio. Incluir ejecución rutinaria, incorporaciones de capacidades, fallos y recuperación. Una demostración convincente debería mostrar dónde ayuda la selección dinámica, en vez de asumir que la flexibilidad tiene valor por sí misma.
Los compradores también deberían evitar juzgar la arquitectura solo por el tamaño del catálogo. La cuestión más significativa es si las capacidades útiles siguen siendo detectables y se aplican correctamente a medida que cambia el catálogo. Un inventario impresionante tiene un valor limitado cuando las solicitudes habituales aún requieren enrutamiento manual.
La calidad del descubrimiento necesita sus propias pruebas de producción
La incertidumbre más importante se refiere al comportamiento más allá de la demostración. El recorrido de AWS ilustra el ciclo, pero no establece cómo funcionará un catálogo empresarial concreto. Las afirmaciones sobre producción deberían depender de una evaluación representativa, no de diagramas arquitectónicos.
La API de descubrimiento devuelve metadatos coincidentes ordenados por relevancia y admite filtrado estructurado. Esto convierte el conjunto de candidatos en una salida observable de la aplicación. Los equipos pueden inspeccionar qué devolvió el descubrimiento antes de investigar qué hizo el modelo después.
Una evaluación de producción debería medir si el descubrimiento proporciona las capacidades necesarias, incluidas las solicitudes en las que no debería utilizarse ninguna capacidad.
Empiece por distinguir entre resultados plausibles y suficientes. Un especialista en facturación puede parecer relevante para una consulta sobre un pedido, pero carecer de la información de envío necesaria para responderla. Los evaluadores deberían identificar las capacidades requeridas para completar la tarea, en lugar de aceptar cualquier resultado con una descripción relacionada.
Las solicitudes ambiguas merecen especial atención. Un usuario que pide «arreglar mi pedido» puede referirse a cambiar una dirección, corregir un cargo o informar de mercancía dañada. Una aplicación segura debería reconocer cuándo es necesaria una aclaración, en lugar de interpretar una coincidencia sólida de búsqueda como una intención resuelta.
Los casos negativos son igual de importantes. Algunas solicitudes no deberían generar ninguna conexión porque el catálogo no dispone de la capacidad adecuada. Otras deberían detenerse porque el usuario no tiene permiso o porque la acción solicitada excede el alcance de la aplicación.
El crecimiento del catálogo debería convertirse en una condición de prueba explícita. Los equipos pueden repetir la misma evaluación después de añadir capacidades solapadas, revisar descripciones o retirar servicios. Esto revelaría si los cambios ordinarios de mantenimiento enrutan las solicitudes de forma diferente, incluso cuando el código fuente del orquestador no cambia.
La calidad de las descripciones también debería evaluarse sin fomentar el lenguaje promocional. Los publicadores tienen incentivos para que sus capacidades sean detectables. Los revisores deberían favorecer un alcance y unas exclusiones precisos frente a descripciones que afirman que un servicio gestiona todas las tareas adyacentes.
La separación entre descubrimiento y autenticación crea casos de fallo útiles para probar. Una capacidad relevante podría tener credenciales caducadas, un endpoint no disponible o una respuesta incompatible. La aplicación debería explicar la limitación sin sustituir silenciosamente la acción por otra menos adecuada.
La recuperación merece el mismo escrutinio. Reintentar una consulta de información es distinto de reintentar una solicitud que modifica registros empresariales. Los equipos deberían establecer si una operación se puede repetir de forma segura antes de permitir que la recuperación automatizada la emita de nuevo.
Las pruebas operativas deberían conectar la solicitud con la capacidad seleccionada y el resultado final. De lo contrario, una respuesta fluida puede ocultar una consulta fallida, una alternativa no deseada o una acción que nunca se completó. Los revisores necesitan pruebas sobre la ejecución, además de la calidad de la respuesta.
También existe una cuestión de propiedad cuando falla una evaluación. La parte responsable puede ser el publicador de la capacidad, el responsable del catálogo o el equipo de la aplicación. Definir estas responsabilidades desde el inicio facilitaría la operación de la selección en tiempo de ejecución entre departamentos.
Para el descubrimiento en tiempo de ejecución de AWS Agent Registry, la promesa defendible es la flexibilidad arquitectónica dentro de límites definidos. Una mayor precisión, menores costes operativos y un mantenimiento más sencillo siguen siendo resultados que cada implementación debe demostrar.
Vigile la migración, el crecimiento del catálogo y la publicación independiente
El punto de observación inmediato es concreto. La guía de migración del registro de AWS indica que el espacio de nombres específico agent-registry se lanzó el 6 de agosto de 2026. Un espacio de nombres es el identificador de servicio utilizado en interfaces y configuraciones. La compatibilidad con el espacio de nombres de registro en vista previa bedrock-agentcore termina el 30 de octubre.
La guía describe cambios que afectan a endpoints de servicio, permisos, clientes, identificadores de recursos y configuración relacionada. Indica que otras ofertas de AgentCore no se ven afectadas por este cambio de espacio de nombres del registro. Por tanto, para los usuarios existentes de la vista previa, la migración es una preocupación operativa a corto plazo.
Las próximas pruebas deberían mostrar la finalización de la migración, un descubrimiento estable ante el crecimiento del catálogo y adiciones de capacidades que eviten cambios innecesarios en el orquestador.
En primer lugar, observe si los consumidores de la vista previa completan la migración y verifican sus rutas de descubrimiento. Una actualización de configuración exitosa debería ir seguida de pruebas de que la aplicación prevista aún puede encontrar e invocar capacidades aprobadas. Esto reforzaría la confianza en la continuidad operativa.
Los fallos de migración no invalidarían por sí solos la selección en tiempo de ejecución. Sin embargo, revelarían las exigencias de mantenimiento de depender de una interfaz gestionada que cambia. Los equipos deberían distinguir un problema de migración del servicio de una debilidad en su diseño de búsqueda o ejecución.
En segundo lugar, observe evaluaciones que amplíen el catálogo manteniendo estable el conjunto de solicitudes. La señal útil sería el descubrimiento continuo de las capacidades necesarias pese a un mayor solapamiento y ambigüedad. Informar solo de ejemplos exitosos dejaría sin resolver la cuestión central de escalabilidad.
Las pruebas de un empeoramiento en la selección debilitarían el argumento a favor de una implementación amplia sin controles adicionales. Sugerirían que es necesario revisar los estándares de descripción, los límites del catálogo, el filtrado o las prácticas de evaluación. La expansión del catálogo debería tratarse como un cambio de comportamiento que merece pruebas.
En tercer lugar, observe si equipos independientes pueden publicar capacidades compatibles sin editar rutinariamente el orquestador. Ese es el beneficio organizativo implícito en trasladar las conexiones fuera de las compilaciones. Las pruebas más sólidas incluirían incorporación, configuración de autenticación, propiedad y retirada, en lugar de limitarse a la publicación.
Si las adiciones requieren repetidamente una gestión especial en la aplicación coordinadora, la arquitectura ofrecería menos independencia de la que sugiere su diagrama. Si los equipos pueden añadir capacidades manteniendo un comportamiento predecible, el descubrimiento en tiempo de ejecución habrá aportado un cambio medible en la coordinación de lanzamientos.
Estas señales importan más que las predicciones generales sobre agentes autónomos. Conectan el diseño con resultados de ingeniería observables: continuidad durante la migración, selección fiable durante el crecimiento y menor coordinación cuando cambian las capacidades.
Para una evaluación inicial, elija un flujo de trabajo acotado en el que la propiedad de las capacidades ya abarque varios equipos. Establezca las dependencias actuales de lanzamiento y el comportamiento ante fallos antes de introducir el descubrimiento en tiempo de ejecución de AWS Agent Registry. Mantenga explícitas las solicitudes representativas, las capacidades esperadas y las acciones inaceptables. Compare solicitudes habituales con preguntas ambiguas, servicios ausentes y accesos denegados. Después, introduzca una capacidad compatible y examine qué cambia realmente en la publicación, aprobación, autenticación, descubrimiento y ejecución. Conserve las conclusiones junto con sus decisiones técnicas para que los futuros responsables del mantenimiento comprendan los límites. Antes de ampliar el catálogo, pregunte si la aplicación se ha vuelto más fácil de extender sin dejar de ser comprensible para las personas responsables de su comportamiento.
