EvoMAS: Evolutionary Algorithms Automatically Design Multi-Agent Systems

Overview: The "Architect" of Multi-Agent Systems Is Automated

Human-designed multi-agent systems (MAS) are like hand-assembled Swiss watches—every gear position and spring tension depends on experience. EvoMAS says: stop doing that manually; let evolution be the designer.

Rather than asking an LLM to write code (which often fails to run) or applying fixed templates (which limit the design space), EvoMAS redefines MAS design as configuration generation. Each MAS is described—like a genome—by a configuration specifying every agent's role, model, prompt, and communication topology. Evolutionary algorithms then automatically search the configuration space for optimal designs.

Why Existing Approaches Fall Short

1. Code generation is fragile. Having LLMs write MAS code directly frequently fails due to syntax errors, API changes, and environment dependencies—debugging costs can exceed hand-writing. 2. Templates are too rigid. Fixed templates (e.g., MetaGPT's "product manager + architect + engineer" roles) restrict the expression space; different tasks need different collaboration patterns. 3. Human design doesn't scale. Hand-crafted architectures (Peer Review, MetaGPT, ADAS) are labor-intensive and performance drops sharply when the model or task changes.

EvoMAS's insight: don't generate code—generate configuration. Code is the execution layer; configuration is the description layer. Configurations are more robust, easier to explore, and reusable.

What Is a Configuration? The "Genome" of a MAS

Each MAS is encoded as a structured configuration across five dimensions:

| Dimension | Description | Example | |---|---|---| | Agent Roles | Role definition per agent | "code reviewer", "test engineer" | | Backbone Models | LLM used per agent | Claude-4.5-Sonnet, Qwen3-235B | | System Prompts | System prompt per agent | "You are a strict code reviewer..." | | Tool Access | Callable tools per agent | file I/O, web search, code execution | | Communication Topology | Inter-agent structure | star, chain, fully connected, hierarchical |

At execution time, a lightweight runtime reads the configuration, instantiates the agents, and runs the system. Decoupling configuration from code means configurations can vary freely without execution failures.

The Evolutionary Loop: Select → Mutate → Crossover → Consolidate

1. Select

Given a task query, EvoMAS picks the k most relevant candidate configurations from the pool, based on similarity of task metadata (task annotations, historical performance). Like starting from the closest existing species rather than designing from scratch.

2. Mutate

Targeted single-candidate modifications: revising an agent's prompt, swapping its backbone model, adjusting tool permissions, or rewiring topology edges. Crucially, mutations are feedback-driven—based on execution feedback (e.g., "the code reviewer missed boundary-condition checks last time")—not random.

3. Crossover

Combines strengths of two parent configurations: inherit one's communication topology, take an efficient agent design from the other, mix prompt strategies—analogous to hybrid breeding.

4. Consolidate

After each evolution run, successful trajectories are summarized into compact representations stored in an experience memory. For future similar tasks, this memory guides the search—not merely "remember good configurations" but "remember which modification strategies work": a form of meta-learning.

Results: Evolved Systems Beat Human Designs

| Benchmark | EvoMAS | Best Human Design | Gap | |---|---|---|---| | BBEH (reasoning) | 58.7% | 46.2% (Peer Review + Qwen3-235B) | +12.5 pp | | SWE-Bench-Verified | 63.8% | 44.3% (MetaGPT + Qwen3-235B) | +19.5 pp | | SWE-Bench-Verified (Claude-4.5-Sonnet) | 79.1% | — | matches leaderboard top | | WorkBench (tool use) | beats EvoAgent | — | +7.1 points | | BBEH (vs EvoAgent) | beats EvoAgent | — | +10.5 points |

Key Findings

1. No single model wins every role: EvoMAS automatically assigns different models to different roles (e.g., Claude for architecture, Qwen for code generation); heterogeneous combinations outperform single-model systems. 2. Evolution gains scale with task complexity: on simple tasks the gap with a single agent is small; on complex tasks (software engineering) it widens sharply. 3. Much higher executability: configuration generation succeeds more often than code generation because configurations are declarative and interpreted by a runtime. 4. Compute-budget scaling: more evolution steps yield continuous improvement, while other methods plateau—an inherent advantage of evolutionary search.

Why Evolution Suits MAS Design

1. The configuration space is combinatorially explosive: agent count × model choice × prompt variants × topology × tool combinations. Gradient descent can't handle such discrete spaces; population-based search naturally fits. 2. Sparse, delayed rewards: final task success is 0/1; LLM-as-judge serves as a proxy reward, converting delayed rewards into intermediate feedback. 3. Cumulative learning: successful configurations and evolution patterns are retained, so the system gets smarter with use. 4. Aligned with test-time compute scaling: EvoMAS allocates test-time compute to configuration search—a structural scaling rather than depth scaling.

Analogy: Automatic Breeding for MAS Design

| Biological Evolution | EvoMAS | |---|---| | Genome | MAS configuration (roles, models, prompts, topology) | | Gene pool | Configuration pool (human designs + accumulated history) | | Natural selection | Task success rate as fitness | | Mutation | LLM-driven, feedback-conditioned modification | | Hybridization | Configuration recombination (topology + agent attributes) | | Species memory | Experience memory (Consolidate's stored patterns) | | Adaptive radiation | Different MAS forms evolving for different tasks |

Limitations and Extensions

Limitations

• Evolution requires multiple evaluations; compute cost exceeds single inference.
• Only cooperative agents are considered; adversarial settings are not covered.
• Relies on LLM-as-judge reliability; the reward signal may be biased.

Future directions

• Heterogeneous model evolution: finer-grained model selection (e.g., MoE routing).
• Online evolution: real-time adaptation instead of per-task evolution.
• Cross-task transfer: extending the Consolidate memory to cross-domain transfer learning.

References

• Yuntong Hu, Yuting Zhang, Matthew Trager, Yi Zhang, Shuo Yang, Wei Xia, Stefano Soatto. *Evolutionary Generation of Multi-Agent Systems*. ICML 2026. arXiv:2602.06511
• Key data: BBEH 58.7% vs 46.2% human design; SWE-Bench-Verified 79.1% (Claude-4.5-Sonnet)
• Benchmarks: BBEH (reasoning), SWE-Bench-Verified (software engineering), WorkBench (tool use)