---
title: "Orquestador-agente: control emergente"
description: "Por qué el motor de ALLAN no declara su topología de ejecución sino que la deja emerger de las llamadas a herramientas del modelo, qué literatura sostiene esa decisión, qué literatura la incomoda y qué queda sin construir."
allan.topic: foundation
allan.service: allan-server
allan.date: 08/04/2026
allan.fuente: [Platform Server/internal/agents/swarm_loop_v3.go, Platform Server/internal/agents/watchdog.go, Platform Server/internal/agents/swarm_skills.go, Platform Server/internal/flows/types.go, Platform Server/internal/flows/validate.go, Platform Server/internal/app/app.go, docs/arquitectura/swarm-v3-execution-contract-redesign.md, docs/arquitectura/intelligent-wait-supervision-design.md]
allan.audiencia: [desarrollador]
allan.madurez: asentado
---

Un motor agéntico tiene que ejecutar un proceso cuya estructura de control no se
conoce antes de empezar. Enunciado con precisión: la *topología de ejecución* de
un encargo —quiénes participan, en qué orden, qué depende de qué y quién decide
el paso siguiente— es una función del contenido del encargo, y ese contenido
solo se entiende del todo mientras se resuelve. Saludar y auditar doscientas
oportunidades de un CRM llegan por el mismo canal, con la misma forma
sintáctica, y no comparten ninguna estructura de control razonable.

De ahí salen dos maneras de construir un motor, y son incompatibles. La primera
declara la topología: un grafo de estados, un DAG de pasos, una retícula de
roles. Se puede verificar antes de ejecutar, se puede dibujar, se puede
auditar. La segunda no la declara: fija un espacio de acciones, entrega el
control a un modelo y deja que la topología *emerja* de las llamadas a
herramientas que ese modelo decide hacer. Se puede observar después, y solo
después.

ALLAN eligió la segunda. Este ensayo explica el motivo, qué sostiene la
literatura y qué no, y qué parte de la factura sigue impagada.

## Lo que el motor no declara

Un solo agente raíz es dueño del encargo de punta a punta y lo conduce a base de
llamadas a herramientas: «a single root agent owns the run end-to-end and drives
everything through tool calls» (`internal/agents/swarm_loop_v3.go:24-26`). No hay
retícula de roles alrededor del modelo, y esa ausencia es el diseño, no una
carencia. De ella salen tres propiedades que el código enuncia una a una.

El paralelismo se expresa, no se declara: «Parallel fan-out is expressed
naturally — the root emits several allan.swarm/spawn calls in one turn and the
workers execute concurrently» (`:26-28`). La revisión aconseja, no veta: «review
is advisory instead of a mechanical veto» (`:29-30`). Y agotar el presupuesto no
mata el encargo: «an exhausted budget triggers a best-effort wrap-up rather than
a failed run with no output» (`:30-31`). Lo ya pagado se entrega.

La consecuencia está *aplicada*, no solo escrita. El normalizador de objetivos de
flow colapsa sobre el root todo nombre que designe coordinación del trabajo
—`planner`, `evaluator`, `synthesizer`, `supervisor`, `verifier`— porque es el
root quien coordina (`internal/flows/validate.go:153-165`). Un documento que
nombre una retícula de roles no obtiene una retícula: obtiene el root.

## El nombre clásico de lo que hace el root

Un orquestador que además es agente no es una novedad conceptual, es un
**nivel meta**. El vocabulario lo fijaron Russell y Wefald, que describen
«a general approach to the study of formalized metareasoning, not in the sense
of explicating the semantics of explicitly specified meta-level control
policies, but in the sense of providing a basis for selecting and justifying
computational actions», y desarrollan «a general formula for the utility of
computations, this utility being derived directly from the ability of
computations to affect an agent's external actions».

La distinción de esa primera frase es exactamente la que decide este diseño. Una
retícula de roles declarada *sería* una política de control de meta-nivel
especificada explícitamente. El root no tiene política: tiene un espacio de acciones
computacionales —lanzar un worker, esperar, preguntar a una persona, cerrar un
hito, dejar de recabar evidencia y responder— colocadas en el mismo catálogo de
herramientas que las acciones de dominio, y elige entre ellas por su utilidad
estimada. El prompt del root formula el criterio en términos de
proporcionalidad: «Match your effort to the request, and re-calibrate as you
learn more» (`swarm_loop_v3.go:2424`), y desarrolla la escalera en tres peldaños
—responder en el mismo paso, usar herramientas uno mismo, delegar en workers—
que el propio modelo decide (`:2425-2427`).

