Workflow and topology search

A UCLA group posted a system in early September that picks a multi-agent topology for each incoming query from a codebook ¹. They trained a vector-quantized autoencoder to compress successful agent graphs into discrete codes, then varied how many codes the model could keep. Growing the codebook from 8 entries to 64 didn't produce more variety. However much capacity was available, the topologies left after training collapsed to about six distinct graphs ¹.

The final system, Codebook Agent, uses a 16-entry codebook, a reward-weighted MLP that maps a query embedding to a distribution over codes, and a second MLP that reranks the decoded candidates. It has the best accuracy on all six benchmarks in the paper (84.6 average against 83.0 for the strongest prior method), picks a topology in 2.4 ms, and uses 21.9–33.2% fewer LLM tokens than the graph generators it replaces ¹.

Since 2024 the subfield had assumed that the space of possible multi-agent organizations is large, that the right one depends on the query, and that finding it is worth running a search. If six graphs cover what works, then the elaborate conditional graph generators built over the previous two years were spending their expressiveness on distinctions that made no difference. The authors also explain why. The message-passing scorers those generators use are invariant to adjacency when every agent has the same profile, so when every node runs one model with a similar prompt, the scorer can't tell two wirings apart ¹.

Two other September papers found the same thing from different directions. A study of sparse multi-agent debate had each agent debate two freshly sampled distinct peers every round, with no learned topology at all. That setup "provides a surprisingly strong baseline and consistently improves the accuracy-cost trade-off," and the authors conclude that learned topology adaptation should be tested against simple routing and stopping baselines before its complexity is justified ². An audit of methods that make multi-agent systems cheaper by pruning agents or edges found that many reported gains depend on the setup and "may arise from structural collapse, disabled tool pathways, or starting systems where random pruning already preserves accuracy" ³.

Codebook Agent is a paper in favor of topology search that wins by searching less. Put it next to those two audits, and next to the budget-controlled studies from earlier in 2026 that found a single agent matching homogeneous multi-agent systems at equal compute ^4,5, and I think it supports a narrower conclusion than its authors draw.

For a team made of copies of one model, the detailed structure of the graph hardly affects accuracy. Two coarser choices do: how much collaboration a problem gets, and whether the team includes models that really differ. The systems with large gains that held up learned the second choice with a small trained orchestrator, and the shipped product that comes closest to "an agent designs its own team" does no offline search at all.

A multi-agent system (MAS) is a harness with more than one model call in its control flow. It has roles (planner, coder, critic), edges (who reads whose output) and an execution order. By 2024 the catalog of hand-designed setups (debate, ensembles, reflection loops, role-playing software teams) was long, and picking one was manual work. Automated design treats the choice as an optimization problem. What gets improved is the workflow, stored outside the weights as code, a graph or text, so in this series' terms it is non-parametric self-improvement: a proposer suggests a new organization, an evaluator scores it on held-in tasks, and the loop keeps the better one.

The history is short. ADAS (August 2024) had a meta-agent write new agents as Python code, keep the good ones in an archive, and iterate. Its discovered agents beat hand-designed baselines and, unusually, kept their advantage on held-out domains and models ⁶. AFlow (October 2024) replaced open-ended generation with Monte Carlo Tree Search over workflows written as code, and let small models beat GPT-4o on specific tasks at 4.55% of the cost ⁷.

MaAS (February 2025) stopped looking for one design and learned a distribution over architectures instead, sampling a cheap system for easy queries and a larger one for hard queries at 6–45% of the inference cost of earlier systems ⁸. By mid-2025, designing a system per query was the default, whether through an inference-time loop that designs and critiques (MAS-Zero ⁹) or a trained generator that emits a system in one pass. Everything in 2026 builds on that framing.

The naive version of this loop runs into problems that shaped what came next. The search space is combinatorial, because every role, prompt, edge and loop bound multiplies the options. Evaluation is expensive, because scoring one candidate means running it over a validation set with several LLM calls per example, and the rule for what to keep is weak.

Most papers keep the design that scores highest on a validation split drawn from the same benchmark they report results on, the same greedy rule this series keeps finding in prompt optimization (06) and harness evolution (09). Run long enough against a small validation set, a search will find organizations that fit that set. Researchers answered the size of the search space and the cost of evaluation with better representations and cheaper search, and mostly put off the weak keep rule until 2026, when the budget-matched studies came out.

Most papers in the subfield still generate graphs. RGA-Designer (August) took an existing autoregressive topology generator, trained a reward model that scores both task correctness and structural compactness, and fine-tuned the generator against it RLHF-style. It matched the original generator's accuracy while cutting token use by 20.5% on average ¹⁰.

