Un agente con buen contexto supera a un enjambre: por qué los traspasos rompen el código multiagente

Siete agentes, una función borrada

Un orquestador lanzó siete agentes. Seis escribieron la misma función y el séptimo la borró. Aquí va el diff recortado, porque verlo es mejor que que te lo cuenten:

+ def limit(req):            agents/a2.py
+ def rate_limit(req):       agents/a3.py
+ def check_limit(r):        agents/a4.py
+ def limiter(request):      agents/a5.py
+ def apply_limit(req):      agents/a6.py
+ def limit(req):            agents/a7.py
- def limit(req):            agents/a7.py  (removed a2's copy)

Son cinco versiones de una función de cuarenta líneas, todas razonables por separado y ninguna consciente de que existían las demás. Luego un séptimo agente detectó un nombre duplicado, hizo lo responsable y eliminó justo la versión que importaba todo lo demás. Ver aquello desfilar por la pantalla mientras se quemaba dinero de verdad no provocó frustración, sino vergüenza: la máquina más cara imaginable acababa de construir una carpeta que no compila, siguiendo un diagrama de arquitectura del que alguien estaba orgulloso.

Si alguna vez has dibujado cajas con las etiquetas Planner, Coder, Reviewer y Tester y has sentido un pequeño orgullo por estar diseñando algo serio, esto va contigo.

La aritmética que falta en las diapositivas

Toma un agente que acierta el 95 por ciento de las veces, que ya es uno bueno de verdad. Encadena cinco y mira lo que pasa. El bucle tarda cuatro segundos:

p = 0.95
for n in range(1, 6):
    print(n, round(p**n, 2))

1 0.95
2 0.9
3 0.86
4 0.81
5 0.77

Un sobresaliente se convirtió en un aprobado raspado, y la factura es cinco veces mayor. Hay charlas de sobra sobre orquestación de agentes, pero este pequeño bucle rara vez aparece en una diapositiva.

Los traspasos son donde se rompe

Esto fue lo que más tardé en notar. Un agente metido a fondo en un problema arrastra una enorme cantidad de estado implícito. Sabe que el middleware de autenticación se sostiene con cinta adhesiva, que la batería de tests exagera la cobertura y que el arreglo obvio ya se probó y lo hizo saltar todo por los aires.

Un traspaso no lleva nada de eso. Lo que se pasa es una nota de quizá trescientos tokens, mil como mucho, y el resto desaparece cuando termina el proceso. Así que el segundo agente no trabaja con lo que sabía el primero, sino con un resumen, y toma decisiones estructurales sobre ese resto comprimido.

FIVE AGENTS

  [A1] --msg--> [A2] --msg--> [A3] --msg--> [A4]
   |             |             |             |
  full          ~300          ~300          ~300
  context       tokens        tokens        tokens
   |             |             |             |
  knows         guesses       guesses       guesses

ONE AGENT
   retrieval ---+
   memory    ---+---> [ AGENT ] ---> output
   tools     ---+         ^  |
   compaction---+         |  |
                          +--+
                     one head, one state,
                     nothing lost in transit

El mejor argumento a favor del multiagente

La postura contraria es sólida, así que merece que la escuchemos bien. Primero, la especialización funciona: en una tarea concreta, un agente con un prompt ajustado supera a uno generalista. Segundo, las ventanas son finitas, y cinco ventanas dan cinco veces más espacio. Tercero, un contexto fresco es el único revisor en el que puedes confiar. Un agente que ha gastado sesenta mil tokens convenciéndose de un diseño está mal situado para juzgarlo. Por último, los sistemas de investigación que revisan muchas fuentes a la vez sí superan a los de un solo hilo, y esa ganancia se midió, no se anunció.

Así que paralelizar no está muerto. Simplemente se aplica en la dimensión equivocada.

La lectura se reparte, la escritura no

Contar agentes no es la prueba adecuada. Lo que importa es si las subtareas toman decisiones que tienen que ser coherentes entre sí. La lectura se divide casi gratis, ya sean cuarenta fuentes, cien archivos o seis afirmaciones que verificar, porque nadie se compromete con nada y no hay estado compartido que romper.

Con la escritura pasa lo contrario. Deja que dos agentes elijan por su cuenta la forma de una API y tendrás dos diseños que tienen sentido cada uno y no encajan entre sí. Conciliarlos lleva más tiempo que hacer el trabajo paso a paso.

hits = par([find(q) for q in qs])   # reads fan out
patch = run(req, ctx + hits)        # writes go through one head

En resumen: paraleliza la lectura y canaliza la escritura por un solo sitio. La regla entera cabe en una servilleta.

La parte aburrida es el trabajo de verdad

Lo que de verdad pesa no es "un solo agente", sino un buen contexto, y ese es un trabajo tedioso y poco vistoso:

• una recuperación que encuentre los cuatro archivos correctos, no los veinte primeros por similitud del coseno
• una compactación que aguante una sesión larga
• una memoria que guarde por qué se descartó un enfoque en lugar de lo que se tecleó
• salidas de herramientas con una forma que evite que una sola llamada se trague media ventana

Los organizadores de conferencias no piden charlas sobre estrategias de compactación, así que la gente construye enjambres. Un diagrama de orquestación se entiende de un vistazo, algo que nunca pasará con tres semanas de trabajo sobre el contenido del prompt. Esas tres semanas merecen la pena, y merecen la pena otra vez.

Pruébalo mañana

Registra cada token que entra en la ventana de tu agente durante una sesión completa. Luego relee el registro y estima qué parte tenía que ver con la decisión que el agente realmente debía tomar. En este caso fue menos de un tercio. Habían alimentado a un modelo brillante con una manguera de ruido y luego lo culpaban de no dar en el blanco.