El sustrato mecánico de esa elección es el bucle razonar-actuar que
describieron Yao y coautores, donde «reasoning traces help the model induce,
track, and update action plans as well as handle exceptions». La variación de
ALLAN consiste en qué se intercala: no solo acciones de dominio, sino acciones
de control. El plan que se induce y se actualiza en cada paso *es* la topología
de ejecución.

Debajo de todo esto está la racionalidad acotada de Simon, que en 1955 planteó
la tarea como «replace the global rationality of economic man with a kind of
rational behavior that is compatible with the access to information and the
computational capacities that are actually possessed by organisms». Un motor
que gasta cuatro llamadas en un saludo no es riguroso: es un *economic man*
computacional, optimizando sobre un espacio que no puede permitirse. La versión
contemporánea del mismo argumento —asignar cómputo de inferencia según la
dificultad estimada de cada petición en lugar de uniformemente— la formulan
Snell y coautores como estrategia «which acts to most effectively allocate
test-time compute adaptively per prompt».

Russell y Wefald traen consigo la advertencia que hace falta: el meta-nivel
también consume recursos, y la regresión hay que cortarla con reglas de parada,
no con más deliberación. ALLAN las tiene, y son deliberadamente romas. El
evaluador que decide si ampliar el presupuesto corre bajo un timeout plano y
**no renovable** de quince segundos, justificado en el código como negativa
explícita a la regresión: «a watchdog that could get stuck waiting on its own
judgment call would defeat the point» (`internal/agents/watchdog.go:29-34`). Las
dos primeras renovaciones de una espera se conceden por heurística, sin llamar
a ningún modelo (`watchdog.go:36-39`). Y el número de veces que un run puede
ampliar su presupuesto está topado en tres, dijera lo que dijera el juez:
`maxBudgetCheckpoints = 3` (`swarm_loop_v3.go:756-759`, comprobado en `:787`).

Hay un precedente limpio del patrón en la literatura de modelos de lenguaje.
Suzgun y Kalai describen el *meta-prompting* como una técnica que «transforms a
single LM into a multi-faceted conductor, adept at managing and integrating
multiple independent LM queries», donde las subtareas «are then handled by
distinct 'expert' instances of the same LM, each operating under specific,
tailored instructions». Es la misma forma: un modelo que descompone, delega en
instancias de sí mismo e integra. La diferencia arquitectónica de ALLAN es que
la delegación no es una convención de prompt sino una herramienta con
presupuesto, cerrojos y persistencia.

Conviene señalar la alternativa que ALLAN *no* eligió, porque existe y está
bien construida. Magentic-One mantiene el estado del meta-nivel en dos
estructuras explícitas. Su descripción literal es esta: «The outer loop
(lighter background with solid arrows) manages the task ledger (containing
facts, guesses, and plan). The inner loop (darker background with dotted
arrows) manages the progress ledger (containing current progress, task
assignment to agents).» Ese libro mayor es un objeto inspeccionable, con campos
nombrados. En ALLAN no hay equivalente: el plan del root vive íntegramente en
su transcripción, se reescribe implícitamente en cada paso y no tiene
representación consultable. La única estructura persistente de intención es el
cursor de hitos de flow, y solo existe cuando hay flow activo.

Esa ausencia tiene un nombre en la literatura clásica de agentes. Rao y
Georgeff plantearon el dilema exacto: «We seem caught on the horns of a
dilemma: reconsidering the choice of action at each step is potentially too
expensive and the chosen action possibly invalid, whereas unconditional
commitment to the chosen course of action can result in the system failing to
achieve its objectives.» Su respuesta fue el compromiso, con «the condition
that the agent is committed to maintain, called the commitment condition» y
«the condition under which the agent gives up the commitment, called the
termination condition». El root de ALLAN está en el extremo de la
reconsideración total: replanifica en cada paso porque no tiene dónde guardar
un compromiso. Se paga en tokens y en deriva.

## La objeción incómoda: ¿planifica el modelo?

Si la topología de ejecución es el plan del modelo, entonces la calidad del
motor está acotada por la capacidad de planificación del modelo. Y ahí la
literatura es dura.