K-GAT (August) conditions graph generation on retrieved evidence as well as the model's parametric knowledge, and reports beating an LLM-Debate baseline on GPQA by 15.7% in accuracy with less than half the tokens ¹¹. MAGIC (September) builds a graph step by step, choosing for each functional role whether to use a single agent or a reusable group. It trains that construction policy with RL plus potential-based reward shaping to cope with sparse final-answer rewards, and reports beating state-of-the-art baselines across eight benchmarks ¹².

Most of these headline improvements are cost reductions at equal accuracy, and the baselines are other graph generators or fixed debate setups. No paper in this group compares against a single agent given the same tokens. Codebook Agent's collapse explains why the wins show up as savings: if the useful set of graphs is small, a better generator mostly learns to stop adding edges.

One 2026 paper measures what topology choice buys by looking only at the coarse decision. Yunsong Hong evaluated five code-generation topologies, from a single agent to hierarchical collaboration, on 614 problems from APPS, HumanEval+ and LiveCodeBench ¹³. Hierarchical collaboration beat a single agent by 2.4 points of pass@1 on the easiest third of problems and by 21.1 points on the hardest third, while costing about 10 times as many tokens throughout. A math study on 400 problems found a gap that widened in a similar way, from 2.5 to 20.9 points ¹³.

Hong's selector, DATS (Difficulty-Aware Topology Selector), predicts each topology's chance of solving a problem and picks the one with the highest predicted success minus a cost penalty. Because the penalty is a single number, any router can be recalibrated to the same spend. Under that budget-matched protocol, six cost-aware methods spread across 21.6 percentage points, and two baselines that had led DATS fell behind once they were calibrated to its budget ¹³.

Fixed at 40% of the always-hierarchical cost, DATS reached 77.7% pass@1, against 73.6% for always-hierarchical and 74.3% for the strongest learned competitor, and the 4.1-point gain held across four backbones. Replacing its 39 interpretable features with a graph network or a pretrained encoder moved accuracy by at most 1.3 points ¹³.

DATS sharpens the budget critique. Under a matched budget, collaboration is worth a lot on hard problems and almost nothing on easy ones, and a simple router can tell which is which. The decision that pays off is one number, how much structure to spend on a problem, which is what you would expect if six graphs cover the useful space.

Another group of systems builds or edits the workflow while it runs. MANTA (July) starts from a task-conditioned topology, watches the collaboration traces, and makes bounded structural edits (roles, links, order, visibility, validation paths) while holding the agent budget fixed. It averages 74.0 across five benchmarks, 5.8 points above the strongest baseline ¹⁴.

ReActNet (September) compiles a query into a sequence of directed communication graphs, one per reasoning stage, in which every edge has a natural-language instruction for what the source agent should tell the target. It needs no training and reports improving on fixed-topology and learned-topology baselines at competitive cost ¹⁵. AOrchestra (February) treats every sub-agent as a tuple of instruction, context, tools and model and creates one per subtask, and it reports a 16.28% relative gain on GAIA, SWE-Bench and Terminal-Bench with Gemini-3-Flash ¹⁶. The three are never tested against a single agent at matched compute, and MANTA's fixed agent budget comes closest.

A third group writes what the search learns down as prose. ABSTRAL (March) keeps the MAS architecture in a natural-language document that it refines by comparing successful and failed traces. On SOPBench (134 bank tasks with a deterministic oracle) it reached 70% on validation and 65.96% on test with GPT-4o, and a design document transferred to a new domain matched, after one iteration, what a cold start reached at its third ¹⁷.

Skill-MAS (June) stores orchestration ability as an evolvable "Meta-Skill" and reports that Meta-Skills transfer to unseen tasks and LLMs, though its abstract gives no headline numbers ¹⁸. Both follow the pattern from report 08: lessons written down as readable text are cheap to keep and to move.

The systems with the largest gains stopped treating the workflow as the thing to search. They train a small model to act as a manager. At each step it decides which worker to call, with what instruction, and which earlier messages that worker gets to see.

The workers are frozen models, often from different labs. The routing policy is stored in the orchestrator's weights while its outputs are text for other models, so these systems are hybrids. They appear here because this is where topology search ended up.

Sakana's Fugu

Sakana's Fugu is the example to look at, and its releases this summer show what it takes to keep such a system current. Fugu is built on Conductor, a 7B model trained with RL to write natural-language workflows over a pool of frontier workers: which agent to call, what subtask it gets, and which earlier messages it can see. Training randomizes the worker pool, and the Conductor can call itself, which gives recursive orchestration ^19,20.

