Delegation Topologies in Multi-Agent Orchestration

Frontier models now cluster so tightly on standard benchmarks that picking the "best" one barely moves the needle. AdaptOrch, published in February 2026, makes this the starting premise of its argument: once models converge in raw capability, the structure you build around them, not the model itself, becomes the thing that decides whether a system is fast, cheap, reliable, and fixable.

Topology as the primary design variable in multi-agent systems

Model selection used to be the whole game. Picking the smartest model available and pointing it at the task used to be enough, with the rest treated as plumbing. Swapping one for another barely changes the result. What changes the result is how work gets split up, handed off, and stitched back together, which is a separate question from which model answers any single piece of it. AdaptOrch names this directly: orchestration topology, the structural shape of how agents are coordinated, parallelized, and combined, now carries more weight for system-level performance than the capability gap between any two frontier models. Topology is the multiplier. Everything in this piece follows from that one claim.

The five canonical topologies and the structural properties each one encodes

AdaptOrch formalizes four shapes that cover most production systems: parallel, sequential, hierarchical, and hybrid. A fifth, debate, appears constantly in practice as a variant of parallel with a reconciliation step bolted on. Each one commits a system to a different set of tradeoffs before a single token gets generated.

A sequential pipeline runs agents in a fixed order, like an assembly line where each station only sees what the last one handed it. Control moves one direction. Each step gets focused, local context, which keeps individual reasoning clean, but a mistake early in the chain rides forward into every step after it, and total latency is the sum of every step in the line.

A parallel fan-out sends independent subtasks to multiple agents at once and combines the results afterward. Wall-clock time drops to roughly the length of the slowest branch instead of the sum of all of them, which is the entire appeal when subtasks don't depend on each other. The cost scales with how many branches you run, so the speed comes at a price that grows linearly with the width of the fan-out.

A supervisor hierarchy puts one coordinator agent in charge, handing out non-overlapping pieces of work to specialist agents and synthesizing what comes back, the way a project manager assigns tasks without doing the tasks themselves. The supervisor holds the global picture while each worker only needs to understand its own slice. When a worker fails, the supervisor sees it and can reroute, which gives this shape a failure-handling advantage the other patterns don't have by default.

Debate sends the same question to multiple agents on purpose, lets them disagree, and routes the disagreement to an adjudicator that reconciles the conflicting answers. Structurally it's a fan-out with a mandatory reconciliation step at the end. It raises reliability on questions where the answer is genuinely contested, at a cost premium that's hard to justify outside of exactly those cases.

A recursive swarm, the pattern WebSwarm builds around, treats orchestration as progressive, recursive delegation: each node in the system either solves its piece directly or spawns child nodes to go deeper, passing evidence back up the chain. Nothing about the decomposition is fixed in advance. The structure of the work and the collaboration between agents evolve together as the system runs, which makes this the right shape for tasks where you genuinely don't know how deep the problem goes until you start digging.

Four structural archetypes underlie the five patterns, chain, star, tree, and general graph, and each one carries predictable consequences for how local the context stays, how wide the parallelism can go, and how far a single failure can spread.

How task structure should determine topology selection

Topology choice can be derived from the shape of the task itself. AdaptOrch's central contribution is a routing algorithm that takes a task decomposition, maps it into a directed acyclic graph, and picks a topology based on three properties of that graph: how wide the parallelism is, how deep the critical path runs, and how tightly the subtasks depend on one another. The algorithm runs in time proportional to the number of nodes and edges in the graph, so the routing decision itself doesn't become the bottleneck.

The diagnostic is simple enough to apply by hand before reaching for any tooling. If a task breaks into pieces that don't depend on each other, route to fan-out or hierarchy. If each step strictly requires the output of the one before it, route to a pipeline. If solving part of the task reveals subtasks you couldn't have known about at the start, route to something recursive or hybrid. AdaptOrch's empirical results back this up: topology-aware orchestration beats static single-topology baselines by 12 to 23 percent, using the exact same underlying models in both conditions. The gain comes from the wiring, not the intelligence sitting inside each node.

