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».