The ICLR 2026 paper reported 83.9% on LiveCodeBench and 87.5% on GPQA-Diamond, higher than any individual worker in its pool, from a modest RL budget of 200 iterations of 4 questions with 64 rollouts each ¹⁹. Fugu became generally available on June 22 as a single model API that calls a pool of LLMs internally, itself included, trained with a combination of fine-tuning, evolutionary algorithms and RL ^21,22.

A month later Sakana released Fugu-Ultra v1.1, "upgraded to incorporate the latest frontier models," with gains of up to 7.9 points over v1.0 at the same price, and added Claude Code-compatible endpoints so the orchestrated pool can be the model behind Claude Code ²³. Two more versions followed on September 11 ²⁴. Fugu Max routes to "the leanest model capable of solving" a task across a larger pool of open and specialized models, including NVIDIA Nemotron, and costs $2 per million input tokens and $6 per million output tokens; Sakana puts the output price 40–60% below Sonnet 5, GPT 5.6 Terra and Kimi K3.

Fugu Ultra v2, according to Sakana, has the best or joint-best score on five of eight benchmarks, including 48.3 on the Chartography visual-reasoning benchmark against 27.3 for Opus 5 and 29.5 for Fable 5 ²⁴. Sakana points out that Fable 5, Fable 5.1 and GPT-6-Astra are not in Ultra v2's pool (training cutoff August 28, 2026). All of these numbers come from the vendor, several on Sakana's internal benchmark, and none has been replicated independently.

What I find informative is how often Sakana ships. The orchestrator's policy encodes what a specific pool of workers is good at, so when the pool changes Sakana has to retrain or re-tune it. That is three versions in under three months, each described as an orchestration upgrade over new workers. The question of what happens to a routing policy when the models under it change is still open in research, and for now Sakana handles it by running the retraining loop itself.

Research orchestrators with explicit costs

The research versions make cost an explicit part of the objective. EASy (August) trains an LLM orchestrator with RL and gives it capability and cost profiles for a mixed set of executors. It breaks tasks into milestones, builds dependency-aware execution graphs, assigns executors and runs independent steps in parallel, and it is trained with tree-structured rollouts and rewards for correctness, efficiency and trajectory completeness. It reports better performance-efficiency trade-offs than strong agentic baselines on math, embodied and deep-research benchmarks ²⁵. The precedent is NVIDIA's ToolOrchestra (November 2025), whose 8B orchestrator scored 37.1% on Humanity's Last Exam against GPT-5's 35.1% at 2.5× lower cost ²⁶.

Kimi K2.5 (February) brought the recipe into a frontier training run. Its Parallel-Agent RL (PARL) trains an orchestrator to spawn and assign parallel sub-agents while keeping the sub-agents frozen, so credit goes only to the orchestrator. The swarm scores 78.4% on BrowseComp against 60.6% for single-agent K2.5, and runs 3–4.5× faster on WideSearch as target item-F1 rises from 30% to 70% ²⁷.

SwarmBench (August) now measures models as swarm orchestrators on accuracy, efficiency, cost and process quality. It finds large differences in orchestration ability between current models, and a simple method that extracts and replays experience improves orchestration consistently ²⁸. If orchestration ability differs by model and improves with replayed experience, labs can train it, and PARL shows at least one lab already does.

Two earlier 2026 systems sit outside this group. CORAL (April) ran several long-lived agents asynchronously on open-ended optimization problems, each in an isolated workspace with a shared memory of attempts, notes and skills, and every attempt a git commit scored by a separate grader. It reported state-of-the-art results on 10 tasks with 3–10× higher improvement rates than fixed evolutionary search, including a kernel benchmark cut from 1,363 to 1,103 cycles by four agents ³⁴.

CORAL's structure is flat and designed by hand, and its gains come from the grader and the shared memory, which makes it closer to evolutionary search with parallel workers than to designing an organization. Hetero-Designer (ACL 2026) framed automated design of teams built from different LLMs as a problem of its own ³⁵. That is the setting the budget critiques leave open, and it has no budget-matched study yet.

The table sorts 2026 results by what they were compared against. That comparison says more about how far to trust a result than the headline number does.

The bulk of the 2026 graph papers (K-GAT, RGA-Designer, MAGIC, MANTA, Codebook Agent) compare a generated topology against other topologies. Their gains are real in the narrow sense that the new design beats the old one on that benchmark, mostly by using fewer tokens. A comparison like that can't tell you whether the organization made a difference or whether the baseline was wasting calls.

