← números anteriores

19 de agosto de 2026

Sistemas multiagente: cuándo (no) dividir el problema entre varios LLMs

Sistemas multiagente: cuándo (no) dividir el problema entre varios LLMs

"Multiagente" suena a la evolución natural de un agente: si uno funciona, tres coordinados deberían ir mejor. En la práctica, la mayoría de los sistemas multiagente que fallan en producción no fallan por el modelo — fallan por el diseño de la coordinación.

Un orquestador reparte subtareas entre agentes especializados y un crítico valida el resultado antes de responder

Por qué el multiagente falla en producción

  • Pérdida de contexto entre agentes. Cada handoff es un resumen con pérdida. Si el agente A no le pasa al B una decisión implícita que tomó, el B la vuelve a tomar — a veces distinta.
  • Coste multiplicado, no sumado. Tres agentes no cuestan 3x un agente: cuestan 3x más las llamadas más las rondas de coordinación (planificar, delegar, revisar), que fácilmente doblan esa cifra.
  • Fallos silenciosos en cadena. Un agente que se equivoca a mitad de pipeline no lanza una excepción: produce un resultado plausible pero incorrecto, y el siguiente agente lo da por bueno.
  • Delegar por delegar. Dividir una tarea en "agentes" cuando en realidad es una secuencia de herramientas deterministas añade indirección sin beneficio: si el flujo no necesita juicio propio en cada paso, no necesita un agente en ese paso.

El patrón que sí funciona: orquestador + especialistas + crítico

  1. Un orquestador, no una conversación en grupo. Un agente (o código determinista) descompone la tarea y decide a quién delega cada subtarea. Los agentes especialistas no se hablan entre sí — todo pasa por el orquestador, que es el único que mantiene el estado global.
  2. Especialistas con contexto acotado. Cada agente recibe solo lo que necesita para su subtarea, no el historial completo. Menos contexto, menos alucinación, menos coste.
  3. Un crítico antes de responder. Un paso final (agente o regla) valida que el resultado combinado responde a la petición original, no solo a las subtareas por separado. Es donde se detecta la mayoría de los fallos en cadena.
const plan = await orchestrator.plan(task); // subtareas + agente asignado

const results = await Promise.all(
  plan.steps.map((step) => specialists[step.agent].run(step.input))
);

const draft = await orchestrator.combine(results);
const review = await critic.check(task, draft);

const finalOutput = review.ok ? draft : await orchestrator.retry(review.feedback);

Cuándo NO necesitas multiagente

Si un solo agente con las herramientas adecuadas y un bucle de razonamiento (ReAct, plan-and-execute) resuelve la tarea, añadir agentes solo introduce más superficie de fallo. La señal de que sí lo necesitas no es "la tarea es compleja" — es que distintas subtareas requieren contextos o roles que interfieren entre sí (por ejemplo, un agente que genera código y otro que lo audita con criterios opuestos). Si no hay ese conflicto de rol, un agente con más herramientas es más simple y más barato que tres coordinados.

La próxima semana: cómo evaluar (con métricas, no a ojo) si tu sistema multiagente está mejorando o solo está costando más.

// no te pierdas el próximo número

ia4dev — suscripción al boletín

$ suscribir --boletin --modulo-gratis --to tu@email.com

sin spam · un email a la semana · baja cuando quieras