arXiv CSopen access

MANTA: Multi-Agent Network Topology Adaptation for Self-Evolving Multi-Agent Systems

MANTA: Multi-Agent Network Topology Adaptation for Self-Evolving Multi-Agent Systems MaoXun Huang1,† , Jerry Wang2,† , Yi-Cheng Lai3,† Zhenxing Zhang1 , Claire Cardie1 , Hen-Hsen Huang3 2

1 Department of Computer Science, Cornell University, United States Department of Computer Science, University of Illinois Urbana-Champaign, United States 3 Institute of Information Science, Academia Sinica, Taiwan † Equal contribution

arXiv:2607.28527v1 [cs.AI] 30 Jul 2026

Abstract Large language model-based multi-agent systems improve complex problem solving through task decomposition, agent specialization, information exchange, and intermediate validation. However, existing systems typically treat communication topology as a fixed design choice or an offline optimization target. We introduce MANTA, a framework for Multi-Agent Network Topology Adaptation that enables communication structures to self-evolve at inference time. Before execution, MANTA initializes a task-conditioned topology from prior structural experience. During deployment, it monitors collaboration traces and applies bounded structural updates when the current organization becomes insufficient. These updates can modify agent roles, communication links, execution order, information visibility, and validation pathways while preserving the task interface and agent budget. We evaluate MANTA against representative single-agent and multi-agent baselines on five benchmarks spanning information seeking, tool use, planning, workflow execution, and mathematical reasoning. MANTA achieves the highest average score of 74.0, outperforming the strongest baseline by 5.8 percentage points and obtaining the best result on PlanCraft. These results show that inference-time self-improvement can extend to the architecture of collaboration itself.

Introduction Biological systems adapt not only before encountering their environments, but also through continued interaction with environmental pressures. Modern AI systems are undergoing a similar transition from predominantly offline optimization toward adaptation during execution. Large language models (LLMs) increasingly operate as components of agentic systems that reason, use tools, retain experience, and coordinate with other agents. Rather than relying only on pre-deployment weight updates, these systems can adapt at inference time through prompts, demonstrations, reasoning traces, memories, tools, workflows, and coordination protocols. In-context learning first showed that demonstrations can induce task adaptation during inference (Brown et al. 2020), while chain-of-thought prompting and ReAct demonstrated the value of intermediate reasoning and reasoning-and-acting trajectories (Wei et al. 2023; Yao et al. 2023b). Copyright © 2027, Association for the Advancement of Artificial Intelligence (www.aaai.org). All rights reserved.

Existing self-improvement methods adapt outputs, prompts, reasoning traces, and memory (Madaan et al. 2023; Shinn et al. 2023). Most approaches, however, adapt individual agents rather than how multiple agents are organized and communicate. Multi-agent frameworks decompose complex tasks across specialized roles and collaborative reasoning processes, allowing agents to debate, verify, aggregate, implement, critique, or coordinate toward a shared objective (Wu et al. 2023; Qian et al. 2024; Hong et al. 2024; Du et al. 2023). Their topology determines who communicates with whom, how information is routed, where validation occurs, and how intermediate outputs are refined. Topology is still typically optimized at design time rather than adapted during execution. Existing methods jointly optimize prompts and topologies or automate workflow design (Zhou et al. 2026; Zhang et al. 2025a; Hu, Lu, and Clune 2025; Shang et al. 2025), but generally fix the resulting structure before task execution. Whether topology can self-improve online therefore remains underexplored. This raises a central question: Can a multi-agent system improve its communication topology while solving each individual task? Unlike prior approaches that rely on training, offline search, or pre-execution optimization, this requires instance-conditioned planning, test-time topology mutation from intermediate collaboration traces, and cross-run transfer of topology experience without updating model weights. We propose MANTA, a framework for Multi-Agent Network Topology Adaptation that combines these capabilities. For each task, MANTA plans a topology from accumulated experience, audits the collaboration process, and applies a bounded structural mutation when the current organization becomes insufficient. A cross-run playbook continually distills topology-selection and repair experience across executions. Across five benchmarks, MANTA achieves the highest average score of 74.0, outperforming the strongest baseline by 5.8 points. These results highlight the value of adapting collaboration structures to task needs and execution-time failures. Our contributions are as follows. • A new problem. We argue that a multi-agent system’s communication structure should be treated as something the system can change while it works, rather than a design choice fixed before deployment. We formalize this

lower level

Levels of Self-Improvement

L7 Weights

RLHF, SELF

L6 Topology

MASS, AFlow, ADAS, AgentSquare, MANTA our focus CAMEL, ChatDev, MetaGPT, Debate, EoT,

higher level

L5 Agent Role MALLM L4 Memory

Reflexion, DC, Generative Agents, A-MEM, AWM, ACE

L3 Skill/Tool

ReAct, Toolformer, Voyager

L2 Trace

CoT, Self-Consistency, Zero-shot CoT, ToT, GoT

L1 Prompt

APO, APE, DSPy, MIPRO, PromptBreeder, TextGrad, GEPA

L0 Output

Self-Refine

text

capability

multi-agent

weights

Figure 1: Levels of self-improvement in agent systems. Methods adapt different system components, from outputs and prompts to agent topology and model weights. MANTA self-improves the communication topology. as topology-level self-improvement. • A method. We propose MANTA, which organizes a team of agents to fit the task at hand, watches the collaboration as it unfolds, and reorganizes when the current structure is clearly failing. What it learns from each task carries over to the next, without any weight updates or offline search. • Evidence that it works. Across five benchmarks, MANTA outperforms single-agent methods, static multiagent topologies, and automated workflow-design baselines. Case studies show it recovering from concrete failures such as an overloaded branch, a missing check, an agreement reached too early, an action taken twice.

Related Work Figure 1 organizes prior work by the object being adapted, ranging from outputs and prompts to agent capabilities, multi-agent organization, and model weights. This view highlights MANTA’s position: whereas most methods improve what an agent produces, observes, remembers, or executes, MANTA improves how multiple agents are organized during task solving. Text-level adaptation. Text-level methods adapt outputs, prompts, or reasoning traces. Self-Refine iteratively revises generated answers through feedback (Madaan et al. 2023). Prompt-level methods search for improved instructions or prompt variants (Pryzant et al. 2023; Zhou et al. 2023), optimize instructions, demonstrations, or modular languagemodel programs (Khattab et al. 2023; Opsahl-Ong et al. 2024), or formulate prompt design as evolutionary, differentiable, or reflective optimization (Fernando et al. 2023;

Yuksekgonul et al. 2024; Agrawal et al. 2026). Trace-level methods restructure intermediate reasoning through chainof-thought, self-consistency, and tree- or graph-based search (Wei et al. 2023; Wang et al. 2023b; Kojima et al. 2023; Yao et al. 2023a; Besta et al. 2024). These methods adapt textual or reasoning artifacts while leaving the surrounding agent organization unchanged. Agent-capability adaptation. Tool- and skill-oriented methods improve how agents act, call external tools, or acquire reusable behaviors (Yao et al. 2023b; Schick et al. 2023; Wang et al. 2023a). Memory-oriented methods store, retrieve, and refine experience, reflections, or task-solving playbooks across interactions (Shinn et al. 2023; Suzgun et al. 2025; Park et al. 2023; Xu et al. 2025; Wang et al. 2024; Zhang et al. 2025b). These approaches create more persistent and reusable agent state, but generally adapt individual capabilities or context rather than collective organization. Multi-agent organization and topology. Role-based systems such as CAMEL, ChatDev, and MetaGPT decompose tasks into specialized agents for communication, planning, coding, reviewing, or management (Li et al. 2023; Qian et al. 2024; Hong et al. 2024). Interaction-based systems coordinate agents through discussion or aggregation, as in multiagent debate, Exchange-of-Thought, and MALLM (Du et al. 2023; Yin et al. 2023; Becker et al. 2025). These systems demonstrate the importance of collaboration structure but generally rely on predefined roles and interaction patterns. More recent work treats multi-agent structure as an optimization target. MASS jointly optimizes prompts and topologies (Zhou et al. 2026), while AFlow, Automated Design of Agentic Systems, and AgentSquare search over agentic workflows or modular system designs (Zhang et al. 2025a; Hu, Lu, and Clune 2025; Shang et al. 2025). These approaches establish topology and workflow as meaningful design targets, but primarily optimize them before execution through offline search or aggregate validation performance. The selected workflow is generally fixed once task execution begins. MANTA instead treats topology as an execution-time object of self-improvement. It uses prior experience to plan an initial task-conditioned organization, then locally repairs communication, coordination, and validation structures when intermediate traces expose a structural deficiency. This distinguishes MANTA from methods that search for a fixed workflow before execution. Weight-level adaptation. Weight-level methods improve agents through training or alignment (Ouyang et al. 2022; Lu et al. 2024). MANTA instead keeps model weights fixed and adapts the collaboration structure at inference time.

Method MANTA chooses a communication topology for each task and can revise it during execution. This section defines its topology representation, orchestration loop, and memory.

System Overview Figure 2 shows two nested layers. The target multi-agent system solves the task through reasoning, tool calls, and message exchange. The orchestration layer selects the agents,

Planning & adaptation

execution

auditing & control

memory & learning

deterministic code

Agent

LLM agent

1

stage order

