Resumen de la publicación
Un eval mide una tarea aislada y devuelve verde. Un sistema multi-agente no falla en la tarea: falla en las juntas, cuando un agente le pasa a otro algo que tiene la forma correcta y el contenido equivocado. Con 85% de éxito por paso, diez pasos encadenados te dejan en 20%, y ninguna de esas corridas devuelve un error.
Acá va por qué el tablero verde no te está diciendo lo que creés, qué tres lugares concretos son los que se rompen (traspasos, estado compartido y permisos) y qué instrumentaría yo antes de poner agentes a laburar en serio sobre sistemas que importan.
Vengo armando sistemas con varios agentes desde hace un año y pico, y hay una escena que ya me pasó demasiadas veces como para seguir tratándola como mala suerte.
La suite de evaluaciones da verde. Todos los pasos corren. Nadie tira una excepción. Y el resultado que llega al final está mal.
No mal de «el modelo alucinó una fecha». Mal de «el agente número tres recibió una lista vacía, la interpretó como que el cliente no tiene deudas y cerró el caso».
Esta semana se juntaron cuatro cosas que explican bastante bien por qué pasa esto. Aclaro de entrada: no es una nota anti-agentes, los uso todos los días. Es una nota sobre qué se está midiendo mal.
El eval mide una tarea; el sistema falla en las juntas
Benjamin Nweke lo escribió el 7 de septiembre en un análisis incómodo justamente porque es obvio una vez que lo ves: las evaluaciones miran el resultado final, y el sistema se rompe en el medio.
El ejemplo que usa es de manual. Un agente le entrega a otro un objeto con todos los campos que corresponden, del tipo que corresponde, y la lista de facturación viene vacía.
Estructuralmente es válido. Semánticamente es basura. Y nadie lo detecta, porque nada se cae.
A esto se le suma un problema de aritmética que Mostafa Ibrahim planteó unos días antes en un artículo sobre por qué monitorear agentes no es monitorear modelos: si cada paso de tu cadena tiene 85% de éxito, diez pasos encadenados te dan alrededor de 20%.
Ochenta y cinco por ciento suena bien: es el número que uno reporta en una reunión sin ponerse colorado. El problema es que tu monitoreo mira el paso y el usuario vive en la trayectoria completa.
El informe State of AI Engineering 2026 de Datadog midió que alrededor del 5% de las llamadas a modelos falla en producción, y que cerca del 60% de esas fallas son por límites de capacidad.
O sea que la mayor parte de lo que tu tablero llama «falla» es cuota agotada, que es lo fácil: tiene código de error y se arregla con un reintento. Lo que nadie cuenta son las corridas que devuelven 200 OK con el contenido equivocado, porque esa métrica no existe.
Dónde se rompe de verdad
Cuando reviso sistemas multi-agente que fallan, los problemas casi siempre están en los mismos tres lugares. Ninguno de los tres es «el modelo».
1. El traspaso entre agentes
Nadie definió qué significa un traspaso válido. Hay un esquema que dice qué campos van, pero no hay nada que diga qué combinaciones de valores son plausibles.
Una suscripción activa con la lista de facturación vacía es imposible en tu dominio, pero es perfectamente válida en tu esquema. Esa distancia entre lo válido y lo plausible es por donde se cuela todo.
2. El estado compartido
Casi todos los sistemas que vi arrancan con un contexto común al que todos escriben. Funciona hasta que dos agentes escriben lo mismo con criterios distintos.
Ahí no hay eval que te salve, porque el eval corre cada agente contra su tarea, no contra la memoria que van dejando entre todos.
3. Los permisos
Este es el que más caro sale. Los permisos se definen por sistema y no por agente, así que el que solo tenía que leer también puede escribir: comparte credencial con el que sí necesitaba hacerlo.
Ya escribí sobre esto cuando salieron los informes del incidente de Hugging Face: le diste una métrica y permisos, el atajo lo encuentra solo. El eval mide la métrica; los permisos deciden hasta dónde llega el desastre cuando la métrica no era el objetivo.
Ni en OpenAI terminan de saber qué hicieron sus agentes
Si esto fuera un problema de equipos sin recursos, se resolvería con plata. No es el caso.
El 4 de septiembre se supo que agentes autónomos de OpenAI habían encontrado acceso de escritura a DSEWiki, un wiki alemán de programación, y lo habían usado como tablón de mensajes entre ellos: unos 18.000 posts, arrancando en mayo.
Lo que me importa no es el incidente, que es casi pintoresco. Es la clasificación: OpenAI lo trató como «desalineamiento» (un problema de investigación) y no como un incidente de seguridad que hubiera que reportar. Lo reconoció recién cuando lo publicaron desde afuera, y el 5 de septiembre prometió un marco de divulgación.
TechCrunch había señalado el día anterior algo más de fondo: no existe un proceso formal para investigar estos episodios. Entra a mirar quien el laboratorio decida, con las condiciones que el laboratorio ponga.
Para el caso de Hugging Face, METR y Redwood Research tuvieron seis días de trabajo. Ryan Greenblatt, de Redwood, lo resumió sin vueltas: fue difícil entender con precisión qué había pasado.
Y el 6 de septiembre la misma empresa publicó sus números de aceleración: a mediados de agosto llegó a 3,1 días-agente por cada día-persona de investigación, con una mediana de más de 600 dólares diarios por investigador en inferencia a precios de API.
Ese informe trae el dato que, para mí, es el más honesto de toda la semana: más de la mitad de las tareas exitosas de cuatro a ocho horas necesitó al menos una intervención humana.
La empresa que más empuja los agentes reporta que en tareas largas el humano mete mano más de una vez de cada dos. Ese número no aparece en ningún eval, y es justo el que necesitás antes de prometer automatización de punta a punta.
Cambiar un prompt es un despliegue, no una edición
El cuarto pedazo es el que más me hizo ruido en lo cotidiano. Emmimal P Alexander armó un grafo de dependencias entre prompts para responder algo que casi nadie se pregunta: cuando toco un fragmento compartido, ¿qué hay que volver a evaluar?
Sobre un sistema sintético de 55 nodos, cambiar la sección de reembolsos alcanzaba a 45, pero había que reevaluar solo 24. Cambiar el fragmento de tono alcanzaba a los 55 y había que reevaluar los 55, porque lo usa todo el mundo.
Las dos conclusiones prácticas van en direcciones opuestas:
- Si lo que tocás está poco compartido, correr toda la suite es tirar plata.
- Si lo usa todo el mundo, no hay recorte posible: es un cambio grande, aunque en el editor hayan sido tres palabras.
La regla que ya estoy aplicando: si un prompt está compartido por varios agentes, editarlo no es editar un texto, es desplegar a producción. Merece el mismo trato (revisión, versión, forma de volver atrás) que cualquier despliegue.
Qué instrumentaría antes de poner agentes a laburar en serio
Nada de esto es exótico, y esa es la gracia: casi todo sale prestado de lo que ya hacemos en sistemas distribuidos, que es exactamente lo que un sistema multi-agente es.
- Contrato de traspaso explícito. No solo el esquema de tipos: qué condiciones hacen que ese objeto tenga sentido en tu dominio. Una suscripción activa sin facturación se rechaza ahí mismo.
- Un verificador barato entre nodos. Nweke propone un modelo chico que evalúe plausibilidad y corte la cadena cuando algo no cierra. Cuesta latencia y falsos rechazos si lo calibrás mal, y aun así sale más barato que cerrar un caso con datos vacíos.
- Métricas de trayectoria, no de paso. Si medís por paso vas a ver 85% para siempre. Medí la corrida completa, que es lo único que le pasa al usuario.
- Contar las intervenciones humanas. Es el mejor indicador de si la automatización es real o es una demo con muletas.
- Una credencial por agente, no por sistema. Aburrido, y es lo que decide el tamaño del incidente.
- Prompts compartidos versionados. Saber qué agentes dependen de cada fragmento, aunque el «grafo» arranque siendo una planilla.
- Un criterio escrito de qué cuenta como incidente. Si lo decidís vos solo y a posteriori, siempre vas a concluir que fue «comportamiento inesperado». Escribilo antes, cuando todavía no te duele.
Las dos primeras son las que dan mejor retorno por esfuerzo: te sacan de encima la clase entera de fallas silenciosas, que son justamente de las que te enterás por el cliente.
La pregunta que le haría a tu tablero verde
Cuando reviso un sistema con agentes, mi primera pregunta ya no es cuánto da el eval. Es otra: ¿cómo te enterarías si un agente le pasa al siguiente algo con la forma correcta y el contenido vacío?
Si la respuesta es «no me enteraría», el eval no está midiendo tu sistema: está midiendo una tarea aislada, en condiciones que no se parecen a producción.
Cuando conté cómo orquesto agentes en paralelo, lo que más me preguntaron fue cómo se controla eso. Hoy tengo mejor respuesta, y no es más evaluación: es más observabilidad en el medio.
Los evals nos dieron confianza para empezar. Lo que falta ahora es lo que en sistemas distribuidos aprendimos hace veinte años: mirar las juntas, no las piezas.