PlanBench separó planificar de recordar mediante dominios de planificación
automática, precisamente porque «most claims about LLM planning capabilities are
however based on common sense tasks-where it becomes hard to tell whether LLMs
are planning or merely retrieving from their vast world knowledge», y concluye
que «on many critical capabilities-including plan generation-LLM performance
falls quite short, even with the SOTA models». Kambhampati y sus coautores
llevan la posición hasta el título: «We argue that auto-regressive LLMs cannot,
by themselves, do planning or self-verification (which is after all a form of
reasoning)». Su propuesta, LLM-Modulo, no es prescindir del modelo sino
rodearlo: «a vision of LLM-Modulo Frameworks that combine the strengths of LLMs
with external model-based verifiers in a tighter bi-directional interaction
regime». La corrección la aporta el crítico externo, nunca el generador.

Y la autocrítica sin verificador externo está peor que sin respaldo: Stechly,
Valmeekam y Kambhampati miden ambas cosas por separado y reportan «significant
performance collapse with self-critique and significant performance gains with
sound external verification».

Un motor de control emergente que ignorase esto sería indefendible. ALLAN no lo
ignora del todo, pero su aplicación es desigual, y merece la pena mirarla pieza
por pieza.

Donde sí hay crítico externo: el cierre de hitos no se cree la afirmación del
modelo. `handleMilestoneDone` valida el identificador contra el catálogo, exige
que el hito esté abierto, comprueba las dependencias y rechaza la evidencia
vacía antes de mover el cursor (`swarm_loop_v3.go:1209`, validaciones en
`:1229-1245`); cada rechazo vuelve como resultado de herramienta correctivo, no
como error. El root tampoco puede entregar mientras queden hitos abiertos: el
borrador se rechaza y el bucle continúa hasta agotarse y caer en la síntesis
best-effort (`:705-710`). Y el juez de presupuesto no razona sobre prosa:
recibe contadores medidos —pasos usados, llamadas a herramientas, spawns, hitos
cerrados— en una estructura `BudgetCheckpoint` (`:847-860`), precisamente
porque en el incidente del 2026-07-28 un juez que solo veía una cadena de
motivo cortó un run que llevaba cien de doscientas cuatro fichas de CRM
paginadas, leyendo «solo dos pasos usados» como «el agente apenas ha empezado»
(`watchdog.go:120-131`). Sustituir una inferencia del modelo por un contador
del motor es el movimiento LLM-Modulo, en pequeño.

Donde no lo hay: el revisor. `maybeReview` es una llamada a un modelo rápido
que juzga el borrador contra la petición original sin ninguna señal externa
(`swarm_loop_v3.go:1739-1793`) —justo la autocrítica cuyo colapso mide Stechly.
La decisión de ALLAN fue quitarle el veto: su prompt le dice «Your feedback is
advice, not a gate» (`:1753`), un fallo del revisor acepta el borrador
(`:1779-1782`) y solo se ejecuta una vez por run (`:1745`). Es una mitigación
honesta del riesgo —una crítica no vinculante no puede destruir trabajo— pero
conviene decir lo que también implica: si la autocrítica no es fiable, un
revisor sin veto no es una salvaguarda, es un gasto con varianza. La única
razón defendible para conservarlo es que a veces su consejo es material y
barato; no que aumente la corrección.

## ¿Y la evidencia de que varios agentes ayudan?

La topología emergente de ALLAN produce, cuando el root lo decide, paralelismo:
varias llamadas `allan.swarm/spawn` en un mismo turno se acumulan
(`swarm_loop_v3.go:996-1001`) y se ejecutan concurrentes bajo un semáforo de
`MaxWorkers`, cuatro por defecto (`:1505`, `:438`). Conviene preguntarse qué
dice la evidencia sobre si eso sirve.

Dos fuentes de proveedor, que hay que leer como tales, reportan ganancia.
Anthropic afirma que «we found that a multi-agent system with Claude Opus 4 as
the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude
Opus 4 by 90.2% on our internal research eval» —evaluación interna, no
reproducible desde fuera— y en la misma página que «multi-agent systems use
about 15× more tokens than chats». LangChain, sobre τ-bench modificado, informa
que «the single agent baseline falls off sharply when there are two or more
distractor domains» mientras las arquitecturas multiagente se mantienen planas
en coste: «the single agent uses consistently more tokens as the number of
distractor domains grows, while supervisor and swarm remain flat». Ambas son
entradas de blog de empresas que venden la arquitectura que miden.