target multi-agent system 

1

Task

3

2

Topology Planner designs a team for the task: topology, agents, roles

Orchestrator validates the topology; spawns the agents

Ù

3

Turn Executor runs one collaboration turn

trace

Trace Auditor flags process anomalies in the trace

ç

5

audit report

Controller stop or repair

7

Finalizer votes; synthesizes from evidence

stop

Agent

Final answer

Agent

per-task loop

Agent

Agent

a final turn runs on the revised topology

records each turn

task agents

repair needed r

6

Ð

Trace-backed repair (one mutation per run) informs new verifier mutate read at initial plan and repair time

cross-run memory

ü

4

Short-term playbook (this run) each turn’s topology, findings, and decision

run outcome (process signals)

edits: add or expand agents, rewire edges, or adjust visibility

 Long-term playbook standing principles · how to choose a topology · lessons from experience

è

8

rewrites the lessons (batched)

Reflector periodically rewrites the lessons Agent

Figure 2: MANTA overview. MANTA first plans a task-conditioned multi-agent topology and executes the task under that structure. The Trace Auditor flags process-observable anomalies in the collaboration trace; it does not judge answer correctness. The Controller either finalizes the answer or returns the diagnosis for one bounded topology revision. A short-term playbook supports repair within the current run, while a long-term playbook transfers reusable topology-selection lessons across runs.

communication links, and information visibility without solving the task. It combines three LLM components called the Topology Planner, Trace Auditor, and Skill Reflector with deterministic code that validates topologies, runs agents, routes messages, controls repair, and decides when to stop. For each task, the Planner chooses the team size, interaction pattern, and roles. After one collaboration turn, the Auditor reports observable process risks rather than answer correctness. The Controller then finalizes the answer or permits one bounded repair and a final turn. Two playbooks provide memory. One records topology and audit history within the current run. The other stores lessons across runs and is updated by the Skill Reflector every N runs. It uses only process signals and never receives the benchmark verdict.

Topology Representation A topology specification defines a versioned and validated multi-agent system. Each agent has a structural role, such as coordinator, worker, verifier, debater, or voter, that determines its graph position. It also has a stage role as a worker or critic. Workers produce contributions supported by evidence. Critics check and revise visible claims. An agent may also receive a domain persona and a list of allowed tools. Agents belong to pattern groups with predefined interaction structures. Groups can be nested, which lets an agent delegate work to a subgroup and synthesize its reports. Direct connections may supplement this tree. Each context pol-

icy controls the messages, senders, and shared evidence an agent can access, how far its messages travel, and whether it receives full or summarized reports. Code enforces these policies whenever information is read. Before execution, MANTA checks group membership, attachment cycles, roles, and the agent budget. Invalid proposals are rejected. The representation includes a single agent and the six fixed workflows as special cases while also supporting nested combinations.

The Orchestration Loop Query-conditioned planning. The Planner receives the task and the experience memory without access to the benchmark identity or a hand-designed topology. It analyzes the task requirements and likely process risks, then produces a compact plan specifying the interaction pattern, agent count, and any optional verifier or nested groups. Deterministic code expands this plan into a complete topology, assigns roles and context policies, and validates all structural constraints. Turn execution. Each collaboration turn executes the topology recursively according to its group structure. Agents communicate through structured relay packets rather than raw transcripts. These packets summarize their answers, evidence, confidence, and unresolved issues. A shared-context controller enforces the visibility policy of every agent. During execution, identical tool calls are deduplicated, while an append-only evidence ledger preserves the claims and supporting evidence produced across branches.

Trace auditing and repair. After each turn, an LLM Auditor scans structured artifacts, tool records, relay packets, confidence, unresolved issues, and evidence visibility. It may also add a new trace-grounded process flag, but it cannot consult the benchmark answer or verdict. We call a run flagged when the initial audit recommends repair because at least one repairable flag has medium or high severity. A clean run does not activate this gate. These terms describe the observed collaboration process rather than answer correctness. For a general task, the Planner returns one mutation with at most three operations. It may add or expand an agent, change a group pattern, edit a communication edge, or change information visibility. Deterministic code applies the operations to a copy of the topology and validates all roles, references, memberships, nesting, and agent limits. Invalid proposals use a conservative repair compiler or are skipped.

Two-Horizon Playbook Memory MANTA maintains memory at two time scales. A short-term playbook lives within a single run and a long-term playbook accumulates across runs. The short-term playbook logs each turn of the current run, recording the topology in use, the process flags reported by the Auditor, the repair it recommended, and the decision the controller took. The Planner therefore sees which structures have already been tried and which observable anomalies they produced rather than only the latest state. The long-term playbook stores general principles that map task characteristics and process risks to topology choices. The Planner consults it both when drafting the initial topology and when choosing a repair. After every N runs a Skill Reflector rewrites its lessons from summaries of recent execution traces. This learning loop never sees benchmark feedback. Each run in a reflection batch receives only a process-derived label. A run is called procedurally clean when the audit contains no process flag and execution ends in decision-grade consensus. This label means that no encoded coordination anomaly was observed; it does not mean that the answer is correct. Groundtruth outcomes are used solely for evaluation and are never exposed to the Planner or either playbook.

Experiments Models and evaluation benchmarks. We evaluate MANTA on five benchmarks spanning three complementary capability categories. For information seeking and tool use, we use BrowseComp (Wei et al. 2025), which evaluates multi-step information seeking and evidence synthesis, and StableToolBench (Guo et al. 2024), which evaluates reliable external tool selection and execution. For planning and workflow execution, we use PlanCraft (Dagan, Keller, and Lascarides 2025), which emphasizes long-horizon planning and dependency-aware action sequencing, and WorkBench (Styles et al. 2024), which evaluates realistic multistep workflows. We additionally include MATH (Hendrycks et al. 2021) as a reasoning benchmark to test whether coordination improvements generalize to tasks that primarily require structured reasoning. All methods use Gemma 4 as the

backbone model (Google DeepMind 2026). For each benchmark, we evaluate 30 questions and repeat each experiment over three independent runs. Baselines. Single-Agent Methods. Single Agent directly solves each task using one language model agent. CoT solves each task with step-by-step reasoning using a single language model agent (Wei et al. 2023; Kojima et al. 2023). Self-Consistency samples multiple reasoning traces and selects the final answer through consistency-based aggregation (Wang et al. 2023b). Self-Refine iteratively improves the answer by generating feedback and revising the response (Madaan et al. 2023). Static Multi-Agent Workflows. Static Agentic Workflows use fixed communication structures throughout task solving. We evaluate voting, group-chat debate, fully linked debate, orchestrator without discussion, orchestrator with discussion, and an orchestrator tree structure. Among these workflows, multi-agent debate allows multiple agents to propose, critique, and revise candidate answers before producing a final decision (Du et al. 2023). Automatic Agentic System Design Methods. AFlow searches over agentic workflows using predefined operators and workflow-level optimization (Zhang et al. 2025a). ADAS uses an LLM-based meta-agent to iteratively propose improved agentic systems based on previous evaluations (Hu, Lu, and Clune 2025). AgentSquare searches over modular agentic system designs by composing agents, tools, memory, and workflow components (Shang et al. 2025). MASS jointly optimizes agent prompts and communication topologies within a multi-agent design space (Zhou et al. 2026).

Results Experimental Results and Analysis Overall performance. Table 1 shows MANTA performs consistently across information seeking, tool use, planning, workflow execution, and reasoning. MANTA achieves the strongest average score of 74.0 across the five benchmarks, leading the next best method by 5.8 points. It also improves on the Single Agent across every benchmark. The results indicate adapting the collaboration to each task provides a broad advantage rather than a gain limited to one task type. The supporting studies explain where this advantage comes from. The ablation study identifies strong initial planning as the largest contributor, while repair and past experience provide additional improvements. The mutation analysis shows the first change captures most of the benefit, with up to three changes extending coverage to the most difficult tasks. Past learned experience also improves results on the same benchmark and produces the only positive average gain when transferred across benchmarks. At the same time, MANTA uses the fewest tokens among the evaluated multi-agent systems. Together, these findings show that careful planning, targeted changes, and reusable experience improve overall performance without requiring more computation.

Category

System

