Research Brief — Orchestration Algorithms: The Quantitative Layer (2025–2026)

Prepared: 2026-07-09. Audience: agentic-systems knowledge base; the quantitative companion to the orchestration-patterns page (content/orchestration/index.md). That page names the topologies — supervisor / orchestrator-worker, hierarchical, sequential pipeline, parallel (sectioning and voting), swarm / handoff, blackboard, router, group chat — and describes their tradeoffs in prose; this brief supplies the decision rules, formulas, scaling curves, and cost models behind them. Sources are cited in-text by id; the full list (all URLs verified 2026-07-09) is in the Sources section in references.yaml format. Companion briefs: retrieval-rag-sota.md, agent-loops-planning-sota.md, memory-sota.md.

1. Executive summary

Five shifts define the quantitative picture of orchestration in 2025–2026:

1. Routing became a decision problem with real algorithms. The router/dispatcher pattern acquired math: bandit policies (UCB1) for online handler selection [ucb1-paper], routers learned from human preference data (RouteLLM — BERT-sized classifiers and matrix factorization, cutting cost more than 2× at matched quality) [routellm-paper], and sequential cost-quality cascades (FrugalGPT — match GPT-4 with up to 98% cost reduction) [frugalgpt-paper]. The router itself should usually be cheap: a classifier, not a frontier model [anthropic-effective-agents].
2. Voting has measured scaling curves — and known failure modes. Self-consistency's majority vote [self-consistency] generalizes to "performance … scales with the number of agents instantiated" [more-agents-paper] and to layered Mixture-of-Agents ensembles [moa-paper]. The binding assumption is error independence: debate converges confidently on wrong answers when agents share them [debate-paper].
3. Search over reasoning is classical tree search with LM value functions, and test-time compute is the budget currency: compute-optimal allocation is >4× more efficient than best-of-N, and FLOPs-matched small-model-plus-search beats a 14× larger model [snell-tts] [tot-paper] [uct-paper] [lets-verify].
4. Fan-out economics are measured, not vibes. Anthropic's production numbers: +90.2% over single-agent on research tasks, at ~15× chat-level token cost, with token usage alone explaining 80% of performance variance [anthropic-multi-agent-research]. The serial fraction (decomposition, synthesis, orchestrator turns) bounds the speedup — Amdahl's original argument, replayed with tokens [amdahl-1967].
5. Topology is a graph with countable costs. Star (supervisor) topologies grow message channels O(n); mesh (debate, network) topologies grow O(n²) — and measured results say most of the quadratic spend is redundant: sparse debate matches or beats fully-connected debate with >40% fewer input tokens [sparse-debate-paper], and message-graph pruning reproduces SOTA topologies at $5.6 versus $43.7 [agentprune-paper]. Reliability composes multiplicatively along any of these graphs (§7).

2. Routing as a decision problem

The content page's router "makes a single up-front classification and then steps out of the way." This section is about how that classification decision should be made — and priced.

2.1 The bandit framing: UCB1

Choosing among K handlers (models, pipelines, toolsets) with unknown quality, learning online from feedback, is the K-armed bandit problem. The classical policy is UCB1 [ucb1-paper]: after playing each arm once, always play the arm j that maximizes

x̄_j + sqrt( 2·ln(n) / n_j )

"where x̄_j is the average reward obtained from machine j, n_j is the number of times machine j has been played so far, and n is the overall number of plays done so far" [ucb1-paper]. The logic is optimism in the face of uncertainty: the second term is a confidence radius, large for rarely-tried arms (forcing exploration), shrinking with use (converging to exploitation); expected regret grows only logarithmically — "the optimal logarithmic regret is also achievable uniformly over time, with simple and efficient policies" [ucb1-paper]. Plain UCB1 ignores the query itself, so it suits A/B-style handler selection under drift; contextual routing on query features is where the learned routers below take over.

2.2 Learned routers: RouteLLM