Tres preprints recientes empujan en dirección contraria. Tran y Kiela
normalizan el cómputo y concluyen que «many reported advantages of multi-agent
systems are better explained by unaccounted computation and context effects
rather than inherent architectural benefits». Jwalapuram y coautores encuentran
que los sistemas multiagente generados automáticamente «consistently
underperform CoT-SC despite being up to 10x more expensive», y lo atribuyen a
que «current automated design paradigms produce architectural bloat that
prioritizes superficial complexity which does not translate into functional
utility». Y Kaliyev y Maryanskyy miden el suelo de ruido: sobre un solo modelo
y un solo benchmark, «the envelope of observed paired gaps spans [-3,+18]pp
across two seeds», de donde «seven of ten recent multi-agent coordination
architectures report headline effects below this local floor». Los tres son
preprints sin réplica independiente conocida, y el último es explícitamente
estrecho —un modelo, un benchmark—; su fuerza está en el método, no en la
generalidad.

Al recuperar las fuentes apareció el dato que cambia la lectura, y viene del
lado que menos convenía. La entrada de Anthropic, la más favorable al
multiagente de todo el corpus, explica su propio resultado así: «Multi-agent
systems work mainly because they help spend enough tokens to solve the
problem», y cuantifica: «we found that token usage by itself explains 80% of
the variance, with the number of tool calls and the model choice as the two
other explanatory factors». Es decir: el proveedor que reporta +90,2% y el
preprint que niega la ventaja arquitectónica **coinciden en el mecanismo**. La
variable no es cuántos agentes hay, es cuánto cómputo se gasta y sobre qué
contexto. El mismo texto delimita su propio alcance: «some domains that require
all agents to share the same context or involve many dependencies between
agents are not a good fit for multi-agent systems today».

Eso reordena la pregunta de diseño. «¿Cuántos agentes?» es la pregunta
equivocada; la correcta es «¿quién decide cuánto gastar, y con qué
información?». Que es, literalmente, el problema de Russell y Wefald. La
respuesta de ALLAN —no declarar el número, dejar que el root lo elija, y acotar
el total con presupuestos renovables y un techo de tres ampliaciones— resulta
coherente con la evidencia, aunque ninguna de estas fuentes la valide. Y
aparece, como contrapeso, el resultado de Chen y coautores sobre sistemas
compuestos: «the performance of both Vote and Filter-Vote can first increase
but then decrease as a function of the number of LM calls». Más llamadas no es
monótonamente mejor; un root sin techo tampoco lo sería.

Queda una tensión no resuelta con la ingeniería de contexto. Cognition sostiene
como principio «Share context, and share full agent traces, not just individual
messages» y «Actions carry implicit decisions, and conflicting decisions carry
bad results» —opinión de ingeniería, no estudio controlado. ALLAN hace lo
contrario a propósito: el worker recibe la constitución del agente, la petición
original y lo que el root le pase, nada más (`swarm_loop_v3.go:2491-2509`), y el
diseño lo justifica textualmente: «La solución a los handoffs no es copiar el
transcript completo a cada worker»
(`docs/arquitectura/swarm-v3-execution-contract-redesign.md:120-121`). El
runtime no propaga el contexto; la garantía se traslada a una frase del prompt
del root —«Workers only know what you brief them: include the relevant findings
from earlier workers in context when a task depends on them» (`:2428`)— y a la
descripción del propio spawn: «When a worker depends on earlier findings, paste
the relevant findings into context — that is the only way it receives them»
(`:2269`). Esto cae dentro de la jerarquía que el propio diseño declara
vinculante —semántica → runtime → prompt → artefactos
(`swarm-v3-execution-contract-redesign.md:40-44`)— pero en su peldaño más
débil, y cae en la categoría que Cemri y coautores llaman «inter-agent
misalignment»: su taxonomía identifica «14 unique modes, clustered into 3
categories: (i) system design issues, (ii) inter-agent misalignment, and (iii)
task verification». *(Una versión anterior de este párrafo afirmaba que la
omisión coincide con «dos de los catorce modos». Esa cuenta no está respaldada:
el resumen recuperado nombra las tres categorías y el número total de modos, y no
se ha leído la enumeración modo a modo, de manera que la correspondencia se
enuncia aquí a nivel de categoría y no de modo.)* Su diagnóstico general merece
citarse entero, porque es el marco correcto para leer todo lo anterior:
«Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains
on popular benchmarks are often minimal.»

## Lo que el motor garantiza hoy

Los invariantes siguientes están enunciados para poder ser refutados con un
test. Todos se sostienen sobre código leído, no sobre diseño.

