Un equipo afina cada agente de su pipeline hasta que es excelente de forma individual. El agente investigador recupera mejor. El agente escritor produce prosa más limpia. El agente verificador atrapa más errores. Cada cambio se mide, y cada cambio es una mejora. Lanzan a producción — y la tasa de éxito end-to-end del sistema baja. Nadie puede decir qué mejora causó la regresión, porque cada una, evaluada por su cuenta, mejoró las cosas.
Eso no es una paradoja. Es lo que pasa cuando optimizas las partes de un sistema cuyo valor vive en cómo se conectan.
La victoria local que no lo es
En una tarea de un solo prompt, "hacer mejor este prompt" está bien definido: mejor output en la evaluación. En un sistema multiagente, el output de un agente no es el producto — es el input al siguiente agente. Un prompt que hace más exhaustivo el output del investigador puede sepultar el único campo que el escritor realmente necesitaba bajo tres párrafos de contexto. Mejoraste el score del investigador y degradaste el handoff. El sistema empeoró por hacer mejor a cada agente.
Trabajo reciente nombra esto directamente. MASPO lo plantea como el desalineamiento entre los objetivos locales de cada agente y las metas holísticas del sistema, y su solución es dejar de evaluar prompts en aislamiento: cada prompt se evalúa por su capacidad de facilitar el éxito aguas abajo para los agentes que lo consumen — optimización conjunta a través de todo el sistema, no afinamiento agente por agente. MAPRO reformula el mismo problema como inferencia sobre todo el grafo de agentes en lugar de una pila de búsquedas independientes. Matemática distinta, premisa idéntica: el trabajo del prompt es el handoff, no su propio output.
Este es el problema de debugging disfrazado
Si esto suena familiar, debería. Es la misma propiedad que hace difíciles de debuggear a los sistemas multiagente — las fallas viven en el espacio entre los agentes, no dentro de ninguno de ellos. Una vista plana, por agente — un log, o un score de evaluación por agente — te da quince afirmaciones verdaderas que no suman el comportamiento del sistema.
Las victorias viven en el mismo lugar que las fallas. Lo que significa que el corolario es inevitable: si no puedes ver el handoff, no puedes optimizarlo. Necesitas el trace de toda la trayectoria, no un scorecard por nodo.
Qué significa esto para cómo construyes
- Evalúa el sistema end-to-end. La evaluación que bloquea es la del éxito de la tarea, la que tiene permiso de detener un release — no la de la calidad de los componentes. Un score por agente más alto que baja el éxito end-to-end es una regresión, punto.
- Trata el cambio de prompt de un agente como un cambio de sistema. El radio de impacto es el grafo, no el nodo. Vuelve a correr la evaluación del sistema, porque una edición local puede romper una suposición aguas abajo que nunca escribiste.
- Desconfía de "optimizamos los prompts." Pregunta qué se midió. El afinamiento agente por agente que nunca evaluó el handoff está optimizando costuras hasta hacerlas existir.
La unidad de calidad en un sistema de agentes es la trayectoria, no el paso. Optimiza el paso y puedes afilar un cuchillo mientras lo apuntas en la dirección equivocada. Optimiza la trayectoria — evalúa cada prompt por si prepara al siguiente agente para tener éxito — y las mejoras por fin componen en vez de cancelarse.