RouteLLM [routellm-paper] formalizes the cost/quality router: send each query to a strong or a weak model, training the router on human preference data (Chatbot Arena) to predict the probability that the strong model's answer wins. Four router architectures are studied — similarity-weighted ranking, matrix factorization, a BERT classifier, and a causal-LLM classifier — i.e., the routers themselves are small. Paper results: costs reduced "by over 2 times in certain cases—without compromising the quality of responses," up to 75% cheaper than a random router on MT Bench, and "optimal cost savings of up to 3.66x" at matched quality [routellm-paper]. The authors' companion blog states the headline differently: "cost reductions of over 85% on MT Bench, 45% on MMLU, and 35% on GSM8K … while still achieving 95% of GPT-4's performance" [routellm-blog].

2.3 Cost-quality cascades: FrugalGPT

Where a router commits before seeing any answer, a cascade decides after: FrugalGPT's "LLM cascade sends a query to a list of LLM APIs sequentially. If one LLM API's response is reliable, then its response is returned, and no further LLMs in the list are needed" [frugalgpt-paper]. The decision rule has two learned objects — the ordered model list L and a threshold vector τ — plus "a generation scoring function" g(q, a) that "generates a reliability score given a query and an answer produced by an LLM API" (instantiated as "a DistilBERT tailored to regression"). Step i returns answer a_i iff g(q, a_i) > τ_i, otherwise escalates to model i+1. Headline: "FrugalGPT can match the performance of the best individual LLM (e.g. GPT-4) with up to 98% cost reduction or improve the accuracy over GPT-4 by 4% with the same cost" [frugalgpt-paper]. Cascades beat routers when cheap-model answers are verifiable after the fact more accurately than they are predictable before it — the price is added latency on escalated queries.

2.4 When a cheap classifier beats an LLM router

Anthropic's routing workflow says the quiet part: classification "can be handled accurately, either by an LLM or a more traditional classification model/algorithm," with the canonical example "routing easy/common questions to smaller, cost-efficient models … and hard/unusual questions to more capable models" [anthropic-effective-agents]. The arithmetic is blunt: the router's value is Δcost · P(routed cheap) − c_router − P(misroute) · cost(misroute), so a router that costs a frontier-model call to save a frontier-model call is self-defeating — which is why RouteLLM's routers are matrix factorizations and BERT-scale classifiers [routellm-paper] and FrugalGPT's scorer is a DistilBERT [frugalgpt-paper]. Reach for an LLM router only when the routing decision itself requires reasoning a small model cannot learn from logged preferences.

3. Ensembling and voting: the mathematics of sampling many

The content page's parallel: voting variant runs "the same task multiple times to get diverse outputs." This section is why that works, how it scales, and when it fails.

3.1 Self-consistency is majority voting over sampled reasoning paths

Self-consistency [self-consistency] samples "a diverse set of reasoning paths instead of only taking the greedy one, and then selects the most consistent answer by marginalizing out the sampled reasoning paths":

answer = argmax_a Σ_{i=1..n} 1[ a_i = a ]

Gains on reasoning benchmarks (vs greedy chain-of-thought): GSM8K +17.9%, SVAMP +11.0%, AQuA +12.2% absolute [self-consistency]. A free by-product is a confidence signal: the fraction of samples agreeing with the winner "is highly correlated with accuracy," so "one can use low consistency as an indicator that the model has low confidence" [self-consistency] — a cheap router feature (§2) and escalation trigger.

3.2 Why aggregation helps — and when it fails

