MANTA: Self-Evolving Multi-Agent Organizational Structure at Runtime

The Counterintuitive Premise

Most LLM multi-agent self-improvement work targets agents themselves: better outputs (Self-Refine), better prompts (DSPy), better reasoning traces (CoT), better memories (Reflexion). What everyone ignores is the organizational structure—who talks to whom.

MANTA (Multi-Agent Network Topology Adaptation) makes one claim: topology is not a static design-time choice, but an object that can self-evolve at execution time.

The Seven-Level Self-Improvement Pyramid

The paper organizes self-improvement methods by *what they improve*:

• L0 Output: Self-Refine — fix the answer
• L1 Prompt: DSPy, APE, TextGrad — fix the instructions
• L2 Reasoning trace: CoT, ToT, GoT — fix the chain of thought
• L3 Skills/tools: ReAct, Voyager — fix what can be called
• L4 Memory: Reflexion, ACE, A-MEM — fix what is remembered
• L5 Agent roles: CAMEL, MetaGPT, Debate — fix the division of labor
• L6 Topology: MASS, AFlow, ADAS, MANTA — fix who talks to whom
• L7 Weights: RLHF — fix the model itself

Before MANTA, all L6 methods (MASS, AFlow, ADAS, AgentSquare) were offline optimizations: search for a good workflow, then freeze it during execution. MANTA's difference is one sentence: the topology can be modified during execution.

Three Components, Two Decisions

MANTA is a nested two-layer design. The inner layer is the target multi-agent system; the outer orchestration layer has three LLM components:

• Topology Planner: Given task features and experience memory, produces a compact topology plan (interaction mode, agent count, verifier/subgroup needs). A deterministic code expander unfolds it into a full topology with roles, context policies, communication edges, and visibility policies. The Planner never sees benchmark identity or hand-designed topologies.
• Trace Auditor: After each round, scans structured execution traces—tool records, relay packets, confidence levels, unresolved issues, evidence visibility. It looks only at process, never at answer correctness, and cannot consult ground truth. If at least one repairable medium/high-severity flag is found, the run is flagged for repair; otherwise it's clean.
• Controller: Decides whether to finalize the answer or perform a bounded topological revision—at most one revision, at most three operations (add agent, expand agent, change grouping mode, change communication edges, change information visibility).

This bounded design keeps meta-layer overhead at only 12% of the inference budget while capturing most repairable failures.

Two Playbooks: Short-Term and Long-Term

• Short-term playbook (per-run): logs each round's topology, Auditor flags, recommended repairs, and Controller decisions—so the Planner knows which structures were tried and what anomalies they produced.
• Long-term playbook (cross-run): stores generalizable principles of the form *task features + process risks → topology choices*, consulted at initial planning and repair. A Skill Reflector rewrites it every N runs.

Critically, the long-term playbook's learning signal never sees ground truth. Each run receives only a process-derived label—"procedurally clean" (no audit flags, ended with decision-level consensus)—meaning "no coordination anomalies observed," not "the answer was correct." Ground truth is used only for evaluation. This avoids the common error of training process on answers.

Four Failures, Four Repairs

1. Overloaded branch: A star-topology worker handling multiple aspects plus an unverified tool failure gets expanded into a dedicated subgroup; the star becomes a two-level tree. 2. Missing check: A single agent returns a low-confidence answer with no review. The fix adds one agent with a critic role in a debate pair—next round: clean audit, confidence 1.0, score 1.0. The added agent never attempts to solve the problem; its only job is checking. 3. Premature consensus: Three agents reach consensus in round one with imperfect confidence and open questions. The fix keeps all three agents and adds one edge—a direct worker-verifier connection, turning star into fully-connected debate. Next round: confidence 1.0, score 1.0. 4. Duplicated action: A stateful action executed twice in parallel becomes a serial chain.

The common thread: all repairs change structure, not content. None of them says "write better answers"; all say "reorganize who talks to whom, who checks whom, who goes first."

Results: 74.0, a 5.8-Point Lead

Five benchmarks (BrowseComp, StableToolBench, PlanCraft, WorkBench, MATH), three independent runs of 30 questions each, all with Gemma 4 backbone. MANTA averages 74.0 vs. 68.2 for the next-best method.

Ablations:

| Configuration | Success rate | Total tokens | |---|---|---| | Full MANTA | 71.7% | 100,315 | | Without initial Topology Planner | 57.5% | 112,040 | | Without topological revision | 60.8% | 72,105 | | Without long-term playbook updates | 67.5% | 102,620 | | Without long-term playbook | 66.7% | 78,356 |

The two largest contributions are initial planning (-14.2 points when removed) and runtime revision (-10.9 points). Cross-run learning contributes only 4-5 points but enables a key capability—cross-domain transfer.

The Only Positive Transfer

| Method | PlanCraft→WorkBench | WorkBench→PlanCraft | Avg. change | |---|---|---|---| | ADAS | 66.7→66.7 | 76.7→70.0 | -3.3 | | AgentSquare | 60.0→36.7 | 26.7→23.3 | -13.3 | | MASS | 46.7→0.0 | 70.0→0.0 | -58.3 | | MANTA | 43.3→50.0 | 70.0→70.0 | +3.3 |

MASS's -58.3 is catastrophic negative transfer—a workflow optimized for PlanCraft fails completely on WorkBench. MANTA is the only method with positive average transfer, because its playbook stores inheritable, actionable structural knowledge ("when task features X, topology choice Y avoids process anomaly Z") rather than fixed workflows optimized for predefined training tasks.

"Procedurally Clean ≠ Correct"

The paper's most thought-provoking insight: process-level audit and answer-level correctness are orthogonal measures. A run can be procedurally clean but wrong (coordination fine, knowledge insufficient), or procedurally messy but correct. MANTA chooses process-level signals because answer-level signals are unavailable in real deployment—you don't know the ground truth for a user's question. This is pragmatic engineering, but it means MANTA learns "how to avoid process anomalies," not "how to produce correct answers." The gap between the two is future work.

Why This Is Happening Now

MANTA's viability depends on preconditions:

1. Cheap enough LLMs: meta-layer operations at 12% of inference budget were unaffordable in the GPT-3 era. 2. Mature structured agent communication: relay packets, append-only evidence ledgers, context policy enforcement—standardized only after ReAct/Reflexion. 3. Executable process-level auditing: machine-readable process representations, enabled by MANTA's relay packet design.

This also explains why L6 (topology) was the last self-improvement level to be tackled—it required L0–L5 infrastructure to exist first.

Limitations

• Only one revision allowed: tasks requiring multiple restructurings are out of reach.
• Process-signal blind spots: some failure modes may not appear in the Auditor's observable anomaly set.
• Single backbone model: all experiments use Gemma 4; meta-layer quality depends on backbone capability.
• No open-source code: the topology representation, relay packet format, and flag taxonomy require code to fully understand.

Key Takeaway

Topological structure is not a static design-time choice but an object that can self-evolve at execution time; process-level auditing and answer-level correctness are orthogonal measures, and testing only one misses failures in the other.

---

Paper: arXiv 2607.28527 — MANTA: Multi-Agent Network Topology Adaptation for Self-Evolving Multi-Agent Systems

Code: No open-source repository released with the paper.

FAQ

Q1: Who is this for? Practitioners, researchers, and students interested in AI, machine learning, and multi-agent systems.

Q2: What are the core points? A counterintuitive premise (topology as evolvable object), a seven-level self-improvement pyramid, and a three-component architecture with bounded runtime revision.

Q3: Is there open-source code? No—see the limitations section.