Escribir un ensayo decente de un tirón, sin poder borrar, es casi imposible. No porque no sepas escribir, sino porque el proceso normal —redactar, releer, tachar, comprobar una fuente, reordenar, pedir que alguien te lo critique— está prohibido por las reglas del juego. A un modelo en modo zero-shot le pedimos exactamente eso: el ensayo perfecto a la primera, sin retroceso.
De ahí sale toda la arquitectura agéntica. Un loop no es más que devolverle al modelo el derecho a borrar. Y la tesis que hizo famoso a Andrew Ng en 2024 era justo esa: el diseño del flujo importa más que el modelo que lo ejecuta.
Dos años y medio después, la tesis sigue en pie. La evidencia con la que se defendía, no.
La cifra que conviene jubilar
Todo el mundo cita el mismo dato: GPT-3.5 resolvía el 48,1 % de HumanEval en zero-shot, GPT-4 el 67 %, y GPT-3.5 metido en un flujo agéntico llegaba al 95,1 %. La conclusión —la mejora de modelo queda empequeñecida por la mejora de flujo— se ha repetido en mil presentaciones, incluidas algunas mías.
Hay que dejar de usarla. HumanEval está saturado: son 164 funciones de Python de un solo archivo, los modelos frontera se agrupan en el rango del 90 al 98 %, y la contaminación del conjunto de entrenamiento está documentada. Sostener una tesis de 2026 con una regla que ya no mide nada es la mejor forma de que un cliente técnico deje de escucharte en el minuto tres.
Lo interesante es que la evidencia moderna sostiene la tesis mejor. Cuando fijas el modelo y cambias solo el andamiaje —el harness: cómo troceas la tarea, qué herramientas expones, qué recuerdas entre pasos— la diferencia de rendimiento es del orden de la que hay entre dos generaciones de modelo. En las mediciones que comparan orquestaciones sobre modelos idénticos aparecen brechas de siete puntos en tareas de investigación y, en comparativas más amplias de frameworks, de hasta treinta.
Traducido a lenguaje de comité de arquitectura: esa varianza es tuya. No la controla tu proveedor de modelo, la controlas tú.
El eje real no son los agentes: es el estado
Los cuatro patrones de Ng —reflexión, uso de herramientas, planificación y colaboración multiagente— siguen siendo el mejor vocabulario disponible, y los cinco flujos que formalizó Anthropic (encadenamiento, enrutado, paralelización, orquestador-trabajadores y evaluador-optimizador) siguen siendo la mejor gramática. Pero se enseñan mal: como un catálogo de recetas del que eliges la que te gusta.
No son recetas. Son etapas en la externalización de la cognición, y todas responden a la misma pregunta: ¿dónde vive el estado y quién paga por transportarlo?
- Loop. El estado vive en la ventana de contexto. Un agente que revisa su propio trabajo. Compacto, barato, perfecto mientras todo quepa.
- Cadena. El estado —el orden— se externaliza al código de tu aplicación. Cada etapa tiene su prompt, su modelo y su validación. Predecible, pero hay que anticipar los casos raros.
- Red. Trabajadores especializados y un orquestador que reparte. Aquí aparece el primer dolor serio: el orquestador se convierte en un centro conversacional que recibe la salida completa de todos.
- Grafo. El estado sale fuera, a una estructura duradera y consultable. Cada trabajador lee el subgrafo que le toca y escribe entidades y relaciones nuevas. El contexto del orquestador se mantiene pequeño porque el estado ya no viaja: se consulta.
No es una escalera de madurez. Muchísimos sistemas deben quedarse en llamada directa o en cadena fija para siempre. Es una secuencia de decisiones, y cada escalón se paga en coste, latencia, no determinismo y superficie de depuración.
Lo que casi nadie contaba en 2024: el contexto se pudre
Si tuviera que señalar el hueco más grande de aquella generación de material sobre agentes, sería este. La disciplina que decide si tu sistema sobrevive a producción ya no se llama prompt engineering. Se llama ingeniería de contexto, y su definición operativa es incómodamente sencilla: curar y mantener el conjunto mínimo de tokens de alta señal en cada inferencia.
El hallazgo que lo cambia todo es que el contexto se degrada antes de llenarse. A medida que crecen los tokens en la ventana, la capacidad del modelo para recuperar información con precisión baja. No hace falta llegar al límite duro: cada token adicional rinde menos. Un agente que en el paso 47 arrastra el residuo de los pasos 1 al 46 decide peor que uno que arranca con un resumen curado de ochocientos tokens.
Hay un corolario que duele especialmente en proyectos empresariales: las definiciones de herramientas también son contexto. Un esquema complejo se come quinientos tokens; conectas unos cuantos servidores MCP y te encuentras con decenas de miles de tokens de definiciones consumidos antes de que el modelo empiece a razonar. Por eso la recomendación práctica no pasa de unas veinte herramientas por agente, con degradación observable bastante antes.
Las tres soluciones que ha traído 2026 son la misma idea con tres envoltorios distintos —divulgación progresiva—: cargar catálogos de herramientas bajo demanda, empaquetar flujos repetibles como skills de los que solo se lee la metadata hasta que hacen falta, y dejar que el agente escriba código que llama a las herramientas para que los datos intermedios no pasen por su contexto. Las reducciones reportadas van del 78 % al 98 % de tokens de entrada. No es una optimización: es la diferencia entre un agente que razona y uno que solo administra su propio inventario.
El debate de las veinticuatro horas
En junio de 2025, con un día de diferencia, Cognition publicó Don’t Build Multi-Agents y Anthropic contó cómo había construido su sistema multiagente de investigación. Titulares opuestos, misma preocupación de fondo: el contexto.
Cognition trabaja en código: dependencias apretadas, decisiones acopladas, un solo artefacto. Ahí los subagentes paralelos toman decisiones independientes con información parcial y el resultado es frágil. Anthropic trabaja en investigación: hilos naturalmente independientes. Sus subagentes reciben una tarea autocontenida, un formato de salida y una ventana limpia; no saben que existen los demás. Ese aislamiento es justamente el mecanismo, y les compra una mejora del 90 % sobre el agente único en su evaluación interna, a cambio de unas quince veces más tokens.
Los dos tienen razón dentro de su dominio. La tarea elige la arquitectura, no al revés: ancho y superficial va a multiagente; profundo y estrecho va a un solo agente con contexto continuo.
La síntesis a la que ha llegado el campo es estrecha y muy concreta: un orquestador que conserva el contexto continuo y genera subagentes efímeros, de solo lectura, que devuelven resúmenes comprimidos. Los enjambres de agentes escribiendo en paralelo sobre el mismo artefacto siguen siendo frágiles. Si tu diseño tiene varios agentes escribiendo a la vez sobre lo mismo, ya sabes por dónde va a romper.
Y un criterio que agradecerás en la conversación de presupuesto: el multiagente solo tiene sentido cuando el valor de la tarea justifica el sobrecoste. Un factor quince en tokens no se amortiza en soporte de primer nivel. Sí puede amortizarse en una due diligence.
Los fallos no son de inteligencia
Existe desde 2025 una taxonomía empírica de por qué fallan los sistemas multiagente, construida sobre más de mil seiscientas trazas de ejecución anotadas de siete frameworks distintos. Catorce modos de fallo en tres categorías: problemas de especificación y diseño, desalineación entre agentes y verificación insuficiente. Aproximadamente cuatro de cada diez fallos vienen de especificaciones malas, casi cuatro de coordinación rota y dos de verificación débil.
La conclusión de los autores es la que más incomoda: mejorar el modelo base no basta para cubrir la taxonomía. Estos no son fallos de inteligencia, son fallos de ingeniería de sistemas distribuidos. Escribir especificaciones verificables, imponer comunicación estructurada, añadir validación independiente, instrumentar todo. Nada de eso sale en una demo.
Hay un dato que me parece decisivo para elegir topología: los sistemas multiagente sin coordinación amplifican errores hasta diecisiete veces, mientras que las arquitecturas centralizadas con una puerta de validación contienen la amplificación en torno a cuatro. Es un argumento cuantitativo a favor del orquestador con verificación frente al enjambre.
El grafo, y por qué no es verdad automática
El grafo aparece cuando el estado debe sobrevivir a la sesión. Hace tres cosas distintas, y conviene no confundirlas: es memoria compartida para que el orquestador no se ahogue, es capa de fundamentación para que el evaluador pueda decir «la tripleta (X, trabaja_en, Y) no existe» en lugar de «esto no me suena bien», y es modelo del mundo persistente para los loops largos. El agente olvida; el grafo no.
Un esquema mínimo aguanta sorprendentemente bien: entidades, afirmaciones, fuentes, artefactos y ejecuciones, con aristas de menciona, apoya, contradice, deriva_de y sustituye. La regla de oro es que la escritura sea aditiva. No sobrescribas una afirmación: crea una versión nueva y enlázala. No borres evidencia contradictoria: conserva las dos y adjunta una evaluación. Eso es lo que convierte un sistema de larga duración en algo auditable.
Dos matices técnicos que hoy sí están resueltos y hace dos años no. El primero, la bitemporalidad: las implementaciones serias de grafos temporales guardan en cada arista cuándo fue cierto el hecho y cuándo lo observó el agente, lo que permite manejar hechos contradictorios o actualizados sin perder información. El segundo, la latencia: el GraphRAG clásico, con detección de comunidades y resúmenes precomputados por LLM, es excelente para corpus estáticos e inviable como memoria de agente, porque cada actualización dispara recomputación y la síntesis tarda decenas de segundos. Lo que funciona en producción es recuperación híbrida —búsqueda léxica, embeddings y travesía del grafo, sin llamadas a modelo en el momento de leer.
Ahora la parte que casi nunca se dice en las presentaciones de arquitectura: un grafo preserva errores con la misma eficacia que hechos. La resolución de entidades puede fusionar dos organizaciones distintas. La extracción puede colgar la fecha equivocada. Un evaluador confiado puede marcar como suficiente una fuente débil. Sin validación de esquema, identificadores canónicos, procedencia, representación explícita del conflicto y revisión periódica, lo que has construido no es una memoria: es un almacén de convicciones equivocadas con muy buena latencia.
La frase que uso como test
Cuando reviso una arquitectura agéntica, lo primero que compruebo es si esta frase es verdadera:
Toda salida importante debe poder trazarse hasta una tarea, un plan, un artefacto, una fuente, una decisión de evaluador y un registro de ejecución acotado.
Cuando es falsa, añadir autonomía solo añade incertidumbre. Cuando es verdadera, loops, herramientas, planes, trabajadores y grafos se comportan como piezas de ingeniería componibles y no como comportamiento opaco.
Y falta una capa que rara vez se pone en el diagrama. Si los cuatro patrones son el vocabulario, los cinco flujos la gramática y el grafo el idioma, las evaluaciones son la ortografía: lo aburrido, lo que nadie presume de dominar, y lo único que distingue un texto legible de uno que solo parece decir algo. El propio Ng lo repite en su material reciente: tras trabajar con muchos equipos, el mayor predictor de que alguien ejecute bien no es su nivel técnico, sino su capacidad de sostener un proceso disciplinado de evaluación y análisis de errores.
El camino de los loops a los grafos no va de lo simple a lo complejo. Va de estado implícito a estado explícito, de memoria volátil a memoria duradera, y de estimación a evidencia. Todo lo demás es decoración.
Referencias principales: A. Ng, «What’s Next for AI Agentic Workflows» (Sequoia AI Ascent, 2024) y la serie «Agentic Design Patterns» (The Batch, 2024) · E. Schluntz y B. Zhang, «Building Effective Agents» (Anthropic, 2024) · Anthropic, «Effective context engineering for AI agents» (2025) · W. Yan, «Don’t Build Multi-Agents» (Cognition, 2025) · Anthropic, «How we built our multi-agent research system» (2025) · M. Cemri et al., «Why Do Multi-Agent LLM Systems Fail?» — taxonomía MAST (NeurIPS 2025) · P. Rasmussen et al., «Zep: a temporal knowledge graph architecture for agent memory» (2025).
Deja una respuesta