Cuándo NO usar multiagente

Al terminar esta lección podrás mirar un problema y decir, con argumentos, si necesita varios agentes o si basta con uno (o con un Workflow sin agente). Sabrás qué pagas al multiplicar agentes y qué señales indican que el pago compensa.

La idea

Un sistema multiagente es un programa donde un modelo, el Orquestador, delega partes del trabajo en otros agentes, los subagentes, que tienen su propio contexto, sus propias herramientas y su propio bucle. Suena a dividir y vencer. En la práctica es una forma cara de comprar dos cosas concretas: contextos separados y trabajo en paralelo. Si tu problema no necesita ninguna de las dos, solo compras complejidad.

La recomendación de Anthropic en Building effective agents va en la misma línea: empieza por la solución más simple que funcione y añade complejidad solo cuando demuestre que mejora el resultado. Esa escalera la tienes en Workflows frente a agentes. Multiagente es el último peldaño.

flowchart TD
  A[Problema] --> B{¿Pasos fijos y conocidos?}
  B -- Sí --> W[Workflow]
  B -- No --> C{¿Cabe en un contexto y es secuencial?}
  C -- Sí --> U[Un agente]
  C -- No --> D{¿Partes independientes?}
  D -- Sí --> M[Multiagente]
  D -- No --> U2[Un agente con compactación]

Lo que pagas

Tokens

Cada subagente arranca con su propio Prompt de sistema, sus definiciones de herramientas y la tarea. Luego hace sus búsquedas, lee resultados y razona. Todo eso son tokens de entrada y salida que no existirían con un solo agente. Además, el orquestador lee después lo que devuelven todos. Anthropic contó en How we built our multi-agent research system que su sistema consumía muchos más tokens que un chat normal y que solo compensa en tareas cuyo valor justifica ese gasto. Lo verás con números propios en El coste de multiplicar agentes.

Coordinación

El orquestador tiene que dividir bien la tarea. Si la divide mal, dos subagentes buscan lo mismo, o ninguno busca lo importante, o cada uno asume algo distinto sobre el formato. Con un agente esos errores no existen porque todo el razonamiento ocurre en un mismo contexto.

Pérdida de información

El subagente no ve la conversación del orquestador. Solo sabe lo que le escribes en la tarea. Y el orquestador solo ve lo que el subagente devuelve, no lo que descubrió por el camino. Cada frontera entre agentes es un punto donde se pierde contexto. Lo tratamos en Pasar contexto entre agentes.

Depuración

Una traza de un agente es una secuencia. Una traza multiagente es un árbol con ramas que corren a la vez. Cuando la respuesta final está mal, tienes que averiguar si falló la división, un subagente concreto o la síntesis. Necesitas IDs que relacionen cada llamada con su padre, algo que verás en Observabilidad y trazas.

Latencia, en ambos sentidos

El paralelismo reduce el tiempo de pared si las partes son independientes. Pero añades al menos dos pasos secuenciales (planificar y sintetizar), y el conjunto tarda lo que tarde el subagente más lento. Para tareas cortas, un agente solo suele terminar antes.

Cuándo sí compensa

Las señales que justifican varios agentes son pocas y concretas:

• La tarea se divide en partes independientes. Investigar cinco competidores, revisar diez archivos que no dependen entre sí, buscar en tres fuentes distintas. Si la parte B necesita el resultado de la A, no hay paralelismo real.
• El contexto no cabe junto o se ensucia. Cada parte genera mucho material intermedio (páginas leídas, resultados de búsqueda) que el resto no necesita. Un subagente lo procesa en su Ventana de contexto y devuelve un resumen corto. Así el orquestador trabaja con contexto limpio.
• Las partes piden herramientas o instrucciones distintas. Un subagente que solo consulta la base de datos y otro que solo busca en la web, cada uno con su prompt y sus herramientas, son más fáciles de afinar que un agente con todas.
• El valor de la respuesta justifica el gasto. Un informe que alguien va a usar para decidir algo caro aguanta multiplicar el coste. Una respuesta de soporte de nivel uno, no.

Si tu caso no cumple al menos las dos primeras, casi seguro que un solo agente bien hecho gana.

Alternativas antes de multiplicar agentes

Muchos problemas que parecen pedir multiagente se resuelven con algo más simple:

Síntoma	Antes de multiagente, prueba
El contexto crece demasiado en tareas largas	Compactación o resumir resultados de herramientas antes de añadirlos
Hay que hacer varias llamadas independientes	Paralelizar llamadas en un workflow (Paralelización), sin bucle agéntico
Tipos de petición muy distintos	Enrutado a prompts especializados
El agente se equivoca a menudo	Mejores herramientas y descripciones (Diseño de herramientas) y evals
Necesitas revisar la calidad	Evaluador-optimizador con un criterio claro

Fíjate en la cuarta fila. Si un agente falla, repartir su trabajo entre varios agentes suele repartir también el fallo. Arregla primero la causa.

Lista de decisión

Responde por escrito antes de construir:

1. ¿Puedo enumerar las subtareas y son independientes entre sí?
2. ¿Cada subtarea genera material intermedio que el resto no necesita?
3. ¿Tengo una versión con un agente que funciona y una medida de su calidad?
4. ¿Cuánto vale una respuesta buena y cuánto estoy dispuesto a pagar por ella?
5. ¿Sé cómo depuraré un fallo en un subagente concreto?

Sin un «sí» en la 3, no tienes con qué comparar. Construye primero el agente único y mídelo con lo que verás en Nivel 80 · Evals.

Errores frecuentes

• Empezar por la arquitectura multiagente porque parece más completa.
• Dividir la tarea en partes que dependen unas de otras y luego coordinarlas con mensajes.
• Comparar el sistema multiagente con un agente único mal configurado.
• No contar los tokens del orquestador y de la síntesis al estimar el coste.

Ejercicio

EjercicioPistas

El manual cabe en el contexto y la tarea es secuencial. Los proveedores son independientes y cada web genera mucho texto que la comparación final no necesita. Clasificar tickets tiene pasos fijos: piensa en enrutado.

Resumen

• Multiagente compra contextos separados y trabajo en paralelo. Si no necesitas eso, solo compras complejidad.
• Pagas en tokens, coordinación, pérdida de información entre agentes y depuración más difícil.
• Compensa cuando las subtareas son independientes, generan mucho material intermedio y el valor de la respuesta justifica el gasto.
• Antes de multiplicar agentes, prueba compactación, paralelización simple o enrutado.
• Sin un agente único medido, no tienes con qué comparar.

Para seguir

• Orquestador y subagentes
• Qué patrón elegir
• Arquitecturas multiagente