Lo que aprendí construyendo herramientas para observar agentes reales, y por qué el problema ya no es generar código sino confiar en él.*
Hace unos meses estaba convencido de que entendía cómo trabajaban los agentes modernos. Sabía qué agentes había definidos en el sistema. Sabía cuál era el flujo que esperábamos. Sabía qué prometían las demos, propias y ajenas.
Lo que no tenía era forma de ver qué hacían *realmente*.
Esa pregunta —¿qué está pasando ahí adentro?— terminó convirtiéndose en semanas de trabajo construyendo herramientas para observar sistemas multi-agente en ejecución real: reconstruir conversaciones, dibujar quién llamó a quién, medir tiempos y costos, separar lo que el sistema *decía* que hacía de lo que efectivamente hacía. Y lo más interesante fue esto: varias cosas que dábamos por ciertas dejaron de serlo apenas apareció la evidencia.
Casi todo lo que sé de IA agéntica lo aprendí en ese hueco —entre lo que un sistema reporta y lo que de verdad ocurre. Quiero contar lo que encontré ahí, porque es donde está el estado del arte de verdad, lejos del hilo viral.
## Qué cambió de verdad
La diferencia entre un copiloto y un agente no es la calidad del modelo. Es el **bucle**.
Un copiloto vive en un único turno: vos preguntás, él responde, se acabó. Un agente vive en un bucle de *percepción → acción → observación*: decide usar una herramienta, observa qué devolvió, y usa esa observación para decidir el próximo paso. Esa estructura, prestada de la robótica y del aprendizaje por refuerzo, es lo que convierte a un modelo de lenguaje en algo que puede *operar* un sistema en vez de solo describirlo.
En la práctica esto significa que el agente puede correlacionar un identificador entre servicios, grepear un log, encontrar la línea que falla, abrir el archivo, leer el contexto alrededor y proponer un fix concreto —todo sin que toques el teclado entre paso y paso. La unidad de trabajo dejó de ser "la línea" y pasó a ser "la tarea".
Y acá aparece la primera verdad incómoda, la que va a recorrer todo este artículo: **un agente es tan bueno como las herramientas que le das, y tan confiable como tu capacidad de verificarlo.** Generar dejó de ser el problema difícil. Confiar empezó a serlo.
## Agente no es lo mismo que workflow
Antes de seguir conviene desarmar una confusión que está en todos lados, porque sin esta distinción el resto del artículo se lee mal.
Un **workflow** es una secuencia predefinida. Vos decidís de antemano el orden de los pasos —primero esto, después aquello, si falla esto otro— y el sistema los recorre. Que en el camino llame a un modelo de lenguaje no lo hace agéntico; lo hace un pipeline con un LLM adentro. Es determinista por diseño, y eso muchas veces es exactamente lo que querés: predecible, auditable, reproducible.
Un **agente** decide dinámicamente. No tiene el camino escrito de antemano: evalúa el estado, elige la próxima acción, observa el resultado y vuelve a decidir. El control de flujo lo lleva el modelo, no vos.
La distinción importa porque buena parte de la industria las mezcla, casi siempre en la misma dirección: workflows sofisticados presentados como agentes autónomos. Un diagrama con cinco cajas y flechas no prueba autonomía; muchas veces es una secuencia fija bien maquillada. No todo lo que usa un LLM es un agente, y no todo sistema multi-step es agéntico. La pregunta correcta no es "¿cuántos pasos tiene?" sino "¿quién decide el próximo paso —el código o el modelo?". Ninguna de las dos arquitecturas es mejor que la otra; lo que es un problema es no saber cuál tenés.
## El contexto es el nuevo cuello de botella
Durante un tiempo creímos que el problema era el tamaño de la ventana de contexto. Más tokens, más memoria, mejor agente. Resultó ser una verdad a medias.
El problema real no es *cuánto* podés meter en el contexto, sino *qué*. A esto se le empezó a llamar **context engineering**, y es probablemente la habilidad más subestimada del momento. Un agente con 200.000 tokens de contexto lleno de ruido rinde peor que uno con 20.000 bien curados. La señal se diluye; el modelo se "distrae" con archivos que no importan y pierde el hilo de lo que sí.
Las consecuencias son contraintuitivas:
- **Leer un archivo entero "por las dudas" es un costo, no un seguro.** Cada token irrelevante empuja a los relevantes hacia los márgenes, donde el modelo presta menos atención.
- **Delegar búsquedas a sub-agentes** que devuelven *solo la conclusión* —y no el volcado de treinta archivos— mantiene limpio el contexto principal. El que orquesta se queda con la respuesta, no con el desorden.
- **Resumir y comprimir** la conversación larga es parte del trabajo, no un detalle.
Cuando dejás de pensar el contexto como una mochila infinita y empezás a tratarlo como un escritorio donde solo cabe lo que estás usando ahora, todo mejora. Y, de nuevo, esto alimenta la misma tesis: cuanto más limpio el contexto, más fácil es *verificar* por qué el agente hizo lo que hizo. El ruido no solo degrada la decisión; oscurece la auditoría.
## Memoria: el conocimiento que sobrevive a la sesión
Un agente sin memoria es como un colega brillante con amnesia anterógrada: cada mañana le tenés que volver a explicar el proyecto. Funciona para una tarea, pero no construye nada acumulativo.
La solución que se impuso es deliciosamente de baja tecnología: **memoria basada en archivos**. Un directorio de notas en markdown, una por hecho, con un índice que se carga al inicio de cada sesión. No hace falta una base vectorial ni un grafo de conocimiento elaborado para empezar; hace falta disciplina sobre *qué* guardar.
Y ahí está el arte. La tentación es guardar todo. Pero la memoria útil no es un log de la conversación: es el **conocimiento no derivable**. La estructura del código ya vive en el código. El historial vive en git. Lo que vale la pena persistir es lo otro:
- la decisión que tomaste y *por qué* descartaste la alternativa,
- el gotcha de infraestructura que te costó tres horas descubrir,
- la preferencia del equipo que no está escrita en ningún lado,
- la corrección que te hizo el humano y que no querés repetir.
Una buena memoria de agente se parece menos a una base de datos y más a las notas de alguien que de verdad presta atención. Cuando esa memoria se enlaza —una nota apunta a otra, se actualiza la vieja en vez de duplicarla, se borra la que resultó falsa— deja de ser un cajón y se vuelve **conocimiento institucional vivo**. Y vuelve trazable el *por qué*: no solo qué sabía el agente, sino de dónde lo sacó.
## Orquestación multi-agente: fan-out y verificación adversarial
Acá es donde el estado del arte se pone interesante de verdad, y también donde más humo hay.
La idea es simple: en vez de un agente haciendo todo en serie, lanzás *muchos* en paralelo. Diez agentes revisando diez archivos a la vez. Cinco escépticos tratando de refutar un mismo hallazgo. Un panel de jueces puntuando tres soluciones distintas al mismo problema. Es un cambio de escala que un solo contexto no puede sostener: cada agente trae su conclusión y vos te quedás con la síntesis.
Dos patrones que mejoran la calidad más que cualquier otro:
**Verificación adversarial.** No le preguntes a un agente "¿esto está bien?". Lanzá tres con la consigna explícita de *refutarlo*, y matá el hallazgo si la mayoría lo tumba. Los modelos son complacientes por diseño; un hallazgo "plausible pero falso" sobrevive a una sola revisión amable y muere frente a tres escépticos. La diversidad de perspectivas —uno mira corrección, otro seguridad, otro si realmente reproduce— atrapa fallas que la redundancia no.
**Loop hasta secar.** Para descubrir cosas de tamaño desconocido —bugs, edge cases, deuda— no sirve un contador fijo de "buscá diez". Seguí lanzando buscadores hasta que dos rondas seguidas no traigan nada nuevo. La cola larga de problemas vive justo donde el contador arbitrario corta.
Estos patrones son poderosos. Pero noten qué tienen los dos en común: existen para *aumentar la confianza* en un resultado, no para producirlo más rápido. Otra vez la misma tesis. El trabajo difícil ya no es generar candidatos; es decidir en cuáles creer.
## Lo que la evidencia mostró (y no era lo que creíamos)
Construir las herramientas de observabilidad fue, en buena medida, descubrir cuántas de nuestras certezas no resistían los datos. Algunas distinciones que solo aparecen cuando dejás de creerle al diagrama y empezás a mirar la traza:
**Mencionar agentes no es usarlos.** Un sistema puede declarar que tiene cinco agentes y, en la traza, mostrar que cuatro nunca se invocaron o que sus salidas no alimentaron ninguna decisión posterior. El organigrama existe; la organización, no.
**Delegación real versus roleplay.** Un agente puede "delegar" en otro de una forma que, mirada de cerca, es un solo modelo conversando consigo mismo en distintos tonos. No hay frontera de contexto, no hay aislamiento, no hay independencia: hay un monólogo con sombreros distintos. Se ve sofisticado y no aporta lo que la delegación debería aportar —perspectivas que no se contaminan entre sí.
**Paralelismo real versus secuencia disfrazada.** "Cinco agentes en paralelo" suena impecable hasta que los timestamps muestran que arrancaron uno después del otro. La etiqueta dice concurrencia; la evidencia dice fila india.
**Claims del sistema versus evidencia observable.** Esta es la madre de todas. Un sistema multi-agente reporta su propia actividad, y ese reporte es un *claim*, no un hecho. Muchas veces los sistemas reportan múltiples agentes coordinándose, y la traza muestra que no hubo coordinación efectiva: hubo agentes corriendo cerca, sin que las decisiones de uno influyeran en las del otro.
La conclusión práctica fue incómoda y clarificadora a la vez: **es facilísimo confundir una lista de menciones con orquestación real.** Que tu diagrama muestre agentes con flechas no significa que haya coordinación; a veces es teatro. La orquestación de verdad —dependencias reales, barreras donde hacen falta, paralelismo donde conviene— es trabajo de diseño deliberado, no un emergente mágico de tirar agentes a un problema. Distinguir una cosa de la otra, en tus propios sistemas y con evidencia en la mano, es media batalla.
## La observabilidad de agentes es observabilidad, nada más nuevo
Conviene bajar esto a tierra conocida, porque no es una disciplina caída del cielo: es la evolución natural de algo que los que venimos de sistemas distribuidos ya sabíamos hacer.
Durante años, frente a un sistema complejo, preguntábamos:
- ¿Qué servicio falló?
- ¿Qué request produjo el error?
- ¿Qué dependencia generó la latencia?
Frente a una flota de agentes, las preguntas cambian de objeto pero no de naturaleza:
- ¿Qué agente tomó la decisión?
- ¿Por qué la tomó?
- ¿Qué contexto tenía cargado en ese momento?
- ¿Qué evidencia tenía disponible cuando decidió?
La necesidad es exactamente la misma de siempre: entender un sistema complejo que no podés sostener entero en la cabeza. Lo que cambia es que ahora una de las "dependencias" toma decisiones no deterministas, y que el "log" tiene que capturar no solo qué pasó, sino *por qué el modelo creyó que correspondía*. Es traza distribuida con una capa de intención encima. Quien ya pensó en spans, correlación y causalidad tiene casi todo el andamiaje mental; solo falta extenderlo a un actor que razona.
## La parte que nadie te pone en el demo
Los videos de "el agente construyó la app solo" son reales, pero están editados —si no en el corte, en la elección del problema. La realidad cotidiana incluye fricciones que ningún hilo viral menciona:
- El agente arregla el código perfecto, pero el deploy falla por un drift de infraestructura que no tiene nada que ver con lo que tocó.
- Resuelve el bug de la capa de aplicación e ignora que la causa raíz era una decisión de arquitectura tres niveles más abajo.
- Te entrega algo que *parece* correcto, compila, pasa los tests… y está sutilmente mal de una forma que solo ves corriendo la app de verdad.
Por eso el principio operativo no es "confiar en el agente". Es **confiar pero verificar**, y en sistemas serios el peso cae sobre "verificar". Correr la app y mirar el comportamiento real vale más que diez tests verdes. La trazabilidad —saber exactamente qué versión, qué commit, qué decisión generó cada cosa— deja de ser burocracia y se vuelve la única forma de auditar algo que produce mucho y rápido.
El agente no reemplaza el criterio de ingeniería. Lo *amplifica*. Y amplificar mal criterio también es un riesgo.
## Decisiones que alinean humanos y máquinas
Un descubrimiento lateral, casi filosófico: las prácticas que hacen a un agente más efectivo son las mismas que hacen a un equipo humano más efectivo.
Los **registros de decisiones de arquitectura** —esos documentos cortos donde escribís "decidimos A en vez de B por estas razones"— resultaron ser uno de los mejores insumos para un agente. No porque la IA los necesite especialmente, sino porque capturan la *intención* detrás del código, y la intención es justamente lo que no se infiere leyendo los archivos. Un agente que lee tus decisiones antes de tocar nada se comporta como un colega que se puso al día, en vez de como un mercenario que adivina.
Lo mismo con los comentarios mínimos pero precisos, los nombres que explican, las convenciones consistentes. Escribir código que se lee como prosa —algo que siempre fue buena práctica— ahora tiene un segundo beneficiario: la máquina que va a colaborar sobre ese código mañana. Las dos audiencias quieren lo mismo. La IA agéntica, sin querer, premia la prolijidad que siempre debimos tener. Y la prolijidad, otra vez, es lo que hace verificable el resultado.
## Cierre
Durante décadas el cuello de botella del software fue la velocidad para producirlo. Escribíamos despacio, revisábamos lo que escribíamos, y el límite era cuánto podíamos teclear con criterio. Ese límite se corrió.
Hoy podemos generar más software del que podemos verificar. Y cuando la generación deja de ser escasa, lo escaso pasa a ser otra cosa: la confianza. El cuello de botella se mudó de "¿puedo construir esto?" a "¿puedo confiar en lo que se construyó?".
Los agentes pueden ejecutar. Los modelos pueden generar. Pero entender el sistema —saber qué está bien, por qué, y con qué evidencia— sigue siendo trabajo humano, y no parece que vaya a dejar de serlo pronto. Esa capacidad de dirigir, observar y validar es, probablemente, la habilidad que más valor va a ganar en los próximos años.
El agente ejecuta. El criterio sigue siendo tuyo. Esa, por ahora, es la frontera —y conviene mirarla con la traza en la mano, no con el diagrama.