Solo el root cierra hitos y produce la respuesta final. Los tres pseudo-tools
de control del meta-nivel se añaden **después** de `ModelTools()` y solo en la
ruta del root: `planTitleToolDefinition`, `swarmSpawnToolDefinition` y —si hay
flow activo— `flowMilestoneToolDefinition` (`swarm_loop_v3.go:2251-2256`); el
worker recibe únicamente `toolRuntime.ModelTools()` (`:1589`). La topología es,
por construcción, de dos niveles; un tercero solo aparece por
`tenant.agent/delegate`, que arranca un run distinto y se detecta como anidado
mediante un valor de contexto (`:368-372`, `:407`).

Las acciones de control no consumen presupuesto de trabajo. `isControlTool`
lista exactamente cuatro (`internal/agents/swarm_skills.go:117-120`) y el spawn
se trata aparte (`swarm_loop_v3.go:1014`). Preguntar a una persona, cargar una
skill o titular el plan no compiten con recabar evidencia.

Toda herramienta sin `readOnlyHint` se considera mutante y serializa
(`:2664-2676`). Equivocarse por exceso cuesta paralelismo; por defecto, datos.
Las claves de cerrojo se ordenan globalmente antes de adquirirse
(`:2620-2646`), lo que hace imposible el interbloqueo por orden inverso.

Ilimitado sigue ilimitado: `raiseMax` no toca un presupuesto con `max <= 0`
(`:2599-2609`), de modo que una ampliación jamás convierte «sin techo» en «con
techo». El incremento es proporcional, no plano, y el código explica por qué:
un incremento fijo «quietly re-imposes the ceiling the checkpoint exists to
remove» (`:827-834`).

Agotar el presupuesto no destruye trabajo. `wrapUp` concede una generación
final sin herramientas para sintetizar lo que haya (`:1848`). El invariante es
falsable y tiene excepción declarada: si esa síntesis falla o vuelve vacía, el
run sí termina en `failed` (`:1880`, `:1886`).

## Lo que está roto, sin terminar o sin medir

**No existe contrato de ejecución congelado.** `ExecutionContract` tiene cero
apariciones en el árbol de `Platform Server`. El resume sigue recompilando o
rehidratando el FlowIR por hash de fuente, tal como el propio diseño reprocha:
«El resume recompila o reconstruye flows mediante fuente/hash, en lugar de
retomar siempre un contrato efectivo congelado y trazable»
(`swarm-v3-execution-contract-redesign.md:241-242`). En un motor de topología
declarada esto sería una molestia; en uno de topología emergente es el agujero
central, porque la única definición posible de «el mismo run» es el contrato
bajo el que corría.

Y el coste de no tenerlo se puede acotar con evidencia externa. TRAIL midió
cuánto cuesta reconstruir un fallo a partir de la traza de un sistema agéntico
y encontró que «modern long context LLMs perform poorly at trace debugging,
with the best Gemini-2.5-pro model scoring a mere 11% on TRAIL». Una topología
que no se declara solo se puede auditar por la traza; si auditar por la traza es
así de caro, el contrato congelado no es una mejora deseable sino el precio de
la arquitectura.

**Los veredictos del meta-nivel casi no se observan.** El veredicto en sí
—`RENEW`/`NUDGE`/`INTERVENE`/`ESCALATE` y su motivo— solo sale por `debugf`
(`watchdog.go:107`, `:112`, `:115`, `:224`, `:229`, `:232`); el fichero no
contiene ni una llamada a `AppendTrace` ni ninguna métrica. Lo que sí deja traza
son las dos consecuencias: `swarm_v3_budget_extended` cuando se concede la
ampliación (`swarm_loop_v3.go:799-807`) y `swarm_v3_wrap_up` cuando no
(`:1851`). La parte del sistema que decide cuánto gastar es la menos
instrumentada, y es justamente la variable que la evidencia externa señala como
decisiva.

**`write_locks` del flow es decorativo.** `FlowStepIR.WriteLocks` existe
(`internal/flows/types.go:93`) y el validador lo deduplica
(`internal/flows/validate.go:63`), pero no tiene ningún consumidor: la fusión de
pasos de flow activos mezcla ocho campos —listas de tools permitidas y
denegadas, y seis topes— y no ese
(`mergeActiveFlowRuntimeSteps`, `internal/app/app.go:2578-2596`). Los únicos cerrojos efectivos son los que
**el modelo** declara en su spawn (`swarm_loop_v3.go:1675`). El diseño ya lo
había clasificado: «`write_locks` existe en `FlowStepIR`, pero no llega
automáticamente al `swarmV3SpawnSpec` que gobierna los locks reales del worker»
(`swarm-v3-execution-contract-redesign.md:182-184`).