Debate and recursion are both special cases of this same logic. Debate earns its cost premium only when getting a contested question right matters more than the extra model calls it takes to get there. It isn't a default pattern, it's a tool for a narrow set of high-stakes, ambiguous questions. Recursion earns its place when the task tree can't be specified before execution starts. WebSwarm argues that for tasks that are both deep and wide, committing to a fixed topology at query time is a structural error, not just a missed optimization, because the system needs room to expand its own decomposition as evidence comes in.

One might argue this whole framework assumes something unrealistic: that you know the task's structure well enough to route it correctly before you've even started working on it. That's a fair objection. Uno-Orchestra answers it by refusing to treat decomposition and dispatch as two separate decisions made at two separate times. Instead, a single orchestration policy learns to decide, jointly, whether to break a task down, how deep to take that breakdown, and which model and primitive pair should handle each resulting piece, all trained end to end.

Why static topologies fail as task complexity grows

Fixed topologies make a bet upfront: that the shape of the collaboration can be decided before the work starts. Complex tasks don't cooperate with that bet, because they tend to reveal their own structure gradually, as earlier steps turn up what the later steps actually need to be. Forcing a flat decomposition onto a task like that squeezes the whole multi-level structure into a single agent's trajectory. The system that was supposed to be a multi-agent swarm ends up behaving like one agent working alone.

WebSwarm names three specific patterns behind this failure. Shallow recursive depth means subtasks several layers down only become visible once the layers above them get solved, so a system that commits to a fixed depth at the start simply can't see that far ahead. Limited collaboration adaptability means a single global strategy, whether that's serial execution, parallel fan-out, or aggregation, gets imposed on every node even when different nodes are chasing genuinely different objectives. Insufficient evidence-grounded expansion means the system has no way to revise its own decomposition once search results start contradicting the plan it made at the outset.

Single-call routers run into the mirror-image problem. They make one routing decision per query. That means they miss parallel structure buried inside a single complex task and have no mechanism for trading decomposition depth against the budget available to execute it. Yuan et al., in a September 2026 paper, pushes on this directly: adding more agents to a system doesn't reliably make it better. Past some point, coordination overhead and compounding errors start outweighing whatever benefit the extra parallelism was supposed to buy, and where that inflection point sits is itself a function of the topology, not the agent count on its own.

Debuggability takes the quiet hit in all of this. A static topology that fails gives an engineer a bounded, traceable failure surface, because the structure was fixed and known in advance. A dynamically instantiated swarm that fails scatters that failure across nodes that were themselves created on the fly, with no fixed map to trace back through. Observability has to be treated as a core design constraint from the start of the build, not something added once something breaks in production.

Learned and adaptive orchestration for topology selection

The research response to these failures has converged on one idea: stop treating decomposition and dispatch as separate decisions and let a single learned policy handle both together. Uno-Orchestra builds this directly. One causal language model backbone produces the task decomposition and the per-subtask routing decision, meaning which model and which primitive handle each piece, in the same assistant turn. That removes the redundant back-and-forth that happens when a planner and a dispatcher are separate components passing context between each other.

Getting there takes two training stages. The first is supervised fine-tuning on trajectories distilled from a stronger teacher model. The second refines the policy on a harder pool of examples using AGENTIC-GRPO, a multi-turn extension of GRPO that hands out intermediate rewards tuned to the many different ways a task can be decomposed. Uno-Orchestra reaches 77.0% macro pass@1 across a 13-benchmark suite, at roughly a tenth the per-query cost of the strongest workflow baseline it was tested against. That result matters because it breaks an assumption that's held for a while in this field, the idea that accuracy and efficiency trade off against each other. When routing is learned jointly instead of hand-built, that tension loosens.

WebSwarm tackles a different half of the same problem. Rather than learning a router that picks among a fixed menu of topologies, it gives each node in the swarm a local search mode that governs how that specific node organizes its own search and collaboration, whether that means a quick fact lookup, wide coverage across many sources, deep pursuit of a single clue, or open-ended enumeration of possibilities. The mode gets matched to what that node is actually trying to do, not inherited wholesale from a global strategy set for the whole system.