Conductor, ToolOrchestra and the Fugu releases compare against strong single models and report cost. I'd weigh these results above the graph papers, because they beat what a practitioner would otherwise use. All of them route among different models, though, so their advantage probably comes from choosing models more than from graph structure, and the Fugu numbers come from the vendor.

I trust the studies that hold compute fixed more than either group. The January and April critiques find that the advantage of homogeneous multi-agent systems disappears at equal compute. DATS shows where collaboration still pays at matched spend: on hard problems, which a cheap difficulty router can pick out.

The September topology-versus-diversity study, under a fixed three-call budget on multilingual emotion detection, found that how the agents were differentiated (sampling, role prompts, or separately fine-tuned specialists) moved results more than how they were connected ²⁹. My conclusion from all three kinds of comparison is that searching over the wiring of identical agents saves tokens and adds little capability, and that capability comes from deciding how much to collaborate and who the collaborators are.

Almost every system in this lineage also searches on a validation split of a benchmark and reports on the test split of the same benchmark, and the RL orchestrators train and evaluate on the same benchmark families ¹⁹. ADAS's cross-domain transfer ⁶ and ABSTRAL's design-document transfer ¹⁷ are the exceptions. ABSTRAL also measured the cost of coordination directly: its ensemble configurations achieved only 26% turn efficiency ¹⁷. A searched topology that adds agents pays that cost on every query, and a codebook of small graphs pays less of it, which is one explanation for why Codebook Agent improved token use and accuracy at the same time ¹.

The budget critique came in two papers in early 2026. Xu et al., in an ICLR 2026 paper, ran homogeneous workflows (one base model playing several roles) against a single agent on seven benchmarks covering coding, math, QA, domain reasoning and planning. The single agent matched the workflows and was more efficient, because one context reuses its KV cache while separate agents re-encode shared information ⁴. The authors stated the limit of their own result: a single model cannot simulate a team of base models that really differ.

In April, Dat Tran, Douwe Kiela and colleagues supplied the theory ⁵. By the data processing inequality, passing information through extra processing steps can't increase what it tells you about the answer. So with a fixed reasoning-token budget and perfect use of context, a single agent is at least as information-efficient as a multi-agent arrangement of the same model. Across Qwen3, DeepSeek-R1-Distill-Llama and Gemini 2.5 on multi-hop reasoning, single agents matched or beat multi-agent systems at equal thinking tokens, and multi-agent systems became competitive only when context use degraded or when they got more compute ⁵.

The reply to both papers is that "perfect context use" fails on exactly the tasks where teams help. Salesforce's MASBENCH (January 2026) varies tasks along depth, horizon, breadth, parallelism and robustness, and finds that multi-agent gains depend on task structure and don't hold across the board ³⁰. Kimi's swarm results on wide search ²⁷ and DATS's gains on hard problems ¹³ are cases where one context stops being enough. So the critiques don't show that teams are useless. They show that a homogeneous team on a task that fits in one context buys nothing a single agent with an equal budget couldn't get, and most topology benchmarks are exactly that setting.

The September efficiency audit applies this to the papers that report cost savings ³. It re-ran representative pruning and compact-structure methods with a shared backbone, agent registry and runtime, across controlled variations in topology, scale, depth and tool use, on tasks chosen because they need a multi-agent system. Many of the reported gains depended on method-specific prompts and starting topologies. Some came from the method collapsing the structure, switching off tool pathways, or starting from a system so redundant that random pruning kept the accuracy too.

The random-routing debate study arrives at the same point from the other side, showing that a policy with no learned structure is a strong baseline that learned topology control often fails to beat ². Both match the July finding, detailed in report 09, that evolved harnesses did not consistently beat simple test-time scaling once someone ran the matched baseline ³¹.

Teams also fail at the handoffs between agents. MAST (March 2025) sorted 1,600+ traces and found multi-agent failures clustered into design issues, inter-agent misalignment and verification failures ³². Researchers pinned down one mechanism in August ³³. When an upstream interaction is compressed into a handoff summary, the summary keeps the operational facts and drops the boundary metadata that says how those facts may be used, a failure the authors named "summary collapse."

Uncompressed free-text handoffs kept boundary markers at a survival score of about 0.80. A 25-word budget dropped that to about 0.57 while the facts themselves were almost all kept, and the two scores were nearly uncorrelated. Vague constraints leaked in 73% of GPT-5-mini cases and 50% of DeepSeek-R1-32B cases, and explicit constraints cut leakage below 15% across the three models tested.

