La mayoría de los equipos que construyen sistemas multi-agente buscan primero herramientas de observabilidad. Conectan dashboards, configuran umbrales de alerta y ajustan agregadores de logs. Luego despliegan. Luego algo falla silenciosamente y nadie puede decir qué agente lo causó, qué se suponía que debía hacer, ni quién debe resolver el problema.
El paso que falta no es mejor monitoreo. Es un inventario de flota.
Qué es un inventario de flota
Un inventario de flota es un registro legible por máquina de cada agente en ejecución dentro de tu sistema. No un README. No un documento en Notion. Un archivo estructurado — JSON, YAML, TOML, el que prefieras — que tu infraestructura puede leer, validar y consultar.
Cada entrada responde tres preguntas:
- ¿Qué es este agente?
- ¿Cómo sé que está sano?
- ¿Qué pasa cuando no lo está?
Sin ese registro, tus herramientas de monitoreo están vigilando un sistema que no entienden. Pueden decirte que un proceso está caído. No pueden decirte si ese proceso debía estar corriendo, de qué era responsable, ni qué agentes dependientes están ahora sin entrada.
Los tres campos que debe contener cada entrada
1. Identidad
La identidad es más que un nombre. Un bloque de identidad útil incluye:
- Nombre canónico — la cadena exacta usada en logs, alertas y handoffs
- Rol — una oración que describe la función del agente y su posición en el pipeline
- Responsable — un equipo o persona accountable de su comportamiento
- Versión — la versión desplegada, no el último tag en el repositorio
El nombre canónico importa más de lo que parece. Si tu agregador de logs lo llama prospect-enricher, tu alerta se dispara con enrichment-agent, y tu runbook hace referencia a lead-enrichment-worker, tienes tres nombres para una sola cosa. Durante un incidente a las 2 AM, esa ambigüedad cuesta 20 minutos.
2. Contrato de heartbeat
Un contrato de heartbeat define cómo se ve la salud en términos medibles:
- Cadencia esperada — con qué frecuencia debe producir output el agente (por ejemplo, al menos un registro procesado cada 90 segundos)
- Techo de latencia — el tiempo máximo aceptable entre la recepción de input y la emisión de output
- Umbral de tasa de errores — el porcentaje de fallos que dispara una alerta frente al ruido normal
Estos números deben provenir del comportamiento observado en staging, no de suposiciones. Ejecuta el agente bajo carga realista durante 48 horas. Registra la latencia p95. Fija tu techo en 2x ese número. Ahora tu monitor tiene un contrato que hacer cumplir, no una vaga sensación de que "las cosas parecen lentas".
3. Ruta de escalación de fallos
Este campo responde: cuando se viola el contrato de heartbeat, ¿qué sucede a continuación?
Una ruta de escalación mínima tiene tres pasos:
- Política de auto-reintento — cuántos reintentos, con qué backoff, antes de considerar que el agente ha fallado
- Comportamiento de fallback — ¿el pipeline se pausa, enruta alrededor del agente fallido, o emite un output degradado?
- Destino de escalación humana — qué persona o canal recibe la alerta, y qué información necesita para actuar
El comportamiento de fallback es el campo que más equipos omiten. Definen la alerta pero no la respuesta. Entonces cuando la alerta se dispara, el ingeniero de guardia tiene que tomar una decisión bajo presión sin ninguna guía documentada. Escribe el comportamiento de fallback cuando el sistema está tranquilo, no cuando está roto.
Cómo arrancar antes de tu primer incidente
No necesitas un inventario perfecto el primer día. Necesitas uno completo — cada agente contabilizado, aunque algunos campos sean marcadores de posición.
Una secuencia práctica de arranque:
- Lista cada agente que corre actualmente en producción. Si no puedes listarlos de memoria en cinco minutos, ese es el primer problema a resolver.
- Crea un archivo de inventario por entorno (producción, staging). Mantenlos en control de versiones junto a tu código de infraestructura.
- Llena primero los campos de identidad. Nombre canónico, rol, responsable, versión. Esto toma menos de una hora para la mayoría de los sistemas.
- Instrumenta los contratos de heartbeat a partir de datos observados. Despliega en staging, ejecuta tráfico realista durante 48 horas, registra los números.
- Escribe las rutas de escalación de fallos antes de escribir la siguiente función. Trátalo como una tarea bloqueante, no como un ítem del backlog.
En DK1.AI, cada sistema en producción que construimos comienza con este inventario antes de que el primer agente entre en producción. Cuando construimos despliegues de AI Brand Presence, el inventario de flota es el primer artefacto que producimos — no el último. Determina cómo estructuramos el monitoreo, cómo definimos "terminado", y cómo transferimos las operaciones al equipo del cliente.
El inventario no previene los fallos. Los hace legibles. Un fallo legible toma 15 minutos en diagnosticarse. Uno ilegible toma 3 horas y una sala de guerra.
El beneficio práctico
Un equipo que opera 8 agentes sin inventario gastará aproximadamente 2–3 horas por incidente solo estableciendo qué falló y por qué. El mismo equipo con un inventario actualizado reduce eso a menos de 30 minutos. A lo largo de un trimestre con 4 incidentes, eso son 6–10 horas recuperadas — más el beneficio acumulado de una iteración más rápida porque los ingenieros confían en el sistema que están modificando.
Las victorias aburridas ganan. Un archivo YAML en tu repositorio supera a un hermoso dashboard de observabilidad construido sobre un sistema sin mapear.