Mi Agente Llamó 5 Veces la Misma API Fallida — El Bug No Estaba en el Código

Un bug llegó a producción. Mi agente estaba repitiendo la misma llamada a una API cinco veces seguidas. Por instinto, lo primero que hice fue abrir el código. La lógica de reintentos estaba bien. El flujo de funciones era normal. Los logs no mostraban ningún error. El código no tenía respuestas.

Recién cuando abrí el trace apareció la causa.

El código de un agente es un cascarón vacío

Abrí cualquier agente y encontrás lo mismo: una especificación del modelo, una lista de herramientas y un system prompt. Eso es todo. Qué herramienta llamar en qué momento, qué secuencia de razonamiento seguir — nada de eso vive en el código. Los equipos que trabajan con agentes basados en LangGraph lo dicen directo: “No podés juzgar la calidad de un agente con code review.”

• El mismo código, el mismo input, patrones de llamadas a herramientas distintos cada vez
• A diferencia de handleSubmit(), la lógica de bifurcación no existe en el código
• GPT-5.2 con la misma consulta 10 veces: apenas ~40% de consistencia en el orden de las llamadas a herramientas
• Hay errores, pero ningún bug en el código, lo que hace imposible reproducirlos

El problema no es que escribiste mal el código. Es que el comportamiento que importa se decide en runtime, dentro del modelo, y el código fuente nunca lo vio.

Los traces son el nuevo código fuente

Un trace registra cada paso. Qué razonó el agente, qué herramienta llamó y por qué.

Cuando apareció el bug de las cinco llamadas repetidas, el trace me mostró algo que el código jamás hubiera revelado: el modelo estaba interpretando el error de la API como una señal ambigua. No como un fallo definitivo. Cada vez que recibía la respuesta fallida, el razonamiento interno concluía que valía la pena intentarlo de nuevo. No era un loop infinito — era el modelo tomando una decisión lógica con información incompleta.

• Comparar dos traces lado a lado muestra el impacto de un cambio de prompt al instante
• Cargar un trace en LangSmith funciona como poner un breakpoint: pausás la ejecución y mirás el estado exacto
• Sin trace, ese razonamiento interno es invisible. El código solo te muestra que algo pasó, no por qué

La diferencia con el debugging tradicional es brutal. En código normal, el estado está en variables que podés inspeccionar. En un agente, el estado está en el razonamiento del modelo — y solo el trace te lo expone.

Las pruebas cambian de raíz

Los agentes son no deterministas. Escribir un test que pase hoy no te garantiza que pase mañana con el mismo input. Esta realidad obliga a repensar toda la estrategia de QA.

El enfoque que funciona: pipelines de evaluación automatizados que sampleen traces de producción cada semana. No se trata de testear casos específicos — se trata de monitorear distribuciones de comportamiento a lo largo del tiempo.

• ¿El agente llama a la herramienta correcta en el 80% de los casos? ¿O bajó al 65% esta semana?
• ¿Los traces muestran que el razonamiento intermedio cambió después del último deploy?
• Monitorear sin traces es como revisar si el servidor está prendido y llamarlo “observabilidad”

Las métricas de infraestructura no te dicen nada sobre si el agente está razonando bien. Solo los traces te lo cuentan.

La colaboración y los analytics de producto también pasan en los traces

En el desarrollo tradicional, el code review pasa en GitHub. Con agentes, el review del juicio del modelo pasa en las plataformas de observabilidad.

Un product manager que quiere entender por qué el agente tomó cierta decisión no puede leer el código — porque la decisión no está ahí. Puede leer el trace. Un ingeniero que quiere explicarle al equipo de negocio qué salió mal tampoco va a abrir el repo — va a compartir el trace.

• Los analytics de producto y las herramientas de debugging convergen en el mismo lugar: los traces
• Las anotaciones en traces reemplazan los comentarios en PRs para razonar sobre comportamiento
• Las regresiones de comportamiento se detectan comparando distribuciones de traces, no corriendo unit tests

Esto también cambia quién puede participar en el debugging. No necesitás acceso al código para entender qué hizo el agente. Necesitás acceso a los traces.

La conclusión

El código es el plano del edificio. Los traces son las cámaras de seguridad. Cuando algo sale mal, primero rebobinás el video.

Cuando mi agente llamó cinco veces la misma API fallida, el código me dijo que todo estaba bien. Los traces me mostraron exactamente en qué momento el modelo decidió que valía la pena intentarlo de nuevo — y qué información lo llevó a esa conclusión.

Esa visibilidad no la conseguís con ninguna cantidad de console.log. Solo la conseguís con traces.