**La asimetría de cerrojos entre root y worker no está documentada en ningún
diseño.** El root siempre bloquea con la clave conservadora `"workspace"`
(`:1023`, `lockFor(nil, …)`); un worker que declaró `["crm"]` bloquea solo
`"crm"`. Nada impide que root y worker muten el mismo recurso en paralelo si el
worker fue específico. Es fragilidad real, no teórica.

**El bucle del worker no tiene punto de control.** Al agotar pasos termina en
`partial` con su último estado intermedio (`:1723-1733`). La guillotina que el
diseño quitó al root sigue puesta al worker, y los topes de flow siguen
recortando `MaxWorkers`, `WorkerMaxSteps` y `WorkerMaxToolCalls` con
`minPositive` (`:467-472`), pese a que el propio código admite que esa simetría
es «a natural follow-up, not done here» (`:461-464`).

**El objetivo `swarm_v3.worker` sigue inerte.** Se normaliza
(`internal/flows/validate.go:166-167`) pero no produce spawn; el diseño lo
reconoce: «El target `swarm_v3.worker` expresa intención, pero no produce por
sí solo un spawn automático»
(`swarm-v3-execution-contract-redesign.md:179-180`).

**No hay medición.** `internal/` no contiene ninguna función `Benchmark`, y no
existe en el repositorio ninguna evaluación que compare la topología emergente
contra una declarada sobre el mismo trabajo y el mismo presupuesto de tokens. La
decisión arquitectónica central del motor descansa hoy sobre el análisis de un
incidente concreto —el del 2026-07-18, documentado con logs y líneas de código
en `intelligent-wait-supervision-design.md:21-56`— y sobre el argumento de este
ensayo. Eso es más de lo que ofrece la mayoría de los frameworks del área, y es
menos de lo que exigiría el protocolo de Kaliyev y Maryanskyy: la topología
emergente no se ha comparado nunca contra una declarada ni contra su suelo de
ruido.

Conviene terminar donde empezó. Que no haya retícula fija está bien fundado: hay
un incidente con autopsia, hay teoría clásica que nombra el problema y hay una
normalización de esquema que impide introducirla por la puerta de atrás. Que la
topología emergente sea *mejor* no está demostrado ni
aquí ni en la literatura. Lo que la evidencia recuperada sí sostiene es más
específico y más útil: la variable que decide el resultado es cuánto cómputo se
gasta y sobre qué contexto, no cuántos agentes intervienen; y una arquitectura
que renuncia a declarar su control se compromete, a cambio, a poder
reconstruirlo después. ALLAN ha cumplido la primera mitad de ese trato. La
segunda —el contrato congelado y la traza del meta-nivel— sigue pendiente.

## Referencias

**Anthropic (2025).** *How we built our multi-agent research system*.
https://www.anthropic.com/engineering/multi-agent-research-system —
*Entrada de blog de proveedor; la evaluación es interna y no reproducible desde
fuera.* «We found that a multi-agent system with Claude Opus 4 as the lead agent
and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%
on our internal research eval.» · «In our data, agents typically use about 4×
more tokens than chat interactions, and multi-agent systems use about 15× more
tokens than chats.» · «Multi-agent systems work mainly because they help spend
enough tokens to solve the problem.» · «We found that token usage by itself
explains 80% of the variance, with the number of tool calls and the model choice
as the two other explanatory factors.» · «However, some domains that require all
agents to share the same context or involve many dependencies between agents are
not a good fit for multi-agent systems today.»

**Cemri, M., Pan, M. Z., Yang, S., Agrawal, L. A., Chopra, B., Tiwari, R.,
Keutzer, K., Parameswaran, A., Klein, D., Ramchandran, K., Zaharia, M.,
Gonzalez, J. E., Stoica, I. (2025).** *Why Do Multi-Agent LLM Systems Fail?*
arXiv:2503.13657. https://arxiv.org/abs/2503.13657 — «Despite enthusiasm for
Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are
often minimal.» · «14 unique modes, clustered into 3 categories: (i) system
design issues, (ii) inter-agent misalignment, and (iii) task verification.»

**Chen, L., Davis, J. Q., Hanin, B., Bailis, P., Stoica, I., Zaharia, M., Zou,
J. (2024).** *Are More LLM Calls All You Need? Towards Scaling Laws of Compound
Inference Systems*. arXiv:2403.02419. https://arxiv.org/abs/2403.02419 —
«the performance of both Vote and Filter-Vote can first increase but then
decrease as a function of the number of LM calls».

