VI · Multi-AgentExperimental·

Dynamic Topology Routing

also known as Adaptive Agent Topology, Optimizable Agent Graph, Runtime Graph Rewiring

Form and dissolve the connections between agents at runtime by matching the task to candidate collaborators, instead of committing the multi-agent system to a fixed chain, star, or mesh up front.

Context

A multi-agent system has a pool of specialised agents. The classic designs wire them into a fixed topology — a sequential chain, a star around an orchestrator, or a fully connected mesh — chosen before any task arrives. Different tasks, though, want different communication structures: some need a tight pipeline, others a wide fan-out, others a small debate among three peers. A topology that fits one task wastes messages or drops needed links on another.

Problem

A fixed inter-agent topology is a compromise across all tasks the system will ever see. A mesh pays quadratic message and token cost even when a chain would do; a chain serialises work that could fan out; a star bottlenecks on its hub. Hard-wiring the structure at design time forces every task through the same shape, so some tasks over-communicate and others lack the links they need.

Forces

  • Different tasks want different communication shapes; one fixed topology fits none of them well.
  • Denser topologies raise coordination quality but cost messages and tokens quadratically.
  • Rewiring at runtime adds a routing decision that itself can be wrong or slow.
  • The agent pool and their competencies are known; which links matter is task-specific.
  • An adaptive graph is harder to reason about and debug than a static one.

Example

A research platform keeps a pool of a dozen specialist agents — retrieval, code, math, critique, writing. For a simple lookup it wires a two-agent chain; for a contested claim it stands up a three-agent debate clique; for a survey it fans out to five retrievers and a synthesiser. The same pool serves all three because a router reads each task and instantiates only the edges that task needs, instead of forcing everything through one standing mesh.

Diagram

Solution

Therefore:

Separate the agent pool from the communication graph over it. For each task (or each step), a routing layer scores candidate agents against the current subtask — by capability description, embedding similarity, or a learned router — and instantiates only the edges needed: a chain when the work is sequential, a fan-out when it is parallel, a small clique when it needs debate. As the task evolves, edges are added and dropped. Approaches range from per-step semantic matching (DyTopo) to treating the whole topology as an optimisable graph trained end to end (GPTSwarm). The static chain, star, and mesh become special cases the router can choose, not the only option.

What this pattern forbids. Agents must not assume a fixed set of peers or a standing communication structure; who they talk to is decided by the routing layer per task and may change between steps. An agent must not open links the router has not granted for the current subtask.

And the patterns that stand alongside it, or against it —

  • alternative-toOrchestrator-Workers★★— An orchestrator dynamically breaks a task into subtasks at runtime and delegates each to a worker LLM, then synthesises results.
  • complementsDecentralized Swarm Handoff★— Agents in a swarm decide handoffs to peers based on a shared protocol with no central coordinator; specifically about agent-initiated handoff protocols, not topology.
  • complementsContract Net Protocol★★— Classical bid-based multi-agent task allocation: a manager broadcasts a task announcement, contractors submit bids, and the manager awards the contract to the best bid.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance