A Counterintuitive Fact
You assemble a team for a complex project—three engineers, a verifier, a coordinator, in a star reporting structure. After the task starts, you notice: one engineer has been assigned both tool-calling and fact-checking directions, and he starts making errors. Meanwhile, there is no direct communication channel between the verifier and the engineers; problems get relayed layer by layer, and by the time the coordinator notices, it's too late.
What would you do?
Most people's first instinct is to swap people—get a stronger engineer, or write a finer prompt. That's also what most current LLM multi-agent systems do: Self-Refine rewrites outputs, DSPy tunes prompts, CoT reshapes reasoning traces, Reflexion accumulates memory. But one variable has been ignored by everyone: the organizational structure itself.
MANTA's (Multi-Agent Network Topology Adaptation) core claim is: topology is not a static design-time choice, but an object that can self-evolve during execution.
The Seven-Layer Self-Improvement Pyramid
The paper presents a striking figure ranking all self-improvement methods by "what gets improved":
- L0 Output: Self-Refine—fixing the answer
- L1 Prompt: DSPy, APE, TextGrad—fixing instructions
- L2 Reasoning trace: CoT, ToT, GoT—fixing chain-of-thought structure
- L3 Skills/tools: ReAct, Voyager—fixing what can be called
- L4 Memory: Reflexion, ACE, A-MEM—fixing what is remembered
- L5 Agent roles: CAMEL, MetaGPT, Debate—fixing the division of labor
- L6 Topology: MASS, AFlow, ADAS, MANTA—fixing who talks to whom
- L7 Weights: RLHF—fixing the model itself
- Only one revision. If the first repair misses, there is no second attempt—an engineering compromise that leaves MANTA unable to handle tasks requiring multiple reorganizations.
- Blind spots in process-level signals. "Procedurally clean" ≠ "correct." Some failure modes fall outside the set of process anomalies the current Auditor can observe.
- Single backbone model. Everything runs on Gemma 4; weak backbones would limit Planner and Auditor judgment quality.
- No open-source code. The paper ships no GitHub repository—a pity, since the topology representation, relay packet format, and Auditor's flag taxonomy can only be precisely understood from code.
Note L6. Before MANTA, methods at this level (MASS, AFlow, ADAS, AgentSquare) were all offline optimization—search for a good workflow first, then freeze it at execution time. MANTA's difference is one sentence: topology can be modified during execution.
This sounds plain, but the implication is deep. Offline optimization assumes you can know the optimal structure before the task begins; MANTA admits you can't—you can only observe where things go wrong during execution, then make one bounded repair.
Three Components, Two Decisions
MANTA's architecture is a two-layer nested design. The inner layer is the target multi-agent system that actually solves the task; the outer orchestration layer decides what the inner layer looks like. It has only three LLM components:
Topology Planner: When a task arrives, it produces a compact topology plan from task features and experiential memory—interaction mode, number of agents, whether a verifier or nested subgroups are needed. A deterministic code expander unfolds this plan into a complete topology (roles, context policies, communication edges, visibility policies) and validates all structural constraints. The Planner never sees benchmark identity and has no hand-designed topologies to reference.
Trace Auditor: After each round, it scans structured execution traces—tool records, relay packets, confidence scores, unresolved questions, evidence visibility. It looks only at process, never at whether the answer is correct. It cannot consult reference answers. If it finds at least one fixable medium- or high-severity flag, the run is marked "flagged" and triggers repair; otherwise it's "clean" and passes.
Controller: Given the Auditor's diagnosis, it decides whether to finalize the answer or make one bounded topology revision—at most one revision, at most three operations: add an agent, expand an agent, change group mode, change communication edges, or change information visibility. Then one more round runs, followed by another audit.
A key design choice here: the revision is bounded. Not unlimited self-repair, but at most one revision with three operations. This constraint keeps meta-layer overhead at just 12% of the inference budget while still capturing most fixable failures.
Two Notebooks: Short-Term and Long-Term Playbooks
MANTA's memory spans two time scales.
The short-term playbook lives within a single run. It records, for each round: current topology, flags reported by the Auditor, recommended fixes, and the Controller's decisions. This lets the Planner know "which structures have been tried and what observable anomalies they produced"—rather than only seeing the latest state.
The long-term playbook accumulates across runs. It stores general principles—task features + process risks → topology choices. The Planner consults it at both initial planning and repair time. Every N runs, a Skill Reflector rewrites its lessons from recent trace summaries.
A counterintuitive design: the long-term playbook's learning signal never looks at ground truth. Each run in a reflection batch receives only a process-derived label—"procedurally clean" (audit with no flags, ending in decision-level consensus). This label means "no coordination anomalies observed," not that the answer is correct. Ground-truth answers are used only for evaluation, never exposed to the Planner or any playbook.
This design avoids the common mistake of "training process with answers." MANTA learns "which topologies on which tasks avoid process anomalies," not "which topologies guess answers right."
Four Failures, Four Fixes
The paper's four case studies are the most rewarding part—concrete topological repairs, not abstract failure modes.
Failure 1: Overloaded branch
In a star topology with three agents, one worker carries multiple aspects and hits an unverified tool failure. After the Auditor flags it, the Planner expands the overloaded worker into a dedicated subgroup—the original single node becomes two nodes with divided work, while unaffected branches stay untouched. The topology shifts from star to a two-level tree.
Failure 2: Missing check
On a MATH task, a single agent returns a low-confidence answer with no one checking it. The fix adds just one agent with a critic role, pairing the two in debate. The next audit is clean, consensus confidence 1.0, score 1.0. The added agent never attempts to solve the problem; its only job is to check the existing answer.
Failure 3: Premature consensus
On a PlanCraft task, three agents reach consensus in round one, but confidence is imperfect and open questions remain. The Auditor flags "premature consensus." The fix keeps all three agents and adds a single edge—a direct connection between worker and verifier, turning the star into a fully connected debate. Next round passes with confidence 1.0 and score 1.0.
Failure 4: Duplicated action
Two agents executing in parallel perform the same stateful action twice. The fix converts parallel execution into a serial chain—one agent finishes, then the next proceeds.
All four fixes share one trait: they change structure, not content. None is "make the agent write a better answer"; all are "reorganize who talks to whom, who checks whom, who goes first." This is on an entirely different level from Self-Refine's "fix the output" or CoT's "fix the reasoning chain."
The Numbers: 74.0, a 5.8-Point Lead
Five benchmarks (BrowseComp, StableToolBench, PlanCraft, WorkBench, MATH), three independent runs, 30 tasks each, all with Gemma 4 as the backbone. MANTA averages 74.0; the next-best method gets 68.2.
The ablations are the most informative:
| Configuration | Success rate | Total tokens | |---|---|---| | Full MANTA | 71.7% | 100,315 | | Remove initial Topology Planner | 57.5% | 112,040 | | Remove topology revision | 60.8% | 72,105 | | Remove long-term playbook updates | 67.5% | 102,620 | | Remove long-term playbook | 66.7% | 78,356 |
The two biggest contributors: initial planning (-14.2 points when removed) and runtime revision (-10.9 points). Cross-run learning contributes only 4–5 points, but brings a crucial capability—cross-domain transfer.
Cross-Domain Transfer: The Only Positive Case
Transferring the playbook learned on PlanCraft to WorkBench, and vice versa:
| 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 on PlanCraft fails completely on WorkBench. MANTA is the only method with positive average transfer. The paper's explanation is clear: MANTA's playbook stores "inheritable, actionable structural knowledge," not "fixed workflows optimized for predefined training tasks."
This distinction matters. MASS learns "the optimal topology on PlanCraft"; MANTA learns "when task features are X, topology choice Y avoids process anomaly Z." The former is a concrete answer; the latter is a rule.
"Procedurally Clean ≠ Correct": A New Member of the Evaluation Blind-Spot Family
This is the paper's most thought-provoking insight.
MANTA's learning signal is "procedurally clean"—no audit flags, execution ending in decision-level consensus. This label means "no coordination anomalies observed," but it does not mean the answer is correct.
In other words: a clean process and a correct answer are two different metrics. A run can be procedurally clean but wrong (coordination went fine, but knowledge was insufficient); a run can also be messy but correct (lots of arguing, then a lucky guess).
MANTA chooses to learn from process-level signals because answer-level signals simply aren't available in real deployment—you don't know the ground truth for a user's question. It's an engineering-pragmatic choice, but it means MANTA learns "how to avoid process anomalies," not "how to produce correct answers." The gap between the two is space for future work.
Engineering Insight: Why This Is Happening Now
MANTA depends on several preconditions:
1. LLMs are cheap enough: meta-layer operations (Planner + Auditor + Reflector) take 12% of the inference budget—unaffordable in the GPT-3 era. 2. Structured agent communication protocols have matured: relay packets, append-only evidence ledgers, context policy enforcement—infrastructure standardized only in the ReAct/Reflexion era. 3. Process-level auditing is executable: the Auditor doesn't look at answers, only process, which requires a machine-readable process representation. MANTA's relay packet design is key to making this work.
This also explains why L6 (topology) was the last self-improvement level to be conquered—it required the L0–L5 infrastructure to be built first.
Three Details That Made Me Pause
The revision is bounded. At most one revision, three operations. Not unlimited self-repair. This keeps meta-layer overhead at 12% while still catching most fixable failures—reminiscent of bounded rationality in human organizations: you can't restructure a team infinitely mid-meeting; you get one re-division of labor.
The Auditor doesn't look at answers. The most counterintuitive engineering choice. But since real deployments lack ground truth, this constraint forces a deeper insight: process-level and answer-level signals are orthogonal—you can judge whether the process went wrong without knowing whether the answer is right.
The only positive cross-domain transfer case. MASS's -58.3 is the most alarming number: a workflow optimized for PlanCraft drops from 46.7 to 0.0 on WorkBench. Fixed workflows optimized for one task are fragile. MANTA's +3.3 isn't big, but it's the only positive—because it learns rules, not answers.
Limitations and Open Questions
Personal Reflection: Organizational Structure as a First-Class Citizen
The deepest thing MANTA made me reconsider: in the agent era, organizational structure should be designed as a first-class citizen.
Recent agent engineering has focused on two directions: individual agent capability (prompt engineering, tool use, memory) and inter-agent protocols (MCP, A2A). Both assume "organizational structure is given"—either a single agent or a fixed multi-agent workflow.
MANTA points out: organizational structure itself is an optimizable variable, and its granularity of optimization aligns with task granularity. Different tasks need different topologies; different stages of the same task might too. This is a new engineering dimension.
A deeper question: can MANTA's long-term playbook itself keep learning? The playbook is periodically rewritten, but the rewriting rules are preset. If the playbook could evolve itself—not just what principles it stores, but how it distills them—that would be the next level: making the naming itself an evolvable object.
That direction is still far off. But with MANTA filling the empty L6 slot, evolution above L6—the self-evolution of topology learning itself—becomes the next thing worth naming.
---
Paper: arXiv 2607.28527 — MANTA: Multi-Agent Network Topology Adaptation for Self-Evolving Multi-Agent Systems
Code: No open-source repository provided with the paper
One-sentence takeaway: Topology is not a static design-time choice but an object that can self-evolve at runtime; procedural audit and answer correctness are orthogonal metrics—measuring only one misses failures in the other dimension.