The Condorcet-style argument (classical jury-theorem logic; none of the LLM papers cited here invokes the theorem by name): if each of n votes is independently correct with probability p > 1/2, majority accuracy rises monotonically toward 1 as n grows — and, symmetrically, decays toward 0 when p < 1/2. Both halves show up empirically. "More Agents" finds "the degree of enhancement is correlated to the task difficulty," with gains that "increase then decrease by rising the inherent difficulty" [more-agents-paper] — when p collapses toward chance, voting amplifies noise, not signal. And independence is the load-bearing assumption: samples from one model share training distribution, biases, and blind spots, and multi-agent debate documents the resulting failure — "while debates typically converged into single final answers, these answers were not necessarily correct," with models continuing to "confidently affirm that their answer is correct and consistent with all other agent responses" [debate-paper]. Consensus measures agreement, not truth; correlated errors make agreement cheap.

3.3 Best-of-n with a verifier

If each sample independently solves the task with probability p, then

P(at least one of n samples is correct) = 1 − (1−p)^n

(arithmetic). This is the oracle ceiling of best-of-n — realized only if the selector can recognize the correct sample. The measurement convention comes from the Codex paper: estimate pass@k from n ≥ k samples with c correct via the unbiased estimator pass@k = E[ 1 − C(n−c, k) / C(n, k) ]; the tempting plug-in 1 − (1−p̂)^k "is biased" (and the raw combinatorial form is numerically unstable — compute it term-by-term) [codex-paper]. Two verifier caveats bound the practice:

• The realized gain is P(a correct sample exists) × P(verifier picks it) (arithmetic): a verifier with a nonzero false-accept rate caps best-of-n below its oracle curve, and the cap binds harder as n grows because more wrong-but-plausible candidates compete for acceptance.
• With a strong verifier the curve is remarkable: OpenAI's process reward model, selecting best-of-1860 per problem, solves 78.2% of "a representative subset of the MATH test set" [lets-verify]. The companion brief (agent-loops-planning-sota.md §3) covers verifier failure modes (OOD drift, reward hacking under heavy search).

3.4 Scaling curves: sampling-and-voting

"More Agents Is All You Need" [more-agents-paper] is the systematic measurement: "simply via a sampling-and-voting method, the performance of large language models (LLMs) scales with the number of agents instantiated," orthogonally to prompt- and framework-level methods. Concrete anchor (paper §5.1): "the enhanced Llama2-13B model achieves 59% accuracy on the GSM8K dataset, outperforming the Llama2-70B model, which scores 54%" — a smaller model out-voting a ~5× larger one, the ensemble-side twin of the test-time-compute result in §4.4. The measured properties: gains rise then fall with inherent task difficulty, rise with the number of reasoning steps, and rise with the prior probability of the correct answer [more-agents-paper].

3.5 Mixture-of-Agents: stacking the ensemble

Mixture-of-Agents [moa-paper] composes the content page's parallel and pipeline patterns: "a layered MoA architecture wherein each layer comprises multiple LLM agents. Each agent takes all the outputs from agents in the previous layer as auxiliary information in generating its response." Result: "Our MoA using only open-source LLMs is the leader of AlpacaEval 2.0 by a substantial gap, achieving a score of 65.1% compared to 57.5% by GPT-4 Omni" [moa-paper]. Read as topology: a fixed-depth DAG whose width buys diversity (§3.2) and whose depth buys aggregation — with token cost multiplying in both directions (§6.2).

3.6 Debate: voting with communication

Multi-agent debate [debate-paper] replaces independent voting with rounds of mutual reading: "multiple language model instances propose and debate their individual responses and reasoning processes over multiple rounds to arrive at a common final answer," improving "mathematical and strategic reasoning" and "the factual validity of generated content." It is the mesh topology of the content page's swarm/blackboard family, so its costs are quadratic (§6.2) — and its convergence-to-confident-error failure mode is §3.2's correlation warning in action.

4. Search over reasoning as tree search

The agent-loops companion brief owns the lineage (ReAct → ToT → LATS → internalized RL, its §2–3); this section states the selection math and the compute economics an orchestrator needs.

4.1 Tree of Thoughts: BFS/DFS over partial thoughts

