El problema de agent sprawl empieza cuando dos equipos construyen la misma capacidad sin saber que el otro ya la tiene.
La gobernanza de IA suele comenzar con un inventario: modelos, casos de uso, owners, clases de riesgo y proveedores. Es necesario mientras el estate es pequeño. Los sistemas agénticos convierten ese inventario en algo mucho más dinámico.
Un agente puede depender de skills, tools, servidores MCP, prompts, políticas, modelos y otros agentes. Cada componente tiene lifecycle y ownership propios. Además, el descubrimiento entra en runtime: builders y agentes necesitan encontrar capacidades aprobadas en lugar de recrearlas o hardcodearlas.
AWS hizo Agent Registry generalmente disponible el 31 de agosto de 2026 como catálogo gobernado y buscable para agentes, herramientas, skills, MCP servers y recursos personalizados, con ownership, flujos de trabajo de aprobación, auditoría, infraestructura como código y descubrimiento entre cuentas.
El patrón corporativo se parece a una CMDB para inteligencia delegada.
Descubrimiento sin gobernanza crea capacidad en sombra
Si cualquier desarrollador puede descubrir cualquier herramienta interna, mejora el reuse pero aumenta la exposición.
Si nada es descubrible, los equipos crean duplicados e integraciones shadow.
Un registro necesita responder a ambas preguntas:
¿Qué existe?
y
¿Qué tienes permiso para saber que existe y utilizar?
Los records deberían ser permission-aware. Capacidades sensibles pueden ser visibles solo para determinados equipos o entornos.
El discovery es una superficie de gobernanza.
Todo agente necesita un owner
Un registro de producción debe contener más que nombre y descripción.
Metadatos útiles:
- business owner accountable;
- technical owner;
- propósito;
- entornos aprobados;
- clasificación de datos;
- usuarios o agentes permitidos;
- modelos y runtimes;
- herramientas y dependencias;
- nivel de riesgo;
- versión actual;
- estado de evaluación;
- última revisión;
- fecha de deprecación;
- contacto de incidente;
- centro de coste.
El registro se convierte en el lugar desde el que responder “¿quién es responsable de esta capacidad autónoma?”.
Durante un incidente esa pregunta es crítica.
Registrar skills y tools, no solo agentes
Centrarse en el agente superior pierde buena parte del riesgo y del potencial de reutilización.
Una capacidad “cambiar dirección de proveedor” puede estar:
- embebida en tres agentes;
- expuesta como tool MCP;
- empaquetada como skill reutilizable;
- llamada por un flujo de trabajo;
- disponible para un coding agent.
La organización debería poder trazar esas relaciones.
Si una herramienta vulnerable debe retirarse, el registro debería revelar todos los agentes dependientes.
El inventario se convierte así en inteligencia de dependencias.
La aprobación debe conocer el lifecycle
Registrar no equivale a aprobar.
Un lifecycle robusto puede ser:
DRAFT → EVALUATED → APPROVED → PRODUCTION → DEPRECATED → RETIRED
La promoción puede exigir evidencia:
- umbral de evaluación superado;
- owner asignado;
- revisión de seguridad;
- revisión de datos;
- reversión definido;
- telemetría habilitada;
- política adjunta.
El registro debe mostrar el estado de gobernanza actual, no insinuar que “descubrible” significa “seguro”.
Infraestructura como código importa
Cuando el registro se convierte en infraestructura operativa, los records manuales de consola no bastan.
Registros y políticas deberían ser reproducibles con CI/CD, incluyendo:
- control de versiones;
- revisión de cambios;
- promoción entre entornos;
- tags;
- checks automáticos de ownership;
- detección de drift.
Así el catálogo se mantiene alineado con lo que realmente corre.
El autodiscovery ayuda, pero los activos detectados deberían entrar en estado controlado hasta ser revisados.
Un estate multi-proveedor necesita una vista lógica por encima de catálogos de proveedor
Las grandes empresas no ejecutarán cada agente en una única nube.
Los registros nativos de proveedor son útiles. La gobernanza corporativa necesita además una vista lógica capaz de abarcar:
- cloud A;
- cloud B;
- agentes SaaS;
- runtimes self-hosted;
- automatización departamental;
- agentes de terceros.
Los catálogos físicos pueden seguir distribuidos mientras se federan metadatos de gobernanza.
La visión de Lexdatum
Un agent registry no es un marketplace de bots ingeniosos. Es el inventario de control de capacidad organizativa ejecutable por máquinas.
Bien construido reduce duplicación, mejora discovery, soporta incident response y da a la gobernanza un objeto concreto que gestionar.
Antes de preguntar cómo orquestar miles de agentes, una empresa debería responder algo más sencillo:
¿Qué agentes, tools y skills existen hoy y quién es owner de cada uno?
Sources
Nota de investigación: este análisis se basa en información pública disponible el 1 de septiembre de 2026. Las capacidades de producto, precios e interpretaciones regulatorias pueden cambiar. Las afirmaciones de proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad, financiero ni de inversión.