A single-agent control still leaked, so topology doesn't explain all of it, but every added edge is one more compression step. Topology search optimizes task accuracy and cost, and nothing in that objective can see what a handoff dropped.

No production system I know of runs offline topology search. The closest thing in a shipped product is Claude Code's dynamic workflows, released with Claude Opus 4.8 in late May 2026 ^36,37. When a task is big enough, Claude writes a JavaScript harness for it with primitives such as agent(), pipeline() and parallel(). The harness splits the job into phases, fans work out to isolated sub-agents and collects the results.

A run executes up to 16 agents concurrently by default, up to 1,000 agents in total, and up to 4,096 items per fan-out ³⁶. Anthropic titled the announcement "a harness for every task" ³⁷, and that is what it does: the model generates the topology fresh for each job instead of retrieving one from a searched library.

Anthropic kept adjusting it through September. Version 2.1.269 (September 11) added a setting that raises the per-run concurrency limit anywhere from 1 to 256 agents, and version 2.1.271 (September 14) changed the default workflow size to small on Pro plans and lowered the "medium" size guideline from 15 agents to 10 ³⁸.

The current documentation describes an ultracode effort level under which Claude plans a workflow for every substantive task in a session, bundled workflows such as /deep-research whose verifier agents cross-check claims, and distribution of saved workflows through plugins ³⁶. The September changes all go toward smaller default teams, with scale available when a task needs it, which is where DATS ended up too, reached here by tuning a product.

Whether a person approves a workflow depends on configuration. Launching one is an ordinary permission-gated tool call. The default manual and accept-edits modes ask the user before each run. Bypass-permissions mode, headless claude -p runs and Agent SDK configurations can remove that prompt, and in auto mode a classifier approves it ³⁶.

So if the operator has set it up that way, a model can design and launch a 1,000-agent job without anyone clicking anything. People come in at a different point: when a run goes well, the user can save it with a keystroke as a reusable command under .claude/workflows/, and over time that builds a library of vetted harnesses ³⁶. The model proposes the workflow, and a person picks what goes into the library.

Fugu is the commercial case of a learned policy choosing the organization per request, and its Claude Code-compatible endpoints from July put the two products in the same terminal ²³. What shipped there is a trained router over different models, retrained as the pool changes, and no searched graph.

The major agent frameworks are designed by hand. The OpenAI Agents SDK composes agents through explicit handoffs ³⁹, Google's ADK offers sequential, parallel and loop workflow agents that developers wire themselves ⁴⁰, and LangGraph defines graphs in code ⁴¹. They don't run topology search by default, and in my view that isn't practice lagging behind research. Frontier models write a decent harness for a task on the fly, and the budget evidence says an offline-searched graph over copies of one model would rarely beat it.

For a multi-agent system built today, I would start with a single agent and a strong model, add a difficulty-based router that spends collaboration only on hard problems, and put different models on the team before spending any effort on how the agents are wired together.

Does routing across several frontier models beat the best single model at an equal budget? The critiques cover homogeneous teams, and the positive results come from routing among different models. DATS shows what a budget-matched protocol looks like for one model and five topologies ¹³.

A learned router over several frontier models still needs the same test: the best single model given the same dollars and tokens, sampled as many times, on held-out tasks. No published study runs it. Until someone runs that, Conductor-style and Fugu-style results stay in the second group of comparisons above, and there is no way to separate how much of their advantage comes from model selection, how much from extra calls and how much from structure. The same benchmark would test whether Codebook Agent's collapse to six graphs still happens once the agents differ.

How do model-designed teams fail in deployment? Claude Code's dynamic workflows and Fugu are the two large deployments of organizations designed by a model, and neither has published success rates, failure taxonomies or cost per task against single-agent runs. Whether 1,000-agent runs launched without a human prompt fail in the ways MAST and the handoff study describe (unverified handoffs, dropped constraints) is an empirical question with safety consequences.

What happens to an orchestrator when the model pool changes? A routing policy encodes the strengths of the workers it was trained on. Conductor randomizes pools during training ¹⁹, and Sakana's summer releases show a vendor re-tuning the orchestrator every month or two as new workers arrive ^23,24. Whether that retraining is cheap enough to keep up, whether routing policies transfer across model generations, and whether an orchestrator can adapt in context from a few trial calls will determine whether these hybrids stay economical. For orchestrators, this is the series-wide question of whether what a system learned still works after a model upgrade.