Evolving the Team: Multi-Agent Topologies That Rewrite Themselves
Here’s the uncomfortable truth the hype cycle doesn’t want you to hear: a single, well-prompted model often beats an entire team of specialised agents on standard reasoning benchmarks. Pan et al. (2025a) demonstrated that single large LLMs with carefully crafted prompts can match the performance of complex multi-agent discussion frameworks across multiple reasoning tasks arxiv:2508.07407. Jwalapuram et al. (2026) push the finding further: a single-agent GPT-5 instance using chain-of-thought with self-consistency “reliably outperforms the most sophisticated GPT-4o-based MAS frameworks (e.g., ADAS or AFlow) while consuming less than half the total tokens,” and automatically generated multi-agent systems “consistently underperform CoT-SC despite being up to 10x more expensive” arxiv:2606.13003. If you’re building an agent system and your first instinct is “let’s spin up three agents and make them debate,” you might just be burning tokens for no gain.
Self-Evolving Agents, a 5-part series grounded in arXiv:2508.07407. ← Part 3 · Part 5 →
But that’s only half the story. When tasks require decomposability, specialisation, or long-horizon execution, a static single agent hits a hard ceiling. The emerging paradigm of Multi-Agent Self-Evolving (MASE) systems—where agent teams rewrite their own prompts, topologies, and communication protocols—promises to break through that ceiling. Fang et al. (2025) formalise this as the shift from Model Offline Pretraining (MOP) through Multi-Agent Orchestration (MAO) to MASE, where the optimisation loop closes between environment feedback and structural adaptation arxiv:2508.07407. The question is whether this complexity actually pays off in production.
The answer isn’t a simple yes or no—it depends on topology, task structure, and whether you’re willing to let the team evolve itself.
What Makes a Multi-Agent Topology Self-Evolving
Most production multi-agent systems today are statically wired: you decide the hierarchy (manager-follower, flat peer-to-peer, or sequential pipeline) at design time and never change it. That’s fine until the task distribution shifts. A self-evolving topology treats the wiring itself as a search variable. The conceptual framework from Fang et al. (2025) decomposes the evolution loop into four components: System Inputs, Agent System, Environment, and Optimiser arxiv:2508.07407. The optimiser explores a search space that includes not just prompts and tools, but the communication graph and role assignments.
This reframes workflow design from manual engineering into an optimisation problem over three interconnected spaces: the structural space of agent topologies, the semantic space of agent instructions, and the capability space of LLM backbones. The optimiser iteratively mutates, evaluates, and selects configurations based on performance feedback from the environment. That’s the MASE paradigm—and it’s a fundamentally different beast from static multi-agent systems.
How Teams Rewrite Their Own Wiring
The most instructive line of work treats topology as a first-class optimisation target. GPTSwarm (Zhuge et al., 2024a) defines the search space as connections within a computational graph of agents arxiv:2402.16823. It relaxes this discrete space into continuous edge probabilities and uses reinforcement learning to learn optimal connection schemes, while a second optimiser refines each node’s prompt — the paper’s two levers are node optimisation and edge optimisation, not topology alone. On the GAIA benchmark, GPTSwarm’s optimised graphs averaged 18.45 against 9.70 for the strongest single-LLM baseline, GPT-4-Turbo — a 90.2% relative improvement. Level‑2 tasks, which require multi-step reasoning and tool use, went from 5.81 to 20.93, a 260.2% relative gain; Level‑1 went from 20.75 to 30.56, a 47.3% gain. This is not incremental. But note what the comparison actually is: an optimised swarm against a single model, with node prompts and graph edges tuned jointly. The paper does not isolate topology as the source of the gain.
AFlow (Zhang et al., 2025j) takes a different tactical approach: it replaces natural-language program representations with typed, reusable operators to form code graphs arxiv:2508.07407. It then uses Monte Carlo Tree Search with LLM-guided expansion and soft probabilistic selection to explore the design space. Compared to AutoFlow’s earlier RL-based search over natural-language programs, AFlow’s MCTS-based exploration is more structured and sample-efficient, better exposing generalisable patterns in workflow design. What GPTSwarm and AFlow have in common is that both treat the communication structure as a searchable variable rather than a design-time constant. Neither paper reports an ablation separating the contribution of topology from that of the prompts optimised alongside it, so the honest claim is the weaker one: structure is worth searching, not that structure dominates prompting. AFlow’s use of typed operators further enables compositional reuse, making the search space more tractable than arbitrary code generation.
EvoAgent (Yuan et al., 2025a) applies evolutionary algorithms directly to agent configurations: mutation, crossover, and selection operators on textual agent settings (roles, skills, prompts) arxiv:2508.07407. It generates diverse agent populations and lets the fittest survive. While evolutionary search over discrete text configurations is less sample-efficient than GPTSwarm’s gradient-based continuous relaxation, EvoAgent has the advantage of producing interpretable configurations that engineers can inspect and modify directly.
The Strong Case for One Good Agent
Before you commit to a self-evolving team, consider the evidence against complexity. Pan et al. (2025a) systematically compared single-model agents (with chain-of-thought and self-consistency) against multi-agent debate frameworks arxiv:2508.07407. The result: on multiple reasoning benchmarks, the single agent matched or exceeded the multi-agent discussion performance when given a well-optimised prompt. Multi-agent systems consumed significantly more tokens for no accuracy gain.
This aligns with findings from Verga et al. (2024) that parallel generation with small LLMs can match or outperform single large LLMs—but only when the task is naturally decomposable into independent subproblems arxiv:2508.07407. For sequential, tightly-coupled reasoning, the coordination overhead of multi-agent systems introduces latency without commensurate improvement. The engineering takeaway is brutal: if you can solve your task with one call to a capable model, you should. Multi-agent systems are a complexity tax, not a free lunch.
Further quantitative evidence comes from hint‑engineering studies on lightweight models. On AIME24 with a 4k token budget, Hint-Engineering-SFT — a fine-tuned 1.5B model, not a prompting trick — reaches 22.7% accuracy, nearly double the 12.1% of the base DeepSeek-R1-1.5B and the 11.0% of Prompt-Hint-SFT arxiv:2506.09820. On correct responses it uses 47% fewer tokens than Prompt-Hint-SFT (4,711 vs. 8,862). Note the scope: this is a single-model comparison against other single-model configurations, not a head-to-head with a multi-agent system. It says that a single model’s reasoning budget is worth optimising — it does not by itself settle the one-versus-many question.
When Teams Earn Their Keep
Despite the cautionary evidence, multi-agent topologies win decisively on tasks that require functional specialisation, long-horizon execution, or coordination across heterogeneous tools. Consider the OPTIMA framework (Chen et al., 2025h), which optimises communication efficiency in multi-agent systems using supervised fine-tuning, DPO, and hybrid methods arxiv:2508.07407. On tasks demanding intensive information exchange (multi-step code generation, collaborative research), OPTIMA achieved a 2.8× performance gain while consuming less than 10% of the token cost compared to naive multi-agent baselines. That’s a clear win: the structured communication protocol eliminated redundant debate while preserving the benefits of specialisation. OPTIMA’s hybrid approach demonstrates that the key to effective multi-agent collaboration is not adding more agents, but designing efficient information channels between them.
In the code generation domain, CodeAgent (Tang et al., 2024) demonstrated that role-specialised agents (coder, reviewer, tester) collaborating through structured dialogue cycles achieve an average recall of 89.46% and F1 of 94.07% on the format-consistency detection task across nine programming languages arxiv:2402.02172. That average F1 is a 10.45 percentage point improvement over the best baseline (GPT-4.0, 83.62%). The multi-agent structure here wasn’t overhead—it was the mechanism that forced the system to simulate code review practices. Broken out by commit category, F1 reached 94.01% on merged commits (+6.94 pp over the best baseline, GPT-4.0) and 94.13% on closed commits (+9.94 pp over the best baseline, GPT-3.5). On the separate code-revision task, CodeAgent posts its highest Edit Progress of 37.6% and an average of 31.6%. These numbers point to the collaborative workflow, not just the underlying model, as the source of the gain.
The pattern is clear: multi-agent teams earn their complexity when the task can be decomposed into roles with clear interfaces. If you’re building a code pipeline, a research assistant, or a customer service system with escalation paths, a self-evolving topology can adapt the team composition to the workload dynamically.
The Hidden Costs: Latency, Token Budget, and Failure Modes
Every multi-agent topology incurs coordination cost. Even with optimised communication graphs, you pay for message passing, serialisation, and context window consumption. AgentPrune (Zhang et al., 2025g) treats the search space as a spatial-temporal communication graph and applies a trainable low-rank-guided graph mask to identify and prune redundant edges arxiv:2508.07407. By removing both intra-dialogue (spatial) and inter-dialogue (temporal) redundant communications through a one-shot, low-rank-guided graph mask, it optimises for token economy. The survey describes the mechanism but reports no token-reduction figure, so treat the size of the saving as unquantified here: the principle is that some inter-agent messages in standard debate setups are redundant, and pruning them recovers coordination overhead—but only if you start with a baseline that actually benefits from multi-agent collaboration in the first place.
Safety is another under-discussed cost. When agents rewrite their own topology, they also rewrite their guardrails. Fang et al. (2025) propose the Three Laws of Self-Evolving AI Agents—Endure (safety adaptation), Excel (performance preservation), and Evolve (autonomous optimisation)—but these are aspirational guidelines, not guarantees arxiv:2508.07407. In practice, self-evolving teams can drift into unsafe behaviours through unguided experience accumulation, as demonstrated empirically in related work. G-Safeguard (Wang et al., 2025f) applies GNN-based risk detection on communication edges to flag dangerous interactions, but this adds yet another layer of complexity. Moreover, the entire optimisation pipeline introduces a new attack surface: a compromised optimiser can inject malicious patterns that persist across evolutionary cycles, making self-evolving teams harder to audit than static systems.
Practical Decision Framework
After studying the evidence across the surveyed systems, here’s a decision rubric for choosing between a single agent and a self-evolving team:
| Task Characteristic | Prefer Single Agent | Prefer Self-Evolving Team |
|---|---|---|
| Task decomposability | Low (tightly coupled reasoning) | High (independent subproblems) |
| Failure cost | High (correctness critical) | Moderate (can absorb occasional errors) |
| Skill set required | Generalist knowledge | Multiple specialised domains |
If your task falls in the left column, stick with a single agent and invest in prompt optimisation and retrieval augmentation. If it falls in the right column, consider a self-evolving multi-agent system—but start with a manually designed workflow before turning on the evolution loop. Let the optimiser tune roles and communication after you’ve validated the baseline.
Putting Self-Evolution into Practice
The most practical approach today combines code-level workflow representations with search-based optimisation. ScoreFlow (Wang et al., 2025j) lifts agent workflows into a continuous space and applies gradient-based optimisation with Score-DPO, a variant of direct preference optimisation that uses quantitative feedback arxiv:2502.04306. This addresses the sample inefficiency of pure RL or evolutionary methods. For a production system, the recommended path is to start with AFlow’s MCTS-based search on a fixed set of typed operators, then graduate to ScoreFlow’s continuous optimisation once you have enough logged trajectories.
EvoAgentX (Wang et al., 2025i) is the first open-source framework that implements the full MASE loop: it automates generation, execution, evaluation, and optimisation of agentic systems arxiv:2507.03616. It’s still early-stage, but it gives you a concrete environment to experiment with self-evolving topologies without building the infrastructure from scratch.
Component Analysis: Prompts vs. Topology
A critical question for practitioners is whether to invest in prompt optimisation or topology search. The MASS framework (Zhou et al., 2025a) provides a useful lens: it proposes a three-stage, conditionally coupled optimisation where prompt tuning is performed first on fixed topologies, then topology is searched in a pruned space, and finally global prompt optimisation is applied on the selected topology arxiv:2508.07407. The conditional coupling means that the two dimensions are not independent—a prompt that works well in a star topology may fail in a mesh. The survey’s coverage suggests that the largest gains come from the topology search stage after initial prompt tuning, because the structure determines which agent interactions are possible. In practice, this means you should never optimise prompts in isolation; always wrap them in the topology that will be used in production.
The Verdict
Do self-evolving multi-agent topologies beat one good agent? Yes—on the right tasks. The evidence from GPTSwarm (90.2% average improvement on GAIA), OPTIMA (2.8× gain at <10% token cost), and CodeAgent (10.45 pp F1 improvement) shows that on complex, decomposable problems, self-evolving teams deliver regime changes, not incremental gains. The same evidence also shows that on tightly-coupled reasoning tasks, a single well-prompted model with chain-of-thought is more efficient and equally accurate.
The future belongs to systems that can make this choice autonomously: detect when the task warrants team collaboration and when it doesn’t, and rewrite their topology accordingly. The DynaSwarm approach (Leong and Wu, 2025) takes a step in that direction by learning a portfolio of graph structures and selecting per-instance topologies arxiv:2507.23261. The next frontier is MASE systems that dynamically toggle between single-agent and multi-agent modes based on real-time task complexity estimates.
For now, the safe bet is to build your agent system with a modular architecture that supports both modes. Let the evolution loop discover whether a team is necessary—don’t assume it from the start. The three laws—Endure, Excel, Evolve—are not just principles. They’re engineering guardrails that separate systems that adapt safely from those that metastasize into unpredictable assemblies of hallucinating chatbots.
FAQ
Q: What is a multi-agent topology? A: A multi-agent topology is the structural arrangement of agents in a system—defining how they communicate, delegate tasks, and share information, similar to network topologies like star or mesh.
Q: Can agent teams evolve their own structure? A: Yes, self-evolving agent teams use meta-level controllers or evolutionary algorithms to add, remove, or reconfigure agents and their connections based on performance feedback, changing their topology without human intervention.
Q: Does a team of agents always outperform one agent? A: No, a single well-optimised agent often beats a naive multi-agent setup on simple or sequential tasks due to lower coordination overhead, but agent teams excel on complex, parallel, or specialised tasks.
Q: What are the main trade-offs with evolving multi-agent systems? A: The key trade-offs are higher computational cost and latency against better scalability and specialisation—performance gains emerge only when task complexity justifies the overhead.