(2/3) Tres arquitecturas de loops agénticos, y lo que cuesta realmente cada una

Pregunta a cinco proveedores qué hace su «sistema multi-agente» y cuatro te describirán un loop único con mejor marketing.

No es una crítica al marketing: es el síntoma de un vacío real en cómo se habla de esto. La primera parte de esta serie defendía que un loop solo es agéntico cuando tiene un trigger y un objetivo que alguien distinto del modelo pueda verificar. Eso es el mínimo. No dice nada sobre cuántos modelos hacen el razonamiento, si corren en secuencia o en paralelo, ni si hay un supervisor leyendo su trabajo antes de que salga. Eso son decisiones de arquitectura, y la suposición habitual —más agentes, más avanzado, estrictamente mejor— es errónea de una forma concreta y medible: la arquitectura es una curva de coste, no una escala de madurez. Elegir la equivocada, o te quema un múltiplo del presupuesto de tokens sin ganar capacidad, o deja capacidad real sobre la mesa para ahorrarte cuatro céntimos.

El loop único: un solo modelo, un solo hilo, sin peaje de coordinación

La arquitectura más sencilla es exactamente la que describía la primera parte: un solo modelo, en ciclos de percibir-razonar-planificar-actuar-observar contra un único objetivo, sin nada más corriendo en paralelo. Es lo que formaliza el patrón ReAct de Yao et al., y es la opción por defecto correcta para cualquier tarea lo bastante acotada como para que un solo hilo de razonamiento pueda mantener toda la tarea a la vista: arreglar un test concreto que falla, responder una pregunta que requiere un par de consultas, trabajar una migración acotada archivo a archivo. No hay peaje de coordinación porque no hay nada que coordinar. El punto de fallo no es el coste; es el alcance. Pasado cierto tamaño de tarea, un solo hilo empieza a perder el hilo de decisiones anteriores, a rededucir cosas que ya había resuelto, o a no notar que dos pasos separados por varios turnos ahora se contradicen.

Planificar y ejecutar: separar decidir qué hacer de hacerlo

La siguiente arquitectura rompe la asunción central del loop único —que razonar y actuar tienen que intercalarse paso a paso— adelantando el razonamiento a un plan explícito, y ejecutando después los pasos de ese plan, en paralelo allá donde no dependen unos de otros. LLMCompiler, de Kim et al. (ICML 2024), es el caso publicado más claro de por qué merece la pena asumir esa complejidad añadida: planificando las llamadas a herramientas como un grafo de dependencias por adelantado, y ejecutando las ramas independientes de forma concurrente en vez de esperar a cada una antes de decidir la siguiente, reportan mejoras de latencia de hasta 3,7 veces y reducciones de coste de hasta 6,7 veces frente a un baseline secuencial al estilo ReAct en su conjunto de benchmarks, con una mejora de precisión añadida, no un intercambio en contra, porque un paso ya no tiene que adivinar qué devolverá un paso anterior antes de poder empezar. El mecanismo es concreto: el trabajo paralelizable no necesita razonamiento secuencial entre cada pieza, y un solo loop intercalado paga un coste de razonamiento por una serialización que no le hacía falta.

El coste de esta arquitectura es la calidad de la planificación previa. Si el plan está mal —una dependencia que el planificador pasó por alto, un paso que en realidad necesitaba la salida de otro— ahora estás depurando un grafo en vez de un rastro lineal, un punto de fallo más difícil de leer que el de un loop único, aunque más raro de encontrar.

Orquestación multi-agente: especialización comprada con una factura de tokens real

La arquitectura más alejada del loop único reparte trozos de una tarea entre distintos agentes: normalmente un agente líder que planifica y delega, y subagentes que hacen cada uno su propio ciclo de percibir-razonar-planificar-actuar-observar sobre una porción del problema, en paralelo, informando al líder. Anthropic publicó cifras exactas sobre el coste de este patrón en su post de ingeniería de junio de 2025 sobre el sistema multi-agente que hay detrás de la capacidad de investigación de Claude: «los agentes usan normalmente unos 4 veces más tokens que las interacciones de chat, y los sistemas multi-agente usan unos 15 veces más que un chat». No es una diferencia de redondeo: es un orden de magnitud, y viene de un mecanismo legible: cada subagente re-deriva su propio contexto y escribe su propio rastro de razonamiento, y el agente líder tiene que leerlo y reconciliarlo todo, así que el mismo terreno se cubre varias veces en vez de una.