**Deshpande, D., Gangal, V., Mehta, H., Krishnan, J., Kannappan, A., Qian, R.
(2025).** *TRAIL: Trace Reasoning and Agentic Issue Localization*.
arXiv:2505.08638. https://arxiv.org/abs/2505.08638 — «Our evaluations reveal
that modern long context LLMs perform poorly at trace debugging, with the best
Gemini-2.5-pro model scoring a mere 11% on TRAIL.»

**Fourney, A., et al. (2024).** *Magentic-One: A Generalist Multi-Agent System
for Solving Complex Tasks*. arXiv:2411.04468. https://arxiv.org/html/2411.04468v1
— frase recuperada del **pie de la figura 2**, no del cuerpo del artículo: «The
outer loop (lighter background with solid arrows) manages the task ledger
(containing facts, guesses, and plan). The inner loop (darker background with
dotted arrows) manages the progress ledger (containing current progress, task
assignment to agents).» · Del resumen: «Magentic-One uses a multi-agent
architecture where a lead agent, the Orchestrator, plans, tracks progress, and
re-plans to recover from errors.»

**Fu-Hinthorn, W. / LangChain (10 de junio de 2025).** *Benchmarking Multi-Agent
Architectures*. https://www.langchain.com/blog/benchmarking-multi-agent-architectures
— *Entrada de blog de proveedor.* «We see that the single agent baseline falls
off sharply when there are two or more distractor domains.» · «We see that the
single agent uses consistently more tokens as the number of distractor domains
grows, while supervisor and swarm remain flat.»

**Jwalapuram, P., Lin, H., Li, C., Jiao, F., Wang, S., Ming, Y., Ke, Z., Qin, C.,
Carenini, G., Joty, S. (2026).** *The Illusion of Multi-Agent Advantage*.
arXiv:2606.13003. https://arxiv.org/abs/2606.13003 — *Preprint de junio de 2026,
sin réplica independiente conocida.* «we demonstrate that automatic MAS
consistently underperform CoT-SC despite being up to 10x more expensive» ·
«current automated design paradigms produce architectural bloat that prioritizes
superficial complexity which does not translate into functional utility».

**Kaliyev, A. T., Maryanskyy, A. (2026).** *How Much Coordination Gain Is Real?
A Paired Noise-Floor Protocol for Multi-Agent LLM Benchmarks*. arXiv:2606.20695.
https://arxiv.org/abs/2606.20695 — *Preprint de junio de 2026; alcance estrecho,
declarado por los propios autores: un solo modelo (Claude Haiku 4.5) y un solo
benchmark (τ²-bench retail).* «The envelope of observed paired gaps spans
[-3,+18]pp across two seeds, with pooled upper Wilson CI ~15pp. Seven of ten
recent multi-agent coordination architectures report headline effects below this
local floor.»

**Kambhampati, S., Valmeekam, K., Guan, L., Verma, M., Stechly, K., Bhambri, S.,
Saldyt, L., Murthy, A. (2024).** *LLMs Can't Plan, But Can Help Planning in
LLM-Modulo Frameworks*. arXiv:2402.01817. https://arxiv.org/abs/2402.01817 —
«We argue that auto-regressive LLMs cannot, by themselves, do planning or
self-verification (which is after all a form of reasoning), and shed some light
on the reasons for misunderstandings in the literature.» · «We present a vision
of LLM-Modulo Frameworks that combine the strengths of LLMs with external
model-based verifiers in a tighter bi-directional interaction regime.»

**Rao, A. S., Georgeff, M. P. (1995).** *BDI Agents: From Theory to Practice*.
Proceedings of the First International Conference on Multiagent Systems
(ICMAS-95), pp. 312-319. https://cdn.aaai.org/ICMAS/1995/ICMAS95-042.pdf —
*Recuperado y leído directamente del facsímil PDF de AAAI.* Página 314: «We seem
caught on the horns of a dilemma: reconsidering the choice of action at each step
is potentially too expensive and the chosen action possibly invalid, whereas
unconditional commitment to the chosen course of action can result in the system
failing to achieve its objectives.» · Página 315: «A commitment usually has two
parts to it: one is the condition that the agent is committed to maintain, called
the commitment condition, and the second is the condition under which the agent
gives up the commitment, called the termination condition.»

