Los registros de agentes le indican qué existe, no si aún se puede confiar en ello.
Un marco de cuatro preguntas para los registros de capacidades de agentes que abarcan la existencia, idoneidad, estatus y procedencia, además de una prueba sencilla de verificación reciente que puede ejecutarse hoy mismo.
Imagínese a un agente en una ejecución rutinaria que busca una herramienta por su nombre, la llama, recibe una respuesta razonable y continúa. La ejecución tiene éxito, y ese es el aspecto preocupante, porque nadie en el equipo revisó nunca esa funcionalidad. Los registros y los servicios de descubrimiento deberían poner bajo control situaciones como esta, y en tan solo una semana llegaron varios productos y especificaciones que afirman ser esa capa de control.
Ninguno de ellos está equivocado, pero juntos abordan solo la mitad de lo que un equipo necesita saber antes de que un agente utilice una nueva funcionalidad. Este artículo divide el problema en cuatro preguntas distintas, muestra cuáles responden los registros actuales y ofrece una verificación concreta, además de una breve lista de acciones, para aquellas que dejan sin resolver.
Qué llegó a la capa de registros
Los detalles a continuación reflejan los anuncios en el momento de redactar este texto; consulte la documentación actual antes de confiar en características específicas o números de versión.
Registro de agentes de AWS
El Registro de agentes en AWS ya está disponible para todos. Pensemos en él como un catálogo privado con gobernanza integrada, capaz de almacenar agentes, servidores MCP, tarjetas de agentes A2A, habilidades y recursos personalizados arbitrarios. El diseño mantiene intencionadamente separados dos planos: los curadores trabajan en un plano de gobernanza donde se aprueban o rechazan las entradas; los usuarios consultan un plano de descubrimiento que solo muestra las entradas aprobadas. Cada registro pasa por cinco estados (borrador, pendiente, aprobado, rechazado, obsoleto). Los eventos de EventBridge impulsan las transiciones entre ellos, y CloudTrail mantiene el registro de auditoría.
Con la disponibilidad general llegó el soporte para infraestructura como código (CloudFormation, CDK y Terraform), la posibilidad de compartir recursos entre cuentas a través de RAM, y la detección automática, en toda la organización, de los agentes que ya están en ejecución en AgentCore. Esta función de detección es fácil de pasar por alto, y existe porque los agentes “sombra” no rastreados ya se han convertido en un verdadero problema de gestión de inventario. Entre los usuarios destacados se encuentran Southwest, PepsiCo, Syngenta, Amdocs y Sony, lo que indica que los compradores ya han dejado atrás la fase de pruebas piloto. AWS describe en detalle su diseño en su blog de aprendizaje automático.
Detección de Recursos Agenciales (ARD)
Junto a esto, una especificación respaldada por varios proveedores aborda la misma brecha. Agentic Resource Discovery fue desarrollada por colaboradores de Google, Microsoft y Hugging Face y se publicó bajo licencia Apache 2.0, con contribuciones adicionales de NVIDIA, Salesforce y Databricks. La cobertura de The New Stack la describe como un DNS para agentes. Su interfaz es intencionalmente sencilla. Los mensajes se envían en formato JSON-LD a través de REST. Existe un único endpoint obligatorio, POST /search, al cual se envían consultas con una descripción de la tarea en lugar del nombre del recurso. Los endpoints de exploración son opcionales. La federación permite a una empresa mantener su propio catálogo privado mientras envía consultas a registros externos en los que haya decidido confiar. En el momento de redactar este texto, la especificación se encuentra en la versión 0.91; su modelo de gobernanza sigue siendo abierto, y se ha mencionado al W3C como uno de los posibles entornos para su desarrollo.
La verificación continua como producto
El tercer lanzamiento fue una startup llamada AIR, que surgió de forma discreta después de recaudar 50 millones de dólares en dos rondas iniciales de financiación (Sequoia lideró la primera y Greenoaks la segunda). Su actividad consiste en inspeccionar los complementos, habilidades y servidores MCP que cargan los agentes. Una estadística suya merece ser tenida en cuenta: aproximadamente el 27% de las habilidades y complementos de origen público que actualmente evalúan son descartados.
Cuando tres lanzamientos se dirigen a una misma área en cuestión de días, generalmente significa que la industria ha llegado a un consenso sobre dónde se encuentra la pieza faltante.
Por qué el descubrimiento no es tarea de MCP
MCP nunca afirmó resolver el problema del descubrimiento de herramientas. Define la mecánica para invocar una herramienta después de que el agente ya haya decidido cuál utilizar. A2A hace lo mismo para conversaciones entre agentes que ya se conocen. En ambos casos, se supone que la localización y selección de la capacidad correspondiente ya ha tenido lugar anteriormente. Si desea repasar esa distinción, consulte cómo el Modelo de Protocolo de Contexto permite a los agentes AI descubrir y utilizar herramientas.
Lo que cambió es el volumen. Conectar manualmente servidores MCP se puede manejar con una docena de herramientas. Pero al tener más de mil, propiedad de diferentes equipos internos, proveedores SaaS y plataformas en la nube, un agente restringido a una lista fija en su configuración apenas puede considerarse un agente; está más cerca de un script fijo que, por casualidad, llama a un modelo. El descubrimiento permite que el conjunto de capacidades cambie en tiempo de ejecución. Esa misma característica implica que nadie ha auditado ese conjunto, y pocas equipos han tenido en cuenta ese compromiso al fijar precios.
Otra presión proviene de la forma en que se están extendiendo los agentes. Los investigadores que analizaron el código fuente de once herramientas de codificación para producción, con aproximadamente cuatro millones de líneas que abarcan herramientas como OpenHands, Gemini CLI, Codex CLI y Claude Code (arXiv 2609.00006), descubrieron que las habilidades en el estilo SKILL.md han superado a MCP en estas herramientas: nueve de las once admiten habilidades y ocho, MCP. Por lo tanto, el mecanismo de extensión que se está difundiendo más rápidamente es un archivo Markdown repleto de instrucciones que el agente ejecutará. Dichos archivos no cuentan con mecanismo de firma ni prácticamente ningún sistema de control de versiones, por lo que una entrada en el registro que apunte a uno de ellos ofrece poca información sobre qué hará mañana.
Cuatro preguntas que debe responder un registro
Cada vez que un agente está a punto de utilizar una capacidad que recientemente no estaba disponible para él, se necesitan cuatro respuestas separadas. Suenan similares pero corresponden a problemas diferentes; al separarlos se puede ver qué hace realmente un producto determinado en comparación con el propósito para el cual se adquiere.
Existencia: ¿existe algo que haga esto?
¿Hay alguna capacidad que pueda manejar esta tarea y dónde está alojada? Esa es la función a la que apunta POST /search de ARD, y el mecanismo de descubrimiento de AWS lo hace muy bien. El problema es real, y a efectos prácticos ya está casi resuelto.
Adecuación: ¿qué candidato es el adecuado para esta tarea?
Una búsqueda devuelve varios candidatos, ¿entonces cuál debería usar el agente? Los propios autores de ARD afirman que la comparación con DNS falla en este caso: una consulta genera candidatos en lugar de una única dirección autoritativa, y cada servicio aplica sus propias reglas de confianza y clasificación. Dejar esto abierto es razonable para una especificación reciente. No lo es para su implementación, ya que la clasificación es precisamente donde un atacante querría insertarse, al igual que con el envenenamiento de motores de búsqueda o el typosquatting en registros de paquetes.
Estatus: ¿está aprobado actualmente?
Aquí es donde AWS destaca por encima de los demás: los estados del ciclo de vida junto con los eventos ofrecen una respuesta bien estructurada, más avanzada que cualquier otra solución en estos sistemas. La debilidad radica en que una aprobación puede quedar obsoleta con el tiempo. Supongamos que un elemento fue detectado automáticamente, aprobado en marzo y luego ignorado. Para septiembre, el sistema sigue presentándolo como si un curador lo hubiera revisado esa misma mañana.
Procedencia: ¿quién lo escribió y qué ha cambiado?
¿Quién desarrolló esta funcionalidad? ¿Qué ha cambiado desde la última vez que se revisó y qué carga en tiempo de ejecución? Nada en la actual ola de lanzamientos responde a estas preguntas, y esa es precisamente la premisa detrás de la financiación de AIR. Su postura, que sigue vigente, es que la verificación debe ser continua y no algo puntual. Una habilidad que superó la revisión hace un mes puede volverse maliciosa tras una actualización de dependencias o por el secuestro de la cuenta del mantenedor, mientras su entrada en el catálogo permanece exactamente igual. Los trabajos académicos apuntan en la misma dirección. Investigaciones recientes sobre los fundamentos de los agentes basados en habilidades (arXiv 2608.29596) modelan un ciclo de vida de nueve etapas y sitúan los registros públicos, los mercados y los adversarios en el centro de la arquitectura, en lugar de tratarlos como consideraciones posteriores durante el funcionamiento.
Problemas de búsqueda versus problemas de cadena de suministro
Las dos primeras preguntas están relacionadas con la búsqueda. Las últimas dos se refieren a la cadena de suministro, y la industria ya ha pasado por esto anteriormente con extensiones de navegador, imágenes base de contenedores y paquetes npm. En cada caso, los catálogos existían mucho antes de que alguien pudiera garantizar su contenido, y los incidentes de seguridad se concentraron en ese período.
La prueba verificada más reciente
Esta comprobación es deliberadamente sencilla, porque la respuesta es más importante que el marco utilizado. Tome su lista actual de capacidades del agente, ya sea un registro adecuado o simplemente una hoja de cálculo, y elija una sola entrada. Luego busque dos marcas de tiempo:
- ¿Cuándo fue aprobada?
- ¿Cuándo, por parte de una persona o un proceso automatizado, se comparó por última vez con su fuente original?
Cuando esas marcas de tiempo coinciden, se trata de un catálogo y no de un plano de control. La primera registra una decisión tomada en el pasado; la segunda refleja la realidad actual. Cuente los días entre las dos fechas: ese es el tiempo durante el cual una capacidad aprobada y luego olvidada ha estado disponible para ser modificada sin que nadie se diera cuenta. Dado que alrededor de una cuarta parte de las habilidades disponibles públicamente ya fallan en las verificaciones básicas, esa cifra constituye una medida razonable de su verdadera exposición.
Muchos equipos no cuentan con una segunda marca de tiempo que mostrar. Esa ausencia es el resultado real: el problema no radica en un valor deficiente, sino en la falta de un campo.
Qué hacer este trimestre
El plan práctico consta de tres partes, según el nivel de esfuerzo requerido.
- Adopte un registro. El inventario representa un problema real, y un agente no rastreado es más peligroso que una suscripción SaaS sin seguimiento, ya que actúa por su cuenta. Los equipos que ya están desarrollando con Bedrock deberían considerar seriamente la opción de AWS; aquellos que necesitan federación y neutralidad del proveedor podrían preferir ARD.
- Añada el campo que falte en el registro. Asigne a cada entrada una marca de tiempo de última verificación que actualice un proceso automatizado, y no un humano. Decida con antelación qué condición activará la actualización: vencimiento, cuarentena o una alerta. Cualquiera de estas opciones es mejor que el comportamiento habitual actual, en el que una entrada obsoleta permanece activa indefinidamente.
Un complemento útil para este plan es una capa de control en tiempo de ejecución que decide qué puede hacer realmente una capacidad descubierta; permisos, puertas de aprobación y niveles de riesgo para los agentes aborda ese aspecto.
Puntos clave
- Los registros y las especificaciones de descubrimiento ahora responden razonablemente bien a las preguntas “¿qué existe?” y “¿está aprobado?”.
Lecturas relacionadas
- Interfaz de chat o bucle de agente: cómo decidir qué necesita tu característica de IA — Aprende a diferenciar un chatbot conversacional de un agente orientado a objetivos, qué aporta el bucle de agente y cómo decidir cuál es realmente necesario para tu característica de IA.