Una solicitud es denegada. Tres agentes la procesaron —uno verificó elegibilidad, uno decidió necesidad médica, uno validó los códigos— y cada uno reportó éxito. Los logs coinciden: solicitud recibida, modelo llamado, base de datos consultada, respuesta devuelta, sin errores. Y aun así el resultado está mal, el cliente está molesto, y nadie puede decir por qué. El ingeniero de guardia recorre un flujo plano de eventos con timestamp durante una hora y no aprende nada, porque el fallo no está en ningún evento individual. Está en el espacio entre ellos.
Ese espacio es exactamente lo que un log no puede mostrarte y un trace sí. A medida que los sistemas de agentes pasan de una llamada a un modelo a una malla coordinada de ellas, la brecha entre "tenemos logging" y "podemos depurar esto" se vuelve la brecha entre un sistema que operas y un sistema que te opera a ti.
Por qué los logs de eventos dejan de funcionar
El logging basado en eventos se construyó para un mundo de pasos discretos, orquestados centralmente. Llega una solicitud, pasan unas cuantas cosas conocidas en un orden conocido, registras cada una, y cuando algo se rompe lees la línea donde se rompió. Ese modelo aguanta hasta que el control deja de ser central.
Un sistema multi-agente no tiene centro. Los agentes se pasan resultados parciales entre sí, toman decisiones según lo que recibieron, y los fallos interesantes son emergentes: información que era correcta cuando el agente A la produjo ya no está para cuando el agente C la necesita; dos agentes se esperan mutuamente; el error de un agente envenena en silencio un contexto compartido en el que tres agentes posteriores confían. Nada de eso produce una línea de error. Cada agente hizo su trabajo y registró éxito. El log es un montón de afirmaciones verdaderas que juntas no explican nada.
La investigación publicada sobre fallos de agentes pone números duros a esto —traces de ejecución a través de muchos frameworks muestran tasas de fallo que serían alarmantes en cualquier otro software, agrupándose en problemas de diseño de sistema, desalineación entre agentes, y brechas de verificación—. El hilo común es que los fallos viven en la coordinación, y la coordinación es invisible para el logging por componente.
Qué es realmente un trace
Un trace no es un log más sofisticado. Es una estructura de datos distinta: un árbol, no un flujo.
Cada unidad de trabajo es un span —una generación del LLM, una recuperación, una llamada a una tool— y cada span lleva su propio ID y el de su padre. Los spans que pertenecen a la misma solicitud comparten un único trace ID. Ese es todo el truco, y alcanza para reconstruir la forma causal completa de una solicitud a través de cada frontera de agente y tool: qué llamó a qué, en qué orden, con qué inputs, y dónde se fueron el tiempo y los tokens. Un log plano te dice que pasaron quince cosas. Un trace te dice que este span causó esos tres, que alimentaron aquel, que es donde el contexto se truncó.
Dos cosas convierten un árbol de trace de un diagrama de tiempos en un instrumento de depuración:
- Contexto semántico en el span. No solo "corrió la recuperación", sino qué recuperó, por qué se eligió esta tool, la confianza que el agente le adjuntó, y qué memoria leyó. La secuencia muestra qué pasó; el contexto semántico muestra por qué el agente pensó que debía hacerlo.
- Sellos de versión en el span. Qué versión de prompt, qué config de tool, qué revisión de agente estaba viva cuando este span corrió. En el momento en que tus agentes empiezan a adaptarse desde el feedback, esto es lo único que te deja conectar un fallo nuevo con el cambio que lo causó —pero eso es su propia discusión.
La taxonomía de fallos que de verdad estás depurando
Una vez que puedes ver el árbol, los modos de fallo multi-agente recurrentes dejan de ser misterios y se vuelven formas reconocibles:
- Colapso de contexto — la ventana se llena de output intermedio y un valor crítico anterior (un score de confianza, un flag) se trunca antes de llegar al agente que lo necesitaba.
- Errores en cascada — el output equivocado-pero-plausible de un agente se vuelve el input confiable de otro, y el error se compone aguas abajo.
- Deadlocks de coordinación — dos agentes se esperan mutuamente.
- Tormentas de reintentos — una mala coordinación dispara reintentos exponenciales que parecen un pico de carga.
- Contaminación de contexto — un agente escribe datos malos en memoria compartida y cada lector los hereda.
Un log plano renderiza todo esto como "todo tuvo éxito, el output estuvo mal". Un trace renderiza cada uno como una imagen específica y arreglable.
La observabilidad es parte del build, no un agregado
El error que más vemos es tratar el tracing como algo que atornillas después de que el agente funciona en una demo. Para entonces es demasiado tarde y demasiado caro —estás metiendo instrumentación a la fuerza en un sistema cuyos fallos ya no puedes ver—. La observabilidad es arquitectura. La decisión sobre qué captura un span, dónde están las fronteras del trace, y cómo se propaga el contexto entre agentes se toma en tiempo de diseño o no se toma bien. Es la misma lección que poner un verificador en el runtime y escribir el runbook de las 3 a.m. antes de las 3 a.m.: el sistema que sobrevive a producción es el que se construyó para poder mirar adentro.
Cierre
"La IA se equivocó" no es una afirmación depurable. Es el sonido de un equipo que entregó un sistema multi-agente con logs en lugar de traces y ahora hace arqueología en vez de ingeniería.
No puedes arreglar fallos de coordinación que no puedes ver, y no puedes verlos en un flujo de eventos. El árbol de trace —spans tipados, trace ID compartido, razonamiento y versiones adjuntos— es lo que convierte "el output estuvo mal y todos tuvieron éxito" en una causa raíz. Constrúyelo desde el primer span, porque no puedes depurar lo que nunca trazaste.