**Russell, S., Wefald, E. (1989).** *Principles of Metareasoning*. Preprint de
KR'89 (Toronto), Computer Science Division, University of California, Berkeley;
conservado en el archivo Allen Newell de la biblioteca de Carnegie Mellon.
http://iiif.library.cmu.edu/file/Newell_box00014_fld01011_doc0001/Newell_box00014_fld01011_doc0001.pdf
— *Recuperado y leído directamente del facsímil PDF.* «In this paper we outline a
general approach to the study of formalized metareasoning, not in the sense of
explicating the semantics of explicitly specified meta-level control policies,
but in the sense of providing a basis for selecting and justifying computational
actions.» · «We develop a general formula for the utility of computations, this
utility being derived directly from the ability of computations to affect an
agent's external actions.» · «This research contributes to a developing attack on
the problem of resource-bounded rationality, by providing a means for analysing
and generating optimal computational strategies.» — **NO VERIFICADA la versión de
revista** (*Artificial Intelligence* 49(1-3):361-395, 1991): ScienceDirect
devolvió HTTP 403 y no se pudo leer su texto. Las frases citadas proceden de la
versión de conferencia recuperada, cuyo contenido puede diferir en detalle del
artículo de 1991.

**Simon, H. A. (1955).** *A Behavioral Model of Rational Choice*. The Quarterly
Journal of Economics 69(1):99-118.
https://cooperative-individualism.org/simon-herbert_a-behavioral-model-of-rational-choice-1955-feb.pdf
— *Recuperado y leído directamente del facsímil JSTOR, página 99.* «Broadly
stated, the task is to replace the global rationality of economic man with a kind
of rational behavior that is compatible with the access to information and the
computational capacities that are actually possessed by organisms, including man,
in the kinds of environments in which such organisms exist.»

**Snell, C., Lee, J., Xu, K., Kumar, A. (2024).** *Scaling LLM Test-Time Compute
Optimally can be More Effective than Scaling Model Parameters*. arXiv:2408.03314.
https://arxiv.org/abs/2408.03314 — «Using this compute-optimal strategy, which
acts to most effectively allocate test-time compute adaptively per prompt, we can
improve the efficiency of test-time compute scaling by more than 4x compared to a
best-of-N baseline.»

**Stechly, K., Valmeekam, K., Kambhampati, S. (2024).** *On the Self-Verification
Limitations of Large Language Models on Reasoning and Planning Tasks*.
arXiv:2402.08115. https://arxiv.org/abs/2402.08115 — «We observe significant
performance collapse with self-critique and significant performance gains with
sound external verification.»

**Suzgun, M., Kalai, A. T. (2024).** *Meta-Prompting: Enhancing Language Models
with Task-Agnostic Scaffolding*. arXiv:2401.12954.
https://arxiv.org/abs/2401.12954 — «This approach transforms a single LM into a
multi-faceted conductor, adept at managing and integrating multiple independent
LM queries.» · «These subtasks are then handled by distinct 'expert' instances of
the same LM, each operating under specific, tailored instructions.»

**Tran, D., Kiela, D. (2026).** *Single-Agent LLMs Outperform Multi-Agent Systems
on Multi-Hop Reasoning Under Equal Thinking Token Budgets*. arXiv:2604.02460.
https://arxiv.org/abs/2604.02460 — *Preprint de abril de 2026, sin réplica
independiente conocida.* «We find that SAS consistently match or outperform MAS
on multi-hop reasoning tasks when reasoning tokens are held constant.» · «many
reported advantages of multi-agent systems are better explained by unaccounted
computation and context effects rather than inherent architectural benefits».

**Valmeekam, K., Marquez, M., Olmo, A., Sreedharan, S., Kambhampati, S.
(2022/2023).** *PlanBench: An Extensible Benchmark for Evaluating Large Language
Models on Planning and Reasoning about Change*. arXiv:2206.10498.
https://arxiv.org/abs/2206.10498 — «Most claims about LLM planning capabilities
are however based on common sense tasks-where it becomes hard to tell whether
LLMs are planning or merely retrieving from their vast world knowledge.» · «Our
studies also show that on many critical capabilities-including plan
generation-LLM performance falls quite short, even with the SOTA models.»

**Yan, W. / Cognition (12 de junio de 2025).** *Don't Build Multi-Agents*.
https://cognition.com/blog/dont-build-multi-agents — *Opinión de ingeniería, no
estudio controlado.* «Share context, and share full agent traces, not just
individual messages» · «Actions carry implicit decisions, and conflicting
decisions carry bad results».

**Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., Cao, Y.
(2022).** *ReAct: Synergizing Reasoning and Acting in Language Models*.
arXiv:2210.03629. https://arxiv.org/abs/2210.03629 — «reasoning traces help the
model induce, track, and update action plans as well as handle exceptions».