These two approaches address different layers of the same system. Uno-Orchestra optimizes which route a task should take once you're looking at it. WebSwarm optimizes how a given node should behave once it exists within the swarm. Between them, a system gets an answer to both what to do and how to do it locally. Neither one, on its own, solves the harder problem that produces both of them: tracing a failure through a structure that didn't exist in any fixed form until the moment the system built it.

Requirements for an agent runtime layer to make any topology operationally viable

None of this works without infrastructure built to carry it. Picking the right topology on paper means little if the system running it can't enforce isolation between agents, hold state persistently, schedule work sensibly, and surface what's happening while it happens. Agentic Services Computing frames this as a genuine shift in what a "service" even is. Agents aren't passive endpoints waiting to be called the way a traditional API is. They interpret delegated intent, hold context over long stretches of time, call their own tools, and revise their own plans based on what comes back. The infrastructure underneath has to be built for that behavior, not retrofitted to tolerate it.

The old abstractions, processes, threads, files, sockets, and resource controllers, were built for workloads that look nothing like this. Agent runtimes need their own primitives: sandboxing that can contain code an agent generates on the fly, scheduling that understands the semantic weight of a task rather than just its CPU footprint, long-lived state that can hold context and episodic memory across a session, and observability that works in real time.

Memory needs differ by topology. No single state architecture works across all five patterns. A sequential pipeline can carry everything it needs forward in context, one step passing what it knows directly to the next. A parallel fan-out needs a shared external store that every branch can read from and write to without stepping on the others. A recursive swarm needs state that's hierarchical by design, so a node several layers deep can pass evidence both upward to its parent and sideways to siblings as the search unfolds. Picking the wrong state model for the topology relocates the coordination problem into whichever layer now has to compensate for it.

Observability carries even more weight once a topology moves past a simple pipeline. Knowing which agent received which input, what it handed back, what the next agent was told to do with that, and where exactly a failure started requires instrumenting the delegation graph itself, not just logging each individual model call in isolation. Without that, a swarm that fails becomes nearly impossible to reconstruct after the fact.

The practical tradeoff map: choosing a topology for a real workload

Every topology carries its own fixed profile across the same four properties: latency, cost, failure containment, and debuggability. The right pick depends on which of those four is the actual constraint on the workload in front of you, not on which pattern sounds most sophisticated.

Choose a sequential pipeline when the steps genuinely have to happen in order and each step's output is the only thing the next step needs. Debuggability is at its best here, since failures stay local to a single, identifiable step in a known sequence. Latency is the weak point, since a long chain adds up every step's time one after another. This shape fits document processing, report generation, and any workflow where getting the order right isn't negotiable.

Choose a parallel fan-out when the subtasks are genuinely independent of each other. Latency drops to roughly the length of the slowest branch. Cost rises with every branch added. This shape fits research aggregation, parallel code review, and any workload built around combining several independent specialist opinions into one answer.

Choose a supervisor hierarchy as the default for most production systems. The supervisor carries the global picture while each worker only has to manage its own local piece, a failed worker is visible to the supervisor and can be rerouted, and the system scales by adding more specialist workers without redesigning the whole structure. This shape fits multi-domain workflows, incident investigation, and anything that needs synthesis across several different areas of expertise.

Reach for debate only when getting a contested question right is worth paying a real cost premium for. That covers high-stakes factual verification, policy decisions, and adversarial robustness testing, a narrow set of cases to reach for deliberately.

Reach for a recursive swarm when the task's structure genuinely can't be specified before execution starts. Deep research and investigative workflows fit here, along with anything where early results keep revealing subtasks nobody could have planned for in advance. The cost is visible in operational complexity and a heavier observability burden, and that cost has to be absorbed at the runtime layer rather than left for an engineer to untangle after something breaks.

Model capability got the industry this far. The shape of the system carries it the rest of the way.