ToT [tot-paper] frames reasoning as search over a tree of partial "thoughts," with a proposal prompt expanding states and a value/vote prompt scoring them, explored by BFS or DFS with a beam. The number that made it famous (Game of 24): "while GPT-4 with chain-of-thought prompting only solved 4% of tasks, our method achieved a success rate of 74%" [tot-paper].

4.2 MCTS selection: the UCT rule

UCT ("UCB applied to trees") runs the §2.1 bandit at every internal node [uct-paper]: treat each node's actions as arms, and descend by selecting the action that maximizes

Q(s,a) + c_{t,s} with bias term c_{t,s} = sqrt( 2·ln(t) / s )

— Q(s,a) the current action-value estimate, t the parent's visit count, s the child's (the paper's drift analysis uses the generalized form c_{t,s} = 2·C_p·sqrt(ln t / s) with an appropriate constant C_p; "in state s, at depth d, the action that maximises Q_t(s,a,d) + c_{N_{s,d}(t),N_{s,a,d}(t)} is selected") [uct-paper]. Routing (§2.1) and tree search share the same optimism core; LATS instantiates exactly this selection rule over environment actions (see agent-loops-planning-sota.md §2 for the full LATS walkthrough and its costs).

4.3 Process-reward-model-guided search

"Let's Verify Step by Step" [lets-verify] supplies the value function: a process reward model trained on PRM800K — "800,000 step-level human feedback labels" ("across 75K solutions to 12K problems") — scores each reasoning step, and as a best-of-N selector reaches the 78.2% MATH-subset result of §3.3 at N = 1860. PRM-guided beam over steps is the standard math/code search recipe; the PRM doubles as an RL reward model, which is how search moved inside the model (companion brief §6).

4.4 Test-time compute: the orchestrator's budget curve

Snell et al. [snell-tts] give the allocation result orchestration should internalize: "compute-optimal" allocation — choosing sequential revision vs parallel best-of-N vs tree/beam search per difficulty — improves the efficiency of test-time compute scaling "by more than 4x compared to a best-of-N baseline," and "in a FLOPs-matched evaluation … test-time compute can be used to outperform a 14x larger model" [snell-tts]. The orchestration reading: which search topology to run is itself a routing decision (§2), conditioned on estimated difficulty. Large-model-once versus small-model-many is a real trade with a crossover set by task difficulty and verifier quality, not a dogma.

5. Parallel fan-out economics (supervisor / orchestrator-worker)

5.1 The measured numbers

Anthropic's multi-agent research system is the best-instrumented production supervisor [anthropic-multi-agent-research]; the content page quotes some of these, collected here with their analysis context:

• Quality: "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 their internal research eval.
• Cost: "agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats."
• Why it works: in their BrowseComp analysis, "token usage by itself explains 80% of the variance" in performance — fan-out is, first of all, a way to spend more tokens effectively by giving each batch of them a clean context window.
• Latency: "the lead agent spins up 3-5 subagents in parallel rather than serially" and "the subagents use 3+ tools in parallel"; together "these changes cut research time by up to 90%" for complex queries.
• The economic bar: "multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance."
• The over-decomposition failure: "early agents made errors like spawning 50 subagents for simple queries" — fan-out width is a tuned parameter, not a free good.

5.2 The token ledger

The orchestrator-worker ledger (arithmetic): total tokens ≈ orchestrator turns + Σ over workers of (system prompt + subtask context + exploration) + synthesis. What makes the pattern viable is the asymmetry between what workers burn and what the coordinator pays: each subagent "might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)" [anthropic-context-engineering]. Fan-out therefore multiplies system tokens (the ~15×) while dividing wall-clock time and conserving the coordinator's context window — the deeper context-isolation treatment is in agent-loops-planning-sota.md §10, and the context-efficiency economics in memory-sota.md §5.

5.3 Amdahl-style limits: the serial synthesis bound

Every supervisor run has a serial fraction — task decomposition, each orchestrator decision turn, the final synthesis — that parallel workers cannot compress: if fraction s of the work is serial, speedup ≤ 1/s no matter how many workers run (the standard formalization of Amdahl's argument; the 1967 paper argues it in prose — the IEEE reprint's editors note "it has no equations and only a single figure" — estimating that housekeeping overhead alone "would then place an upper limit on throughput of five to seven times the sequential processing rate" [amdahl-1967]). The live instance is Anthropic's synchronous orchestration: "the lead agent can't steer subagents, subagents can't coordinate, and the entire system can be blocked while waiting for a single subagent to finish" [anthropic-multi-agent-research]. Latency regimes for the parallel phase (arithmetic; the content page states both): a barrier (sectioning/voting) waits for the max over branches — "bounded by the slowest branch rather than their sum," so straggler variance is the enemy — while a pipeline sums stage latencies per task but overlaps them across a stream: throughput improves, per-task latency doesn't, and errors propagate forward (§7.1).

6. Topology formalisms

6.1 Orchestration graphs as state machines and DAGs

The formal frame the frameworks converged on: "Multi-agent systems can be modeled as graphs, with agents represented as nodes. In the manager pattern, edges represent tool calls whereas in the decentralized pattern, edges represent handoffs that transfer execution between agents" [openai-agents-guide]. LangGraph makes the graph explicit and typed — nodes are LLM/tool steps, edges are routing, state is shared channels (see agent-loops-planning-sota.md §5.2 for the durable-execution consequences); a subgraph — "a graph that is used as a node in another graph" — is the recursion that builds the content page's hierarchical (supervisor-of-supervisors) teams, communicating either through shared state keys or through explicit input/output transformations between different schemas [langgraph-subgraphs]. LangChain's current multi-agent taxonomy names five shapes — subagents, handoffs, skills, router, custom workflow [langgraph-multi-agent-docs] — and its subagents page restates the supervisor pattern with the context-isolation property attached: "a central main agent (often referred to as a supervisor) coordinates subagents by calling them as tools," where "each subagent invocation works in a clean context window, preventing context bloat in the main conversation" [langgraph-subagents-docs].

Mapped to the content page's patterns: supervisor = star graph; pipeline = path DAG; router = single-decision branch; swarm/handoff = state machine whose transitions are handoffs; blackboard/group chat = star wired through shared state rather than scoped messages.

6.2 Communication cost by shape

Counting channels (arithmetic): a star with n workers has n links, O(n); a chain has n−1; a full mesh has n(n−1)/2, O(n²). Tokens follow the links. In a shared-transcript group chat, each of n agents re-reads a transcript to which all n contribute, so per-round input tokens grow ~O(n²) in the agent count (each of n agents reads n−1 peers' turns) — the content page's "every agent paying for the entire transcript," priced. Mesh-shaped debate (§3.6) has the same quadratic core, which is what makes the sparsification results decisive:

• Sparse debate: "multi-agent debates leveraging sparse communication topology can achieve comparable or superior performance while significantly reducing computational costs" — concretely, neighbor-connected debate vs fully-connected: "+2% on the MATH dataset and maintains the same accuracy on GSM8K" while "the average input token cost for reasoning tasks is reduced by over 40%"; on alignment (Anthropic-HH), quality edges up while costs drop 50.0% and 53.3% [sparse-debate-paper].
• Learned pruning: AgentPrune performs "one-shot pruning on the spatial-temporal message-passing graph, yielding a token-economic and high-performing communication topology," achieving "comparable results as state-of-the-art topologies at merely $5.6 cost compared to their $43.7," integrating with existing frameworks at "28.1%∼72.8% token reduction" — plus 3.5%–10.8% better robustness specifically against two types of agent-based adversarial attacks [agentprune-paper].

Design rule: the mesh buys diverse evidence flow at quadratic token cost, and the measurements say most of that quadratic spend is redundant. Default to star or sparse topologies; earn the mesh.

6.3 Control transfer: handoffs as transitions

The swarm/handoff pattern is a state machine whose transition function the LLM invokes as a tool: "handoffs are represented as tools to the LLM," named transfer_to_<agent_name>, and by default "the new agent takes over the conversation, and gets to see the entire previous conversation history" unless an input filter scopes it [openai-agents-handoffs]. The selection heuristic between the two edge types of §6.1, from the same SDK: "use agents as tools when a specialist should help with a bounded subtask but should not take over the user-facing conversation. Use handoffs when routing itself is part of the workflow and you want the chosen specialist to own the next part of the interaction" [openai-agents-multi] — and, on determinism: "orchestrating via code makes tasks more deterministic and predictable, in terms of speed, cost and performance" [openai-agents-multi].

7. Failure math: reliability under composition

7.1 Chains compound multiplicatively

A k-step pipeline whose steps each succeed independently with probability p succeeds end-to-end with probability p^k (arithmetic): at p = 0.95, ten steps give 0.95¹⁰ ≈ 0.60 and twenty give ≈ 0.36 — the content page's pipeline "error propagation" failure mode, priced. The independence assumption errs in both directions. It is optimistic where steps interact: "actions carry implicit decisions, and conflicting decisions carry bad results" [cognition-no-multi-agents] — a wrong early decision doesn't just fail its step, it poisons the assumptions of every later one. It is pessimistic where feedback exists: gates, tests, and verifiers between stages catch errors before they propagate (§7.3).

The empirical anchor is METR's horizon metric: the "50%-task-completion time horizon" is "the time humans typically take to complete tasks that AI models can complete with 50% success rate," measured by fitting "a logistic model to find the time horizon at which each AI agent has a 50% chance of success"; that horizon "has been doubling approximately every seven months since 2019" [metr-time-horizons]. Success falling smoothly with task length is what p^k-style compounding looks like from the outside; the doubling horizon says frontier models keep raising the effective per-step p.

7.2 Reliability across trials: pass^k

τ-bench measures the orthogonal axis — the same task, retried: pass^k is the probability an agent succeeds in all k i.i.d. trials, and the headline is grim: "state-of-the-art function calling agents (like gpt-4o) succeed on <50% of the tasks" and "are quite inconsistent (pass^8 <25% in retail)" [tau-bench-paper] (metric details in agent-loops-planning-sota.md §3.3). The orchestration corollary (arithmetic): a supervisor whose w workers each succeed with probability p sees all of them succeed with probability p^w — fan-out multiplies exposure to per-agent flakiness exactly the way chains multiply per-step risk, unless the synthesis step can tolerate or repair individual worker failures.

7.3 What bends the curve — and what doesn't

Verification stages change the exponent's base: a best-of-n stage lifts a step's raw p toward 1 − (1−p)^n, verifier permitting (§3.3), and a gate that re-runs a step until an external check passes converts "wrong and propagated" into "wrong and retried" — latency and tokens buying back reliability. This is why the content page's pipeline gates and Anthropic's evaluator-optimizer workflow [anthropic-effective-agents] exist. Two verified boundaries: introspection is not a verifier — "LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction" [huang-self-correct] (the gate needs tests, execution, retrieval, or users; evidence review in agent-loops-planning-sota.md §4) — and correlated reviewers are weak gates: §3.2's confident-consensus-on-wrong-answers result [debate-paper] applies to LLM judges drawn from the generator's own model family. Cognition's counter-position closes the loop: for write-coupled work the reliability killer is decision coherence, not per-step p — "share context, and share full agent traces, not just individual messages"; prefer "a single-threaded linear agent" where "the context is continuous" [cognition-no-multi-agents]. When steps cannot be made independent, serialize them (the read-parallel / write-serial synthesis of agent-loops-planning-sota.md §5.4 and §10).

8. What to add to the knowledge base

Actionable additions to content/orchestration/index.md (status: reviewed — proposals for its next revision, not edits now) and the site:

1. Per-pattern "numbers boxes" on the orchestration page: router — UCB1 + the cascade rule
   • FrugalGPT's 98% [ucb1-paper] [frugalgpt-paper]; parallel/voting — 1 − (1−p)^n, the correlated-error caveat, and sparse debate's >40% token cut [codex-paper] [debate-paper] [sparse-debate-paper]; supervisor — the page already carries 4×/15× and the 80%-of-variance line; add the 90.2% quality figure, the 1,000–2,000-token summary figure, and the value-of-task bar [anthropic-multi-agent-research] [anthropic-context-engineering]; group chat — the O(n²) transcript-cost note.
2. New concept page orchestration-algorithms.html ("The Math of Coordination"): bandit routing, cascades, voting curves, UCT box, fan-out ledger, failure math — sharing the UCT material with search-and-planning.html proposed in agent-loops-planning-sota.md §9.
3. A cost row in the choosing-a-topology flowchart: expected token multiplier per branch (~1× single agent, ~4× agent, ~15× multi-agent [anthropic-multi-agent-research]).
4. A failure-math sidebar: the p^k table, pass^k, METR's doubling time horizon [tau-bench-paper] [metr-time-horizons]; cross-link from the loops brief's evals-page proposal (its §9).
5. Doc-rot note for the next content review: LangGraph's multi-agent docs no longer use the network/supervisor/hierarchical taxonomy the content page describes; the current official taxonomy is subagents / handoffs / skills / router / custom workflow at a new URL [langgraph-multi-agent-docs]. The page's claims should be re-attributed to the legacy docs or updated.

Sources (references.yaml format; all URLs verified 2026-07-09)

ucb1-paper: {title: "Finite-time Analysis of the Multiarmed Bandit Problem (Auer, Cesa-Bianchi, Fischer; Machine Learning 47, 2002)", url: "https://homes.di.unimi.it/~cesabian/Pubblicazioni/ml-02.pdf", accessed: "2026-07-09"}
uct-paper: {title: "Bandit based Monte-Carlo Planning (Kocsis & Szepesvári, ECML 2006 — UCT)", url: "https://www.lri.fr/~sebag/Examens_2008/UCT_ecml06.pdf", accessed: "2026-07-09"}
frugalgpt-paper: {title: "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance (May 2023)", url: "https://arxiv.org/abs/2305.05176", accessed: "2026-07-09"}
routellm-paper: {title: "RouteLLM: Learning to Route LLMs with Preference Data (Jun 2024)", url: "https://arxiv.org/abs/2406.18665", accessed: "2026-07-09"}
routellm-blog: {title: "RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing — LMSYS (Jul 2024)", url: "https://lmsys.org/blog/2024-07-01-routellm/", accessed: "2026-07-09"}
self-consistency: {title: "Self-Consistency Improves Chain of Thought Reasoning in Language Models (ICLR 2023)", url: "https://arxiv.org/abs/2203.11171", accessed: "2026-07-09"}
more-agents-paper: {title: "More Agents Is All You Need (Li et al., Feb 2024)", url: "https://arxiv.org/abs/2402.05120", accessed: "2026-07-09"}
moa-paper: {title: "Mixture-of-Agents Enhances Large Language Model Capabilities (Jun 2024)", url: "https://arxiv.org/abs/2406.04692", accessed: "2026-07-09"}
codex-paper: {title: "Evaluating Large Language Models Trained on Code (Codex — pass@k estimator, Jul 2021)", url: "https://arxiv.org/abs/2107.03374", accessed: "2026-07-09"}
lets-verify: {title: "Let's Verify Step by Step (OpenAI, May 2023 — PRM800K)", url: "https://arxiv.org/abs/2305.20050", accessed: "2026-07-09"}
tot-paper: {title: "Tree of Thoughts: Deliberate Problem Solving with Large Language Models (NeurIPS 2023)", url: "https://arxiv.org/abs/2305.10601", accessed: "2026-07-09"}
snell-tts: {title: "Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Model Parameters (Aug 2024)", url: "https://arxiv.org/abs/2408.03314", accessed: "2026-07-09"}
debate-paper: {title: "Improving Factuality and Reasoning in Language Models through Multiagent Debate (Du et al., May 2023)", url: "https://arxiv.org/abs/2305.14325", accessed: "2026-07-09"}
sparse-debate-paper: {title: "Improving Multi-Agent Debate with Sparse Communication Topology (Jun 2024)", url: "https://arxiv.org/abs/2406.11776", accessed: "2026-07-09"}
agentprune-paper: {title: "Cut the Crap: An Economical Communication Pipeline for LLM-based Multi-Agent Systems (AgentPrune, Oct 2024)", url: "https://arxiv.org/abs/2410.02506", accessed: "2026-07-09"}
amdahl-1967: {title: "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities (Amdahl, AFIPS 1967; IEEE SSCS authorized reprint)", url: "https://www3.cs.stonybrook.edu/~rezaul/Spring-2012/CSE613/reading/Amdahl-1967.pdf", accessed: "2026-07-09"}
metr-time-horizons: {title: "Measuring AI Ability to Complete Long Tasks (METR, Mar 2025)", url: "https://arxiv.org/abs/2503.14499", accessed: "2026-07-09"}
tau-bench-paper: {title: "τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (Sierra, Jun 2024)", url: "https://arxiv.org/abs/2406.12045", accessed: "2026-07-09"}
huang-self-correct: {title: "Large Language Models Cannot Self-Correct Reasoning Yet (ICLR 2024)", url: "https://arxiv.org/abs/2310.01798", accessed: "2026-07-09"}
cognition-no-multi-agents: {title: "Don't Build Multi-Agents — Cognition AI (Jun 2025)", url: "https://cognition.com/blog/dont-build-multi-agents", accessed: "2026-07-09"}
anthropic-effective-agents: {title: "Building Effective Agents — Anthropic Engineering (Dec 2024)", url: "https://www.anthropic.com/engineering/building-effective-agents", accessed: "2026-07-09"}
anthropic-multi-agent-research: {title: "How We Built Our Multi-Agent Research System — Anthropic Engineering (Jun 2025)", url: "https://www.anthropic.com/engineering/multi-agent-research-system", accessed: "2026-07-09"}
anthropic-context-engineering: {title: "Effective Context Engineering for AI Agents — Anthropic Engineering (Sep 2025)", url: "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents", accessed: "2026-07-09"}
openai-agents-guide: {title: "A Practical Guide to Building Agents — OpenAI (2025, PDF)", url: "https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf", accessed: "2026-07-09"}
openai-agents-handoffs: {title: "Handoffs — OpenAI Agents SDK Documentation", url: "https://openai.github.io/openai-agents-python/handoffs/", accessed: "2026-07-09"}
openai-agents-multi: {title: "Orchestrating Multiple Agents — OpenAI Agents SDK Documentation", url: "https://openai.github.io/openai-agents-python/multi_agent/", accessed: "2026-07-09"}
langgraph-multi-agent-docs: {title: "Multi-Agent — LangChain Documentation (current taxonomy: subagents, handoffs, skills, router, custom workflow)", url: "https://docs.langchain.com/oss/python/langchain/multi-agent", accessed: "2026-07-09"}
langgraph-subagents-docs: {title: "Subagents — LangChain Multi-Agent Documentation", url: "https://docs.langchain.com/oss/python/langchain/multi-agent/subagents", accessed: "2026-07-09"}
langgraph-subgraphs: {title: "Use Subgraphs — LangGraph Documentation", url: "https://docs.langchain.com/oss/python/langgraph/use-subgraphs", accessed: "2026-07-09"}