Information Seeking and Tool Use Planning and Workflow Execution Reasoning Average BrowseComp StableToolBench PlanCraft WorkBench MATH Single Agent 34.4±4.2 74.4±7.9 61.1±1.6 41.1±5.7 85.6±6.3 59.3±2.5 Reasoning CoT 26.7±5.4 50.0±7.2 62.2±12.6 35.6±4.2 75.6±3.1 50.0±3.3 Models Self-Consistency 37.8±1.6 51.1±1.6 61.1±15.7 15.6±1.6 78.9±4.2 48.9±3.3 Self-Refine 14.4±3.1 68.9±1.6 62.2±15.0 35.6±4.2 96.7±2.7 55.6±3.2 Voting 43.3±2.7 85.6±1.6 61.1±1.6 41.1±1.6 92.2±1.6 64.7±0.8 Group Chat Debate 61.1±3.1 82.2±5.7 72.2±3.1 21.1±4.2 91.1±4.2 65.5±1.9 Fully Linked Debate 58.9±9.6 81.1±5.7 73.3±2.7 21.1±4.2 91.1±1.6 65.1±2.5 Static MAS Orchestrator w/o Discussion 53.3±2.7 82.2±1.6 74.4±1.6 23.3±4.7 94.4±3.1 65.5±1.3 Orchestrator w/ Discussion 64.4±4.2 80.0±0.0 73.3±2.7 20.0±2.7 93.3±0.0 66.2±1.1 Orchestrator Tree Structure 54.4±5.7 78.9±3.1 62.2±3.1 16.7±2.7 94.4±1.6 61.3±1.6 AFlow 12.2±3.1 66.7±5.4 21.1±4.2 61.1±4.2 96.7±0.0 51.6±1.7 ADAS 48.9±1.6 77.8±4.2 57.8±13.4 66.7±0.0 90.0±0.0 68.2±3.2 Adaptive MAS AgentSquare 32.2±1.6 88.9±5.7 34.4±6.8 62.2±3.1 96.7±2.7 62.9±1.7 MASS 50.0±2.7 50.0±5.4 70.0±0.0 46.7±0.0 95.6±1.6 62.5±1.2 Ours MANTA 76.7±4.7 82.2±3.1 76.7±3.3 43.3±2.7 91.1±5.7 74.0±1.8

Table 1: Main results across five benchmarks using Gemma 4 31B with medium reasoning effort. Methods are grouped into reasoning models, static MAS, and adaptive MAS. We report mean success rates over three runs, with standard deviations in subscript. Best results, including ties, are bolded. Expanding an overloaded branch

Success

StableToolBench and Browsecomp task

a0

a1

a2

Detected issue one worker covers several facets and encounters an unvalidated tool failure

T0 : star of 3

a0

Topology repair expand the overloaded worker into a dedicated subgroup

a1

a2

a3

a4

a5

T1 : two-level tree

Figure 3: Branch expansion. When one worker in the initial star becomes overloaded and encounters an unvalidated tool failure, MANTA expands that worker into a dedicated subgroup while preserving the unaffected branch.

Ablation Study We evaluate four variant versions of MANTA to measure the contribution of its main components. This experiment uses 30 tasks from each of BrowseComp, WorkBench, PlanCraft, and StableToolBench. Table 2 reports the average success rate across these four benchmarks. The first ablation replaces task-conditioned initial topology planning with a fixed coordinator–worker topology; it retains the Auditor and the repair-time mutation planner. The second retains the initial Topology Planner, but disables audit-triggered topology mutation. The remaining two settings either freeze updates to the long-term playbook or remove the long-term playbook entirely. Full MANTA achieves the highest average success rate. Replacing task-conditioned planning with a fixed topology causes the largest drop, from 71.7 to 57.5. Removing topology repair reduces the average to 60.8. Freezing or removing the long-term playbook gives smaller but consistent drops. These results show that initial topology planning and execution-time repair provide the largest gains, while cross-

Mean tokens per run

Ablation setting

(%)

Input Output

Total

Full MANTA

71.7

94,811

5,504 100,315

No initial Topology Planner

57.5 105,941

6,099 112,040

No topology mutation

60.8

67,528

4,577

No long-term playbook update No long-term playbook

67.5 66.7

97,145 74,067

5,474 102,620 4,289 78,356

72,105

Table 2: MANTA ablation results averaged across four benchmarks. Token counts include the amortized cost of batched long-term playbook updates.

run learning provides an additional benefit.

Effect of Mutation Budget We next test whether a larger topology-mutation budget helps MANTA solve more tasks. We run full MANTA with budgets from zero to three on 30 tasks from each of BrowseComp, StableToolBench, PlanCraft, and WorkBench. We evaluate the budgets progressively. Starting at zero, we retain solved tasks and isolate the unsuccessful ones. At each larger budget, we identify failures that flip to success and carry those successes forward. Thus, at budget b, a task is counted as solved if it has succeeded at any evaluated budget up to b. This measures the task coverage provided by the available repair budget. As shown in Figure 4, all four benchmarks improve as the available budget increases. The largest average gain comes from the first mutation opportunity, while later mutations provide smaller additional gains. These results show that bounded topology repair expands the set of tasks MANTA can solve.

BrowseComp

PlanCraft

StableToolBench

WorkBench

Type

Average

Offline In

1.0

Single

Single Agent

Static

Voting Orch. (No Disc.) Orch. (Tree) Orch. (Discussion) Fully Linked Group Chat

Adaptive

AFlow ADAS AgentSquare MASS

Ours

MANTA

0.9

Success rate

System

0.8 0.7 0.6

Out

Inference Total

Overall

In

Out

Total

Total

—

17,767

4,044

21,811

21,811

—

64,895 15,885 80,781 80,781 94,125 21,173 115,298 115,298 107,227 28,194 135,421 135,421 149,950 34,257 184,207 184,207 128,726 34,212 162,938 162,938 159,809 41,843 201,651 201,651

126,292 6,225 132,517 17,472 229,228 18,447 247,675 26,220 115,561 27,494 143,056 13,009 49,801 3,347 53,148 120,690 —

1,082 18,553 151,070 1,508 27,728 275,403 1,929 14,938 157,993 7,188 127,878 181,026

63,724 13,928

77,652

77,652

0.5 0.4 0

1

2

3

Mutation budget

Table 4: Mean token usage per run across four benchmarks. Offline costs correspond to workflow search or validation; MANTA’s inference usage includes 9,416 meta-level and 68,236 inner-agent tokens.

Figure 4: Success rate under different mutation budgets. Cross-domain transfer Method

PlanCraft → WorkBench

WorkBench → PlanCraft

ADAS

66.7 → 66.7

76.7 → 70.0

−3.3

AgentSquare

60.0 → 36.7

26.7 → 23.3

−13.3

Mean ∆

MASS

46.7 → 0.0

70.0 → 0.0

−58.3

MANTA

43.3 → 50.0

70.0 → 70.0

+3.3

In-domain playbook adaptation (MANTA) Method

PlanCraft → PlanCraft

MANTA

70.0 → 73.3

contrast, transferring the structures learned by the adaptive baselines produces neutral or substantially negative effects. MANTA transfers more effectively because its longterm playbook preserves inheritable and actionable structural knowledge rather than fixed workflows optimized for predefined training tasks. Since MANTA does not assume a specific training-task set, these results demonstrate its ability to dynamically adapt its topology to different tasks and domains.

WorkBench → WorkBench Mean ∆ 43.3 → 46.7

+3.3

Table 3: Playbook transfer at mutation budget zero. Each cell reports the success rate before and after transferring sourcebenchmark experience. The pre-transfer success rate is the median across three runs (%).

Transferability of the Long-Term Playbook A central goal of MANTA’s long-term playbook is to accumulate structural experience that remains useful beyond the tasks on which it was originally acquired. We therefore evaluate whether the learned playbook can improve topology initialization on unseen tasks from either the same benchmark or a different benchmark. This experiment examines whether MANTA learns reusable structural knowledge rather than benchmark-specific workflows. We construct a playbook from 30 source-benchmark runs and update it after every 10 runs. The resulting playbook is then frozen and evaluated on 30 target tasks. In-domain transfer uses the same benchmark for learning and evaluation, whereas cross-domain transfer exchanges PlanCraft and WorkBench as the source and target. We set the mutation budget to zero so that any performance difference comes solely from playbook-guided topology initialization rather than execution-time topology adaptation. As shown in Table 3, MANTA benefits from both indomain and cross-domain experience. In-domain reuse improves PlanCraft and WorkBench by 3.3 points each, while cross-domain transfer yields a mean gain of 3.3 points. In

Token Usage Although token efficiency is not the primary objective of MANTA, the results reveal an additional benefit of adaptive topology revision. As shown in Table 4, static multiagent systems often incur substantial inference costs because they execute fixed agent configurations and communication patterns regardless of task needs. Meanwhile, workflow-optimization methods can reduce inference-time usage, but introduce additional offline search or validation costs. MANTA achieves the lowest overall token consumption among the evaluated multi-agent systems. In particular, its meta-level operations account for only approximately 12% of its inference budget, suggesting that targeted topology planning and repair can improve coordination without introducing substantial token overhead.

Topology Evolution and Repair Expanding overloaded branches. Figure 3 shows a StableToolBench and Browsecomp task with multiple retrieval facets. The Planner initially selects a three-agent star in which a coordinator distributes the facets across two workers. During execution, one worker becomes responsible for several facets and encounters a tool failure without sufficient downstream validation. MANTA responds by expanding that worker into the hub of a dedicated subgroup. The topology evolves from a star into a two-level tree, increasing decomposition and specialization only within the affected branch. Changing verification and execution order. Figure 5 shows two repairs that modify coordination without increasing the size of the entire system. When a singleton produces

a low-confidence output without verification, MANTA adds a verifier and forms a two-agent chain. When parallel agents attempt the same state-changing action, MANTA replaces the star with a chain that serializes execution and prevents the action from being applied more than once.

Rewiring communication and inserting a critic Premature consensus a0

a1

Repairing verification and execution structure

a2

debate of 3

a0

a1

a0

low confidence no critic

Duplicate state-changing actions

a0

repeated write from parallel agents

a0

a1

proposer → verifier singleton

a2

a2

Unchecked answer low confidence no downstream check

singleton

a1

a1

star of 3

Missing validation

a0

a0