El mismo post reporta la otra cara del intercambio: un sistema orchestrator-worker corriendo Claude Opus 4 como líder con subagentes Claude Sonnet 4 superó a un baseline de un solo agente Opus 4 en un 90,2% en su evaluación interna de investigación, y, en un detalle que merece la pena detenerse, el uso de tokens por sí solo explicaba el 80% de la varianza en lo bien que rendía una ejecución, más que la elección de modelo o las herramientas disponibles. La exploración en paralelo de un espacio de problema amplio es una capacidad genuina que la orquestación multi-agente compra y que un loop único estructuralmente no puede ofrecer, porque un solo hilo solo puede seguir una línea de razonamiento a la vez. Tiene un precio de 15 veces, y la cifra del 80% es la pista: la ganancia de capacidad se compra sobre todo con tokens, no con ingenio.

Un cuarto eje, ortogonal a los otros tres: cuánto se esfuerza un solo intento antes de responder

La arquitectura responde «cuántos agentes, dispuestos de qué forma». Una pregunta aparte es cuánto se cuestiona a sí mismo un solo agente su propio resultado antes de dar un paso por terminado, y eso es lo que formalizó Reflexion, de Shinn et al. (NeurIPS 2023): en vez de actualizar los pesos del modelo, el agente escribe una autorreflexión verbal sobre por qué falló un intento, la guarda en una memoria episódica, y vuelve a intentarlo con esa reflexión en el contexto. En HumanEval, esto subió el pass@1 de un baseline de GPT-4 en zero-shot del 80% al 91%, sin tocar el modelo en sí. Esta capa es ortogonal a las tres arquitecturas anteriores: puedes añadir un paso de autocrítica a un loop único, a cada worker de un sistema multi-agente, o a la etapa de ejecución de un pipeline de planificar-y-ejecutar. Compra precisión al precio de más iteraciones por tarea, una factura distinta del peaje de coordinación de añadir agentes.

El 90,2% es real; el 15 también —y solo una forma de tarea se gana los dos

Aquí está la concesión que los pitch decks se saltan: la ganancia de la orquestación multi-agente es real, pero está condicionada a que el trabajo sea paralelo de verdad. Un supervisor coordinando tres subagentes que de todos modos solo podrían haber corrido en secuencia paga el múltiplo entero de 15 veces en tokens y el sobrecoste de coordinación —la reconciliación, la re-derivación de contexto— sin ningún beneficio, porque nunca hubo un espacio de problema amplio que explorar de forma concurrente. La cifra del 90,2% venía de una tarea de investigación pensada para la amplitud: muchas líneas de indagación independientes, exploradas en paralelo, reconciliadas al final. Una tarea estrecha y secuencial —del tipo que un loop único gestiona bien— no tiene esa estructura que explotar, así que la orquestación multi-agente ahí multiplica el coste sin multiplicar nada más.

Cómo elegiría yo, en orden

1. ¿Puede un solo hilo de razonamiento continuo mantener toda la tarea a la vista? Si sí, empieza con un loop único. Es la arquitectura más barata y la más fácil de depurar, y la mayoría de tareas que reciben el tratamiento «multi-agente» no lo necesitaban.
2. ¿Es el trabajo un conjunto de pasos con una estructura de dependencias clara y mayoritariamente independiente? Si sí, planificar-y-ejecutar es la siguiente opción: tienes el paralelismo sin el peaje de coordinación completo, al precio de acertar el plan de antemano.
3. ¿Requiere la tarea explorar un espacio de problema amplio y desconexo que ningún hilo único podría mantener a la vez? Solo entonces el múltiplo de 15 compra algo que una arquitectura más barata estructuralmente no puede. Si no puedes nombrar la exploración paralela, no estás pagando por capacidad: estás pagando solo el peaje de coordinación.
4. Por separado: ¿importa más la corrección que la latencia en esta tarea? Si sí, añade una capa de autocrítica como la de Reflexion sobre la arquitectura que hayas elegido, y presupuesta las iteraciones extra que cuesta.

Nada de esto sobrevive al contacto con producción sin guardrails

Una arquitectura bien elegida todavía se te puede descontrolar si nada limita hasta dónde llega, cuánto gasta, o qué puede hacer sin que un humano lo haya mirado antes, que es donde retoma el hilo la tercera parte de esta serie.

Si estás valorando cuál de estas encaja con un sistema que estás construyendo, contáctanos.