Flujos multiagente en la práctica

La idea suena bien en una pizarra: un agente planifica, otro ejecuta, otro revisa. En la práctica, cada frontera entre agentes es un punto donde se pierde contexto, se acumula latencia y se multiplica el coste. Aquí va lo que hemos aprendido montando estos sistemas.

Cuándo tiene sentido más de un agente

• Aislamiento de contexto: una subtarea larga y ruidosa que no debe contaminar el hilo principal.
• Herramientas o permisos distintos: el agente que lee la base de datos no necesita desplegar.
• Paralelismo real: tres búsquedas independientes que no dependen entre sí.
• Especialización con evaluación propia: un revisor con su propio conjunto de pruebas.

Cuándo no

Si la tarea cabe en un solo contexto y es secuencial, un único agente casi siempre gana: menos latencia, menos coste, menos superficie de fallo.

Patrones que funcionan

1. Orquestador y trabajadores. Un coordinador reparte subtareas acotadas y ensambla resultados. Los trabajadores no se hablan entre sí.
2. Productor y crítico. Uno genera, otro evalúa contra criterios explícitos y devuelve correcciones. Límite de iteraciones obligatorio.
3. Enrutador. Un clasificador barato decide qué agente especializado atiende cada petición.
4. Pipeline con checkpoints. Cada etapa valida su entrada y puede rechazarla antes de gastar tokens.

Cada traspaso entre agentes debe justificar su coste. Si no puedes explicar por qué esa frontera existe, probablemente sobra.

Lo que más nos costó

El problema recurrente es la pérdida de contexto en el traspaso. El orquestador resume, el trabajador recibe el resumen y le faltan tres detalles que resultan críticos. Nuestra mitigación es despachar cada subtarea con un contrato explícito, no con prosa libre:

agent dispatch \
  --role worker \
  --goal "Validar el esquema del archivo config.yaml" \
  --inputs ./config.yaml,./schema.json \
  --done-when "salida JSON con {valid: bool, errors: []}" \
  --budget-tokens 8000

El campo --done-when es el que más fallos evitó: obliga a definir el criterio de éxito antes de arrancar.

Coste real, con números

En un flujo productor-crítico con tres iteraciones, cada ciclo puede consumir tanto contexto como la tarea original. Un trabajo que un agente resolvería en 20.000 tokens acaba costando 90.000 repartidos entre cuatro llamadas. Si el resultado es apenas mejor, no compensa. Medimos siempre la relación entre calidad ganada y tokens gastados antes de dejar un patrón multiagente en producción.

Consejos operativos

• Pon un presupuesto de tokens y de tiempo por agente; sin techo, un bucle productor-crítico puede arder solo.
• Registra cada traspaso con su entrada y su salida. La depuración de sistemas multiagente es imposible sin esa traza.
• Falla rápido: si un trabajador no cumple el contrato en dos intentos, escala a un humano.
• Versiona los prompts de cada rol por separado y evalúalos por separado.

Conclusión

Los sistemas multiagente no son magia ni el futuro inevitable de todo. Son una herramienta de arquitectura con costes concretos: latencia, dinero y complejidad de depuración. Úsalos cuando el aislamiento o el paralelismo lo justifiquen, define contratos estrictos en cada frontera y mide si el conjunto entrega más de lo que un solo agente bien equipado haría. Muchas veces la respuesta honesta es empezar con uno.