agents agree early open issues remain

a0

a1

a2

serialized chain

worker–critic debate

Figure 6: Rewiring and critic insertion. Illustration of two topology repairs that add a missing communication edge to transform a star into a fully connected debate and insert a critic to transform a singleton into a worker–critic debate. Highlighted elements indicate the modifications introduced by each repair.

parallel star

Figure 5: Verification and serialization repairs. Missing validation introduces a verifier, while duplicated statechanging actions replace parallel execution with a serialized chain.

Rewiring communication and inserting a critic. The traces contain two further repairs, and neither one grows a branch (Figure 6). The first rewires communication while keeping the agent set fixed. In the PlanCraft trace, all three agents agreed after the first turn, but the agreement came with imperfect confidence and issues still open, so the auditor flagged it as premature consensus. The repair kept all three agents and added the one edge the star lacked, a direct link between worker and verifier, turning the topology into a fully connected debate (Figure 6, top). The next turn passed the audit, terminated by consensus with confidence 1.0, and the answer received benchmark score of 1.0. The second repair adds validation capacity instead of another solver. In the Math500 trace, a single agent returned a low-confidence answer that no one checked. The repair inserted exactly one agent, assigned it the critic role, and paired the two in a debate (Figure 6, bottom). The next audit was again clean, and the run ended with a consensus confidence of 1.0 and a score of 1.0. The added agent never attempts the task itself; its only job is to check the answer that already exists. Insight. Topology evolution is not simply adding agents or edges. Of the five repairs above, only branch expansion makes the system larger: serialization reorders execution, rewiring changes who talks to whom, and critic insertion gives new compute a checking role rather than a solving one. In every case, the appropriate repair is determined by the structural failure visible in the execution trace, not by the size of the system.

How Well Does Trace Auditing Work? We evaluate the initial audit over all 450 MANTA runs without exposing benchmark verdicts to the system. Runs with no repair flag are correct 83.2 percent of the time, compared with 62.5 percent for flagged runs. The resulting 20.7 point separation shows that trace quality provides meaningful information about answer reliability while remaining independent of the benchmark answer. The Auditor identifies 75 of the 117 incorrect runs. On WorkBench it reaches F1 0.78 because empty branches and duplicated state changes leave clear process evidence. It rarely changes PlanCraft and MATH runs, which preserves the original reasoning process when no structural symptom is visible. MANTA applies 151 repairs. The number of process flags decreases after 60.9 percent of repairs, and 59.6 percent of named repair targets are absent from the next audit. Repaired runs produce a correct final answer in 69.5 percent of cases. A clean trace remains a reliability signal rather than a correctness guarantee, since agents can agree on the same incorrect answer without an observable process anomaly.

Conclusion We presented MANTA, a framework that enables multi-agent systems to revise their collaboration topology during task execution. By combining topology planning, trace-based auditing, targeted structural repair, and cross-run experience, MANTA adapts how agents communicate and validate information when the initial organization becomes insufficient. Our findings highlight topology as a distinct layer of self-improvement, where effective adaptation may involve rewiring communication, changing execution order, or adding validation rather than simply increasing the number of agents. This perspective opens a path toward agent systems that can reorganize their collaboration processes in response to emerging failures.

References Agrawal, L. A.; Tan, S.; Soylu, D.; Ziems, N.; Khare, R.; Opsahl-Ong, K.; Singhvi, A.; Shandilya, H.; Ryan, M. J.; Jiang, M.; Potts, C.; Sen, K.; Dimakis, A. G.; Stoica, I.; Klein, D.; Zaharia, M.; and Khattab, O. 2026. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. arXiv:2507.19457. Becker, J.; Kaesberg, L. B.; Bauer, N.; Wahle, J. P.; Ruas, T.; and Gipp, B. 2025. MALLM: Multi-Agent Large Language Models Framework. arXiv:2509.11656. Besta, M.; Blach, N.; Kubicek, A.; Gerstenberger, R.; Gianinazzi, L.; Gajda, J.; Lehmann, T.; Podstawski, M.; Niewiadomski, H.; Nyczyk, P.; and Hoefler, T. 2024. Graph of Thoughts: Solving Elaborate Problems with Large Language Models. Proceedings of the AAAI Conference on Artificial Intelligence, 38(16): 17682–17690. Brown, T. B.; Mann, B.; Ryder, N.; Subbiah, M.; Kaplan, J.; Dhariwal, P.; Neelakantan, A.; Shyam, P.; Sastry, G.; Askell, A.; Agarwal, S.; Herbert-Voss, A.; Krueger, G.; Henighan, T.; Child, R.; Ramesh, A.; Ziegler, D. M.; Wu, J.; Winter, C.; Hesse, C.; Chen, M.; Sigler, E.; Litwin, M.; Gray, S.; Chess, B.; Clark, J.; Berner, C.; McCandlish, S.; Radford, A.; Sutskever, I.; and Amodei, D. 2020. Language Models are Few-Shot Learners. arXiv:2005.14165. Dagan, G.; Keller, F.; and Lascarides, A. 2025. Plancraft: an evaluation dataset for planning with LLM agents. In Second Conference on Language Modeling. Du, Y.; Li, S.; Torralba, A.; Tenenbaum, J. B.; and Mordatch, I. 2023. Improving Factuality and Reasoning in Language Models through Multiagent Debate. arXiv:2305.14325. Fernando, C.; Banarse, D.; Michalewski, H.; Osindero, S.; and Rocktäschel, T. 2023. Promptbreeder: Self-Referential Self-Improvement Via Prompt Evolution. arXiv:2309.16797. Google DeepMind. 2026. Gemma 4 Model Card. https: //ai.google.dev/gemma/docs/core/model_card_4. Accessed: 2026-07-03. Guo, Z.; Cheng, S.; Wang, H.; Liang, S.; Qin, Y.; Li, P.; Liu, Z.; Sun, M.; and Liu, Y. 2024. StableToolBench: Towards Stable Large-Scale Benchmarking on Tool Learning of Large Language Models. In Ku, L.-W.; Martins, A.; and Srikumar, V., eds., Findings of the Association for Computational Linguistics: ACL 2024, 11143–11156. Bangkok, Thailand: Association for Computational Linguistics. Hendrycks, D.; Burns, C.; Kadavath, S.; Arora, A.; Basart, S.; Tang, E.; Song, D.; and Steinhardt, J. 2021. Measuring Mathematical Problem Solving With the MATH Dataset. In Thirty-fifth Conference on Neural Information Processing Systems Datasets and Benchmarks Track (Round 2). Hong, S.; Zhuge, M.; Chen, J.; Zheng, X.; Cheng, Y.; Zhang, C.; Wang, J.; Wang, Z.; Yau, S. K. S.; Lin, Z.; Zhou, L.; Ran, C.; Xiao, L.; Wu, C.; and Schmidhuber, J. 2024. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. arXiv:2308.00352. Hu, S.; Lu, C.; and Clune, J. 2025. Automated Design of Agentic Systems. arXiv:2408.08435.

Khattab, O.; Singhvi, A.; Maheshwari, P.; Zhang, Z.; Santhanam, K.; Vardhamanan, S.; Haq, S.; Sharma, A.; Joshi, T. T.; Moazam, H.; Miller, H.; Zaharia, M.; and Potts, C. 2023. DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv:2310.03714. Kojima, T.; Gu, S. S.; Reid, M.; Matsuo, Y.; and Iwasawa, Y. 2023. Large Language Models are Zero-Shot Reasoners. arXiv:2205.11916. Li, G.; Hammoud, H. A. A. K.; Itani, H.; Khizbullin, D.; and Ghanem, B. 2023. CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society. arXiv:2303.17760. Lu, J.; Zhong, W.; Huang, W.; Wang, Y.; Zhu, Q.; Mi, F.; Wang, B.; Wang, W.; Zeng, X.; Shang, L.; Jiang, X.; and Liu, Q. 2024. SELF: Self-Evolution with Language Feedback. arXiv:2310.00533. Madaan, A.; Tandon, N.; Gupta, P.; Hallinan, S.; Gao, L.; Wiegreffe, S.; Alon, U.; Dziri, N.; Prabhumoye, S.; Yang, Y.; Gupta, S.; Majumder, B. P.; Hermann, K.; Welleck, S.; Yazdanbakhsh, A.; and Clark, P. 2023. Self-Refine: Iterative Refinement with Self-Feedback. arXiv:2303.17651. Opsahl-Ong, K.; Ryan, M. J.; Purtell, J.; Broman, D.; Potts, C.; Zaharia, M.; and Khattab, O. 2024. Optimizing Instructions and Demonstrations for Multi-Stage Language Model Programs. arXiv:2406.11695. Ouyang, L.; Wu, J.; Jiang, X.; Almeida, D.; Wainwright, C. L.; Mishkin, P.; Zhang, C.; Agarwal, S.; Slama, K.; Ray, A.; Schulman, J.; Hilton, J.; Kelton, F.; Miller, L.; Simens, M.; Askell, A.; Welinder, P.; Christiano, P.; Leike, J.; and Lowe, R. 2022. Training language models to follow instructions with human feedback. arXiv:2203.02155. Park, J. S.; O’Brien, J. C.; Cai, C. J.; Morris, M. R.; Liang, P.; and Bernstein, M. S. 2023. Generative Agents: Interactive Simulacra of Human Behavior. In the 36th Annual ACM Symposium on User Interface Software and Technology (UIST ’23), UIST ’23. New York, NY, USA: Association for Computing Machinery. Pryzant, R.; Iter, D.; Li, J.; Lee, Y. T.; Zhu, C.; and Zeng, M. 2023. Automatic Prompt Optimization with "Gradient Descent" and Beam Search. arXiv:2305.03495. Qian, C.; Liu, W.; Liu, H.; Chen, N.; Dang, Y.; Li, J.; Yang, C.; Chen, W.; Su, Y.; Cong, X.; Xu, J.; Li, D.; Liu, Z.; and Sun, M. 2024. ChatDev: Communicative Agents for Software Development. In Ku, L.-W.; Martins, A.; and Srikumar, V., eds., Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 15174–15186. Bangkok, Thailand: Association for Computational Linguistics. Schick, T.; Dwivedi-Yu, J.; Dessì, R.; Raileanu, R.; Lomeli, M.; Zettlemoyer, L.; Cancedda, N.; and Scialom, T. 2023. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761. Shang, Y.; Li, Y.; Zhao, K.; Ma, L.; Liu, J.; Xu, F.; and Li, Y. 2025. AgentSquare: Automatic LLM Agent Search in Modular Design Space. arXiv:2410.06153.

Shinn, N.; Cassano, F.; Berman, E.; Gopinath, A.; Narasimhan, K.; and Yao, S. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366. Styles, O.; Miller, S.; Cerda-Mardini, P.; Guha, T.; Sanchez, V.; and Vidgen, B. 2024. WorkBench: a Benchmark Dataset for Agents in a Realistic Workplace Setting. In First Conference on Language Modeling. Suzgun, M.; Yuksekgonul, M.; Bianchi, F.; Jurafsky, D.; and Zou, J. 2025. Dynamic Cheatsheet: Test-Time Learning with Adaptive Memory. arXiv:2504.07952. Wang, G.; Xie, Y.; Jiang, Y.; Mandlekar, A.; Xiao, C.; Zhu, Y.; Fan, L.; and Anandkumar, A. 2023a. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291. Wang, X.; Wei, J.; Schuurmans, D.; Le, Q.; Chi, E.; Narang, S.; Chowdhery, A.; and Zhou, D. 2023b. Self-Consistency Improves Chain of Thought Reasoning in Language Models. arXiv:2203.11171. Wang, Z. Z.; Mao, J.; Fried, D.; and Neubig, G. 2024. Agent Workflow Memory. arXiv:2409.07429. Wei, J.; Sun, Z.; Papay, S.; McKinney, S.; Han, J.; Fulford, I.; Chung, H. W.; Passos, A. T.; Fedus, W.; and Glaese, A. 2025. BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents. arXiv:2504.12516. Wei, J.; Wang, X.; Schuurmans, D.; Bosma, M.; Ichter, B.; Xia, F.; Chi, E.; Le, Q.; and Zhou, D. 2023. Chain-ofThought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903. Wu, Q.; Bansal, G.; Zhang, J.; Wu, Y.; Li, B.; Zhu, E.; Jiang, L.; Zhang, X.; Zhang, S.; Liu, J.; Awadallah, A. H.; White, R. W.; Burger, D.; and Wang, C. 2023. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155. Xu, W.; Liang, Z.; Mei, K.; Gao, H.; Tan, J.; and Zhang, Y. 2025. A-MEM: Agentic Memory for LLM Agents. arXiv:2502.12110. Yao, S.; Yu, D.; Zhao, J.; Shafran, I.; Griffiths, T. L.; Cao, Y.; and Narasimhan, K. 2023a. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601. Yao, S.; Zhao, J.; Yu, D.; Du, N.; Shafran, I.; Narasimhan, K. R.; and Cao, Y. 2023b. ReAct: Synergizing Reasoning and Acting in Language Models. In The Eleventh International Conference on Learning Representations. Yin, Z.; Sun, Q.; Chang, C.; Guo, Q.; Dai, J.; Huang, X.; and Qiu, X. 2023. Exchange-of-Thought: Enhancing Large Language Model Capabilities through Cross-Model Communication. arXiv:2312.01823. Yuksekgonul, M.; Bianchi, F.; Boen, J.; Liu, S.; Huang, Z.; Guestrin, C.; and Zou, J. 2024. TextGrad: Automatic "Differentiation" via Text. arXiv:2406.07496. Zhang, J.; Xiang, J.; Yu, Z.; Teng, F.; Chen, X.; Chen, J.; Zhuge, M.; Cheng, X.; Hong, S.; Wang, J.; Zheng, B.; Liu, B.; Luo, Y.; and Wu, C. 2025a. AFlow: Automating Agentic Workflow Generation. arXiv:2410.10762.

Zhang, Q.; Hu, C.; Upasani, S.; Ma, B.; Hong, F.; Kamanuru, V.; Rainton, J.; Wu, C.; Ji, M.; Li, H.; Thakker, U.; Zou, J.; and Olukotun, K. 2025b. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. arXiv:2510.04618. Zhou, H.; Wan, X.; Sun, R.; Palangi, H.; Iqbal, S.; Vulić, I.; Korhonen, A.; and Arik, S. O. 2026. Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies. In The Fourteenth International Conference on Learning Representations. Zhou, Y.; Muresanu, A. I.; Han, Z.; Paster, K.; Pitis, S.; Chan, H.; and Ba, J. 2023. Large Language Models are Human-Level Prompt Engineers. In The Eleventh International Conference on Learning Representations.

Implementation Details Experimental Setup and Fair Comparison For fair comparison, all multi-agent methods are constrained to the same maximum number of agents and comparable inference budget. Static workflows use the same set of agent roles as MANTA but keep their communication topology fixed throughout the entire task-solving process. For optimization-based baselines such as AFlow, ADAS, AgentSquare, and MASS, we follow their original optimization procedures when applicable and match the search budget as closely as possible. For MANTA, topology revision is performed online according to intermediate collaboration signals, and the revised topology is used for subsequent reasoning steps. Unless otherwise stated, the final answer is produced by the designated aggregator or coordinator agent.

Effect

add_agent

Add one agent to an existing group, with a specified structural role (e.g., verifier) and stage role (worker or critic). Turn one agent into the hub of a new nested subgroup with its own interaction pattern and members. Change the interaction pattern of an existing group (e.g., star → debate, star → chain). Add or remove a direct communication link between two agents. Adjust an agent’s information visibility (e.g., grant global access to the shared evidence ledger).

expand_agent_ to_group set_group_pattern

add_edge, remove_edge set_context_policy

Table 6: Bounded topology mutation operators available to the Planner during trace-backed repair.

MANTA Configuration Table 5 lists the configuration used in all MANTA experiments. All meta-agents (Topology Planner, Trace Auditor, and Skill Reflector) use the same backbone model as the task agents, with temperature 0. If the Planner returns an invalid or unparseable plan, the Orchestrator substitutes a deterministic fallback topology (a coordinator–worker star, or a singleton when the budget is one agent). Parameter

Value

Maximum initial agents Maximum total agents (after repair) Topology mutations per run Operations per mutation Root interaction patterns

5 10 1 ≤3 singleton, star, chain, debate, voting 0.0 12 runs

Meta-agent temperature long-term playbook reflection batch size

Operator

Retrieval-heavy tasks use the same audit and budget gate but a separate deterministic mutation. The resource guard selects the existing non-coordinator that made the most search calls (with deterministic tie-breaking), replaces the active topology by a singleton containing that agent, grants it global evidence access, and assigns a focused evidence-recovery directive. This retrieval contraction does not add agents and is not part of the Planner’s mutation language. It avoids rerunning a wide set of searchers after the first fan-out has already failed. All old packets, evidence, and turn-level candidates remain in the append-only run state under both repair paths.

Table 5: MANTA hyperparameters.

Topology Mutation Operators Deterministic Audit Taxonomy For a non-retrieval task, a repair is expressed as at most three of the operators in Table 6. The Planner emits a compact JSON object containing a rationale and an ordered operation list. Deterministic code discards unknown operators, normalizes role aliases, and attaches the current audit modes as the mutation targets. It then applies the operations to a copy of the current topology specification. The new version is accepted only if it passes full structural validation (unique group membership, valid identifiers and roles, acyclic attachment structure, legal group patterns, and the maximum agent budget); otherwise the proposal is rejected before any agent is instantiated. A conservative repair compiler may then map the grounded audit modes to one local edit; if it cannot do so, execution finalizes without a mutation.

The deterministic component of the Trace Auditor scans the execution trace for the fixed process-anomaly patterns in Table 7. The implementation calls these patterns “failure modes,” but the term is diagnostic: a match means that an encoded risk is visible in the trace, not that the final answer is incorrect. Each flag carries a severity, the implicated agents, and a repairability field; the open-set LLM auditor may add further trace-grounded flags beyond this taxonomy.

Process flag

Signal in the trace

Benchmark

tool_error_cascade

Repeated failing tool calls within a branch. A branch yields no substantive artifact (blocked or empty output). An agent declares the task unanswerable without supporting evidence. Agents agree the task is unanswerable without independent verification. Gathered evidence is absent from the synthesis input. Agreement despite low confidence or open unresolved issues. Relay-packet compaction dropped load-bearing content. Too few distinct queries for a broad retrieval task. The same state-changing tool call is issued by multiple agents. A high-precision task lacks a distinct verification step. Every candidate answer concludes that the task cannot be completed.

BrowseComp StableToolBench PlanCraft WorkBench MATH

83 67 1 47 2

0.25 0.21 1.00 0.81 0.50

All

200

0.38 0.64 0.38

branch_collapse

unsupported_ impossibility_claim unverified_impossibility_ consensus evidence_lost_ before_synthesis premature_consensus message_ compaction_loss insufficient_ search_coverage duplicate_state_mutation missing_validator give_up_shaped_ candidate

Table 7: Deterministic process-anomaly taxonomy used by the Trace Auditor. Internal identifiers retain the implementation’s failure_mode vocabulary.

Trace Auditing Statistics This section is the aggregate results of Trace Auditing over the 450 MANTA runs. Correctness-proxy scores per benchmark. Table 8 compares the initial repair-level audit flag with benchmark answer incorrectness. Using the first audit avoids evaluating a detector after its own intervention. Here precision, recall, FPR, and FNR use answer incorrectness as the positive class. They must not be read as literal process-detection scores: no human label says whether a trace truly contains a coordination defect. “False positive” therefore means only flagged but ultimately answer-correct, and “false negative” means clean but answer-incorrect. Across all runs, the audit flags 64.1 percent of incorrect answers at 37.5 percent precision. The aggregate FPR and FNR are 37.5 and 35.9 percent. The benchmark spread is more informative than the aggregate: WorkBench answer errors often co-occur with visible workflow anomalies, whereas PlanCraft and MATH frequently contain wrong reasoning with no observable coordination symptom. BrowseComp and StableToolBench show the opposite difficulty: retrieval or tool-use anomalies are common but often recoverable, producing high proxy FPR.

Flag Prec. Rec. FPR FNR 1.00 0.88 0.05 0.75 0.13

0.90 0.72 0.00 0.23 0.01

0.00 0.13 0.95 0.25 0.88

F1 0.40 0.34 0.09 0.78 0.20

0.36 0.47

Table 8: Initial audit as a proxy for answer incorrectness, with 90 runs per benchmark. Flag is the number of runs whose audit recommends repair. Metrics treat benchmarkincorrect as positive; they do not use manually annotated process-failure ground truth. Initial audit

Incorrect

Correct

Repair flag No repair flag

75 42

125 208

Total

117

333

Table 9: Initial audit outcome versus benchmark correctness over all 450 MANTA runs. Which process flags correlate with correctness. Table 10 reports, for each mode, how many runs it appears in, the difference in success rate between runs where it fires and runs where it does not, and how often a repair that targeted it removed it from the following audit. Seven of the nine modes are associated with a lower success rate, and the four strongest of them carry a gap of more than 30 points, showing that several deterministic detectors contain useful correctness information. This association does not establish that every firing is a true process defect. Two modes, relay-packet compaction loss and failing tool calls, show no such gap. They capture recoverable events that a competent topology absorbs, and down-weighting them in the severity gate is a direct way to raise precision in future work. Process flag Evidence lost before synthesis Missing validator Branch collapse Give-up shaped candidate Premature consensus Duplicate state mutation Insufficient search coverage Message compaction loss Tool error cascade

Runs

∆ succ.

Cleared

7

−60.7

6/6

71 100 36 48 143 68

−46.1 −38.6 −32.1 −17.5 −14.2 −5.8

17/19 4/12 n/a 9/11 23/39 n/a

131 61

+2.2 +5.4

5/8 23/51

Table 10: Detected process flags over all 450 runs. ∆ succ. is the success rate of runs containing the mode minus the success rate of runs without it, in percentage points, against an overall rate of 74.0. Cleared is the share of repairs targeting that mode after which the mode is absent from the next audit. Modes marked n/a are only observed on retrieval runs, which are repaired by a deterministic contraction that names no target.

Effect of repair in detail. The pre/post comparison is made on audit outputs, not benchmark counterfactuals. Of 151 repairs, 92 (60.9%) reduce the total number of flags, 27 (17.9%) leave it unchanged, and 32 (21.2%) increase it; 27 (17.9%) leave a trace with no flag of any severity. For the 146 named non-retrieval targets, 87 (59.6%) are absent from the following audit. Target names are attached from the audit by construction, so their 146/146 consistency is a schema invariant, not evidence that the recommendation was semantically correct. The condition MANTA uses to write an entry into longterm memory is stricter than a clean audit alone, since it also requires the run to terminate by decision-grade consensus. Runs meeting that stricter condition are correct 85.8 percent of the time against 74.0 percent for the corpus. This supports using the condition as a high-yield process-only filter, while the remaining 14.2 percent error rate shows why it cannot be treated as a correctness label. Which operators are used. Table 11 shows how the 151 repairs were expressed as 162 operations: 140 repairs use one operation and 11 use two; none reaches the threeoperation limit. The deterministic retrieval contraction is the most frequent operation. Among Planner-language operations, changing the group pattern and expanding a branch dominate. Adding a new agent accounts for only 9.3 percent of operations. Duplicated state-changing calls are answered by serializing the group into a chain in 33 of 39 targeted cases, a missing verification step is answered by adding a critic agent in 15 of 19 cases, and a failing tool branch is answered by expanding that agent into a subgroup in 28 of 51 cases. Thus repair more often changes execution structure than increases agent count. Operation Deterministic retrieval contraction set_group_pattern expand_agent_to_group add_agent set_context_policy remove_edge add_edge

Count

Share

68 44 33 15 1 1 0

42.0% 27.2% 20.4% 9.3% 0.6% 0.6% 0.0%

Table 11: Repair operators applied across all runs. Counts are per operation (162 total), and a single repair may combine up to three. The retrieval contraction is a fixed structural narrowing applied without invoking the Planner. Complementary validation. The current evaluation measures how strongly the audit predicts answer correctness and how often repair removes its named process target. Two extensions can provide further resolution. Human annotation of a stratified trace sample can directly evaluate process flag precision and recall, with agreement reported across independent annotators. A paired replay can compare the recommended mutation with an equal budget continuation from the same trace prefix. This design would isolate the effect of the recommendation while preserving the process-only setting used by MANTA.

Comparison with Automated Design Frameworks The reproduced automated design baselines select workflows using aggregate validation performance and keep those workflows fixed during test-time execution. MANTA combines prior topology experience with signals from the current trace. Memory guides the initial design, while observed process evidence determines whether the topology should be retained or revised. This distinction is visible on BrowseComp. AFlow uses an answer, review, and revise sequence, but later stages reuse the initial evidence. ADAS retains one reasoning agent without an independent retrieval path. AgentSquare combines reflection with tools but does not preserve a dedicated evidence validation route. MASS uses repeated debate, where agents can reinforce an answer supported by the same evidence. MANTA can instead add an independent retrieval or validation path for the affected instance. Its advantage comes from revising the structure that produced the observed process issue.

Meta-Agent Prompts We reproduce the system prompts and message templates of the three meta-agents. Placeholders such as ⟨task preview⟩ are filled deterministically at run time; the wording is otherwise verbatim. Topology Planner: Initial Planning The Planner receives the task and the long-term playbook ; it never sees the benchmark identity beyond the name of the task source, and it never sees ground-truth outcomes. Planner system prompt (initial plan) You are an expert topology planner (architect) for a multi-agent system. Given one task, you design a small, query-conditioned topology of specialized agents. Work in three steps: (1) analyze the task, (2) choose the topology its analysis implies, (3) justify the choice and say what each agent does. You return only a compact JSON plan; deterministic code expands and validates it. Analyze along three axes: • task type: retrieval/search, multi-step reasoning, coding, external tool use, state mutation, verification, planning, comparison, summarization, etc.; • attributes: ambiguity, need for breadth/parallelism, need for debate, need for verification, hallucination risk, whether external state is mutated, whether tools are required, whether outputs must be aggregated; • failure risks: duplicated writes, thin search coverage, premature consensus, weak verification, poor decomposition. Prefer the smallest topology that covers the work – extra agents cost tokens and can conflict – but do provision enough agents to cover the task (for example, several searchers for broad retrieval). Count independent evidence sources, not requested output fields: when one read-only API call or structured dataset can supply all fields, assign exactly one retriever and at most one verifier over its relayed result; do not send parallel agents to repeat the same call. Consult the topology planning

skill / accumulated experience below (standing principles, how-to-choose guidance, and lessons from prior runs); follow it unless this task clearly calls for otherwise.

Planner user message (initial plan) Plan the topology for one task from the ⟨benchmark name⟩ benchmark. Task preview. ⟨first 800 characters of the task prompt⟩ Topology planning skill (accumulated experience — consult before choosing). ⟨long-term playbook document⟩ Constraints. • Total agents (root group plus all subgroup members) must be ≤ ⟨max agents⟩. • Root patterns: singleton | star | chain | debate | voting. • star requires num_agents ≥ 2 (one coordinator plus workers). • debate and voting require num_agents ≥ 2. • Optional expansions turn one root worker into the hub of a nested subgroup (member_index counts root workers from 0, excluding the coordinator; num_subagents ≥ 1, or ≥ 2 for debate/voting). • Optional “verifier”: true makes the last root worker a critic that verifies instead of producing parallel work. Output format. Return ONLY one JSON object, no markdown fences, of the form: {“task_analysis”: {“task_type”: “...”, “attributes”: [“...”], “failure_risks”: [“...”]}, “rationale”: “why this topology fits and what each agent does”, “pattern”: “star”, “num_agents”: 3, “verifier”: false, “expansions”: []}

Topology Planner: Trace-Backed Repair At repair time the Planner is conditioned on the current topology, the audit report, and both playbook horizons: the short-term log of this run’s turns and the long-term skill document. Planner system prompt (repair mutation) You are a topology planner performing one step in a bounded trace-backed repair loop for a multi-agent system. Given the current topology and audit findings, propose ONE small mutation that addresses the strongest failure signal. You return only a compact JSON mutation; deterministic code applies and validates it. If no mutation is clearly useful, return {“ops”: []}. A repair must have counterfactual information gain. If the current agents already queried the same read-only API or structured dataset, do not add or expand agents with identical access: change context/decision structure, add at most one evidence-checking verifier, or return no mutation. More agents cannot repair data that the source did not return. Weigh the topology planning skill and playbook memories below as accumulated experience when choosing the repair.

Planner user message (repair mutation) Current topology (version ⟨v⟩). One line per group: ⟨group id⟩: pattern, members, and leader. Audit findings. One line per finding – ⟨mode⟩ [⟨severity⟩] ⟨implicated agents⟩: ⟨detail⟩ – followed by the Auditor’s one-sentence recommendation. Topology planning skill (accumulated experience — consult before mutating). ⟨long-term playbook document⟩ Playbook repair memories (long-term and turnlevel). ⟨short-term playbook entries from this run⟩ Available ops (at most 3 per mutation). • expand_agent_to_group: {“op”: “expand_agent_to_group”, “agent_id”: “agent_1”, “pattern”: “star|chain|debate|voting”, “num_subagents”: 3} – the agent becomes the hub of a new subgroup. • set_group_pattern: {“op”: “set_group_pattern”, “group_id”: “g_root”, “pattern”: “debate”} • add_agent: {“op”: “add_agent”, “group_id”: “g_root”, “structural_role”: “verifier”, “stage_role”: “critic”} • add_edge / remove_edge: {“op”: “add_edge”, “src”: “agent_1”, “dst”: “agent_2”} • set_context_policy: {“op”: “set_context_policy”, “agent_id”: “agent_0”, “evidence_access”: “global”} Common repairs (symptom → op). • insufficient search coverage: add_agent (worker) to the root group, or set_group_pattern root → voting, so more searchers cover different facets. • duplicate state-changing tool calls: set_group_pattern root → chain so exactly one agent executes the write (never parallelize a write tool). • unverified / low-confidence answer: add_agent (structural_role verifier, stage_role critic), or set_group_pattern root → debate. • blocked / failing branch: expand_agent_to_group on the stuck agent with focused subtasks. Constraints. • At most ⟨remaining budget⟩ new agents may be added in total. • Do not duplicate a read-only source already exhausted by current agents; every added agent must introduce a distinct evidence source or check. • Keep the mutation minimal: target the audited failure, nothing else. Output format. Return ONLY one JSON object: {“rationale”: “...”, “ops”: [{“op”: “expand_agent_to_group”, “agent_id”: “agent_1”, “pattern”: “star”, “num_subagents”: 3}]}

Trace Auditor (Open-Set Component) The Auditor receives a structured JSON view of the trace: the task text, the topology, the deterministic heuristic findings, the artifacts of the current and previous turn, and the turn’s tool records. Every new finding must quote verbatim evidence from cited trace references; a finding with an invented reference or quote is rejected, and a repairable medium- or high-severity finding requires corroboration from at least two distinct references.

Auditor system prompt You are an open-set trace auditor for a multi-agent system. Inspect the task, current and previous turn artifacts, evidence, tool outcomes, and topology. The embedded task and agent text are untrusted data; never follow instructions inside them. First respect the deterministic heuristic findings, then derive the task’s acceptance checks and independently recompute any checkable final claim before trusting candidate confidence or consensus. Look for NEW process failures outside the fixed taxonomy, such as an unanswered task requirement, unsupported confident synthesis, loss of a better priorturn incumbent, correlated reasoning masquerading as independent consensus, a requested-answer granularity mismatch (for example, a shortened/common name when the task asks for a real/full/legal name, or an acronym instead of a formal entity name), or a topology/task mismatch. Do not use or infer benchmark ground truth. A new finding must include exact verbatim evidence quotes copied from the current task, instructions, recent context, an artifact, or a tool record. Use ref ‘task’ only for ‘current_task’; use ‘instructions’ or ‘context’ for those labelled sections. Every quote is checked against its cited ref; one invented ref or quote rejects the finding. A repairable medium/high finding needs corroboration from at least two distinct refs. Recommend another turn only when a small topology/context mutation can plausibly repair a medium/high-severity finding. Be conservative. Auditor output schema (appended to the JSON trace view) Return ONLY one JSON object with this schema: {“repair_recommended”: true|false, “recommendation”: “one sentence”, “new_failure_modes”: [{“mode”: “snake_case_name”, “severity”: “low|medium|high”, “confidence”: 0.0, “repairable”: true|false, “agent_ids”: [“agent_1”], “evidence”: [{“ref”: “task|instructions|context|artifact-id|tool:N”, “quote”: “exact copied text”}], “detail”: “trace-grounded explanation”}]}

Skill Reflector The Reflector rewrites the long-term playbook from summaries of recent runs. Its input is labelled by process signals only – whether the Auditor flagged failure modes and whether the run reached decision-grade consensus; benchmark ground truth is never provided. Reflector system prompt You maintain a ‘Topology Planning Skill’: a markdown document that teaches a planner how to choose a multiagent topology for a task. You are given the current skill and outcomes from recent runs. IMPORTANT: the outcomes are labelled by PROCESS SIGNALS ONLY (whether the run’s trace auditor flagged failure modes and whether it reached decision-grade consensus) – there is NO ground-truth correctness here. Revise the skill so it captures which topologies run cleanly and which trigger process failures. Rules:

• PRESERVE these sections, refining wording only, never deleting them: “Standing principles”, “How to choose a topology”. • Grow the “Lessons from experience” section: add or refine concise, actionable lessons grounded in the process signals (cite the evidence, e.g. ‘chain/3 ran clean 2/2 on tool-using medium retrieval; star/3 flagged duplicate_state_mutation 3x’). Speak of running cleanly / avoiding process failure modes, NOT of being ‘correct’ or ‘right’. • Keep every lesson GENERAL – key it on task characteristics (task type, tools, size, state mutation, search breadth), not on benchmark-specific trivia. • Prefer revising an existing lesson over duplicating it; drop lessons the new evidence contradicts. Keep the document tight and readable. • Output the COMPLETE updated markdown document and nothing else (no fences).

Task-Agent System Prompt Every task agent shares one structural system prompt that fixes its stage contract, output schema, and confidence rubric; role-specific and tool-specific clauses are appended per agent. Instruction priority is stated explicitly so that domain personas can never override stage behavior. Agents exchange compacted relay packets derived from these structured artifacts rather than raw transcripts, and information visibility is enforced in code when packets are read, not through prompt instructions. Task-agent system prompt (shared structural core) You are one agent in a deterministic multi-agent workflow. Agent ID: ⟨agent id⟩. Agent Role: ⟨structural role⟩. Stage Role: ⟨worker | critic | aggregator | planner⟩. Instruction priority: 1) structural stage contract, 2) tooluse contract, 3) task and benchmark instructions, 4) domain persona. Use only the task messages, the prior artifact, and the visible packets provided in this conversation. Do not invent hidden context. Return exactly one JSON object and do not wrap it in markdown. Required JSON keys: answer_artifact, summary, critique, revision_request, confidence, unresolved_issues, evidence_summary. Set confidence to reflect confidence in the current answer_artifact only, using this rubric: 0.0 = no answer or pure planning; 0.25 = weak hypothesis; 0.5 = plausible but incomplete; 0.75 = likely correct with remaining gaps; 1.0 = strongly supported final answer. If a field is unknown, use an empty string, an empty list, or a conservative confidence score. evidence_summary must summarize actual evidence from tool outputs, visible packets, or the prior artifact. Do not claim evidence that was not actually retrieved or provided. Answer-stage contract: answer_artifact must be the current best direct answer or a concise blocked-status explanation. Do not use answer_artifact for plans, tool lists, search strategies, or sub-question lists. • Worker contract: gather or apply evidence, then state the best supported answer you can defend.

• Critic contract: challenge weak claims, verify against available evidence, and revise toward the best supported answer. • Aggregator contract: synthesize peer outputs into one supported answer; do not simply restate unresolved debate.

• Material uncertainty may justify an independent evidence-checking critic. • Tasks requiring decomposition and aggregation may benefit from a coordinator. • A singleton is appropriate when another agent would not contribute distinct work.

Tool-use contract (tool-enabled stages): if evidence is missing or weak, call the relevant tool instead of narrating that you need to search. Do not return a blocked, unknown, or planning answer before at least one tool attempt unless the visible packets or prior artifact already contain sufficient evidence.

For external state mutation, exactly one agent may execute the mutating action; other agents may only read, plan, or verify. Use lessons from prior runs as evidenceweighted suggestions. Consider their relevance, sample size, and observed process failures, and depart from them when the current task analysis supports another topology. State why the selected topology is preferable to the simplest viable alternative.

Long-Term Playbook (Topology Planning Skill) The long-term playbook is a markdown document read in full by the Planner at both planning and repair time. Its first two sections are protected: the Reflector may refine their wording but never delete them. The final section is rewritten by the Reflector from process-signal-labelled run summaries. We show the document with the lessons accumulated during our experiments, typeset for readability. Topology planning skill document Standing principles. Always apply these, on any benchmark, even one never seen before. 1. Concentrate state changes in a single executor. Writes, sends, schedules, deletions, and payments must be performed by exactly one agent. Repeating the same state-changing action across agents wastes effort and can double-apply it, corrupting the result. Reading, planning, and genuinely independent sub-actions can still run in parallel. 2. Match the topology to the question’s shape. Parallel workers suit independent facets (breadth); a chain of clues where each step depends on resolving the previous is better served by shared context (chain or debate) so the reasoning assembles instead of fragmenting across agents that each see only a piece. Add an agent only when it does work the task needs – a verifier earns its slot only if it also gathers or checks evidence, not if it merely waits. 3. Distinguish a premature give-up from honest uncertainty. If the gathered evidence supports or points toward an answer (including by inference from partial clues), commit the best-supported one rather than stalling (“let me search more”) or returning a non-answer. Only when the evidence genuinely supports no answer should you say so and note what is missing – never fabricate. Convey degree of belief with a confidence value. How to choose a topology. Analyze the task’s dependency structure, evidence needs, action risks, aggregation requirements, and resource budget. Choose the smallest topology in which every agent has a distinct, necessary contribution. Treat the following as possibilities, not fixed mappings: • Independent subtasks may benefit from parallel workers. • Dependent subtasks may benefit from sequential execution or shared context.

Lessons from experience. Concrete patterns learned from prior runs, with the evidence behind them. The reflection agent grows and prunes this list. • Prefer voting over singleton or debate for toolless reasoning. Sequential or interactive topologies (chain/2, debate/2, star/2) and singletons correlate with higher process failure rates in tool-less reasoning contexts. Evidence shows voting/3 and voting/4 running clean 35/35 in these settings, while singleton/1 (0/6), debate/2 (0/4), and star/2 (0/1) have triggered process failures. • Minimize topology complexity to avoid signal loss. Inefficient or over-provisioned structures correlate strongly with message_compaction_loss (flagged repeatedly across runs). Keep the topology lean to ensure evidence is preserved through the pipeline without being truncated or lost during synthesis. • Include explicit validation for high-precision tasks. Relying on implicit aggregation without a dedicated validator can trigger process failures; the auditor has flagged missing_validator when topologies lacked a distinct verification step to audit the final synthesis.

Agent Harness and the Agentic Loop Every task agent runs inside a single shared harness that defines one stage-execution contract. The harness exposes one generation interface that takes the stage prompt, the tool schemas, a temperature, and a tool-iteration budget, and returns the stage text together with token usage and a structured record of every tool call. A stage execution proceeds as follows. Deterministic orchestrator code first assembles the stage prompt from fixed parts. These parts are the structural system prompt, the rolespecific clause, the stage directive, the relay packets the agent is allowed to see, and the bounded evidence digest. The harness then runs a bounded agentic loop, shown in Figure 7. In each iteration the model may either return tool calls or return a final text. Tool calls are executed by harness-owned handlers, and their outcomes are appended to the conversation as tool messages. When the model returns a final text without tool calls, the loop ends and the text is coerced into the structured JSON artifact of the stage contract. The runtime never fabricates tool calls after the fact. If the model claims evidence it did not retrieve, the claim simply remains

unsupported in the artifact and is visible to the Auditor. The loop manages its own context. Only the most recent k tool iterations are kept verbatim in the conversation. All older iterations are replaced by one deterministic summary message that lists, for every summarized iteration, the assistant text preview and each tool call with its arguments, status, and a compacted output. Full document text retrieved by a read tool is preserved in this summary up to a larger character budget, because retrieved evidence is the part of the history the final answer depends on. The model is told explicitly that the summary is compressed and that the latest raw tool messages win on any conflict. The loop also carries a set of deterministic guards (Table 12). They stop unproductive behavior early and convert every abnormal exit into a typed, non-silent outcome. In particular, when the iteration budget is exhausted or a hard timeout fires, the harness forces one final tool-free model call that must answer from the evidence already gathered, so the stage always produces an artifact rather than an empty output. After the stage returns, the orchestrator removes tool records whose exact tool name and arguments already ran earlier in the run, which guarantees that a replayed state-changing call is applied exactly once, and appends the artifact’s claims and evidence to the shared evidence ledger. If one agent trips its tool-failure circuit breaker, only that agent’s contribution is dropped and the remaining agents continue, so a single flaky tool cannot kill the whole task. Guard

Behavior

Duplicate call check

An identical tool call repeated inside one stage is answered from its earlier result instead of re-executing. When consecutive search iterations return the same result set, the loop steers the agent to read or answer instead of searching again. Repeated consecutive failures of the same tool end the tool phase for this stage (3 failures, 2 for search tools). An agent that searched but never opened a document may not return a blocked answer. It is redirected once to read the top hit first. On budget exhaustion, timeout, or an empty completion, one final tool-free call must produce a best-effort answer from the gathered evidence, recorded with a typed stop reason.

Stagnant search check

Failure circuit breaker

Read gate

Forced final answer

Table 12: Deterministic guards inside the agentic loop. Parameter

Value

Tool iterations per stage Raw tool iterations kept verbatim Summary budget for older iterations Preserved document text in summary Tool-failure circuit breaker (general / search)

8 2 6,000 chars 12,000 chars 3/2

Table 13: Agentic-loop defaults.

Assemble stage prompt structural contract + role clause + directive + visible packets + evidence digest

Build working context base messages + summary of older tool iterations + last 2 raw iterations

Model call with tool schemas next iteration

no / budget spent Tool calls returned?

(forced final answer)

yes Execute tool calls, record outcomes, apply guards (Table 12)

Coerce final text into the structured JSON stage artifact

Post-stage bookkeeping drop already-executed duplicate calls, append claims and evidence to the shared ledger

Figure 7: The agentic loop executed by the shared harness for one agent stage. The loop is identical for both LLM backends.

Worker Context Management Under Topology Mutation Agents in MANTA are stateless between stages. No agent owns a private chat history that survives a turn. All conversational state lives in one shared run state with three appendonly stores. The packet store holds every relay packet ever sent. The evidence ledger holds every claim and its supporting evidence, deduplicated by agent, turn, and claim text. The candidate list holds the best group output of each completed turn. A stage prompt is always rebuilt from these stores at execution time. What an agent sees is decided at read time, in code, by a shared context controller. When a stage is about to run, the controller selects the packets addressed to that agent, filters them by kind, turn, and sender, keeps only the latest packet per sender and kind, checks that the sender’s share scope permits the reader, and finally applies the reader’s own bounds such as summary-only compaction and a per-packet character budget. The controller also renders the evidence ledger into one bounded digest packet whose scope follows the reader’s policy. A worker may see only its own branch, while every final synthesis stage always receives the global digest. The digest is prompt-only context and is never written back into the packet store. This design makes topology mutation cheap and lossless, as sketched in Figure 8. A mutation is applied to a copy

Turn t agents

one bounded mutation

Turn t+1 agents topology spec v+1, new agents regis-

topology spec v

tered deterministically

Shared context controller applies the current spec at read time: recipient, kind, sender scope, latest per sender, reader bounds, evidence digest scope

Packet store

Evidence ledger

Turn candidates

append only

append only

temporal voting

Figure 8: Context management across a topology mutation. Agents are stateless and read the shared stores only through the controller, so re-pointing the controller at the mutated specification changes visibility without migrating or losing any state.

of the current topology specification and validated. The orchestrator then simply re-points the context controller at the new specification. Because every read is lazy, nothing is migrated, recomputed, or truncated. All packets, ledger entries, and candidates written under the old topology remain in the shared state, and the next turn’s agents inherit them automatically through the same read path. Only the visibility rules change, since branch membership, share scopes, and evidence access are now resolved against the new specification. Agents created by a mutation are registered deterministically. The orchestrator assigns their backbone model type, message budget, and domain persona from fixed rules without any extra LLM call. A new agent starts with an empty private context. Its first prompt is assembled from the task packets addressed to it, the packets its policy makes visible, and the evidence digest, so it can build on all prior evidence without ever seeing a raw transcript. Agents that a mutation removes from the active topology leave their packets and ledger entries behind, so their work is not lost. Two further mechanisms connect the mutated turn to the audited one. First, the Auditor’s one-sentence recommendation is injected into every stage directive of the repaired turn as an explicitly untrusted diagnosis. Agents are instructed to verify it against the task and to re-evaluate the prior answer under it, rather than to obey it blindly. Second, the best output of every earlier turn is preserved as a temporal candidate. Final answer selection votes over these candidates, so a mutation that makes the answer worse cannot overwrite a better incumbent from before the mutation.