Topological Coherence for Self-evolving Multi-agent Systems

1 INTRODUCTION

• Existing methods can jointly optimize system structures, yet do not explicitly keep responsibilities, collaboration, and memory compatible with task dependencies as the system changes.Task regions delimit responsibility and tool scope, cross-region dependencies create handoffs, and ownership boundaries delimit private and selectively shared memory.Source: §1 · p. 2
• Topological coherence means consistency among responsibility, collaboration, and memory relations derived from the task topology.It is not similarity between graph shapes; task regions, cross-region dependencies, and ownership boundaries provide a common organizational reference.Source: §1 · p. 2, Figure 1 · p. 2
• TOCOMAS grounds task graphs in tool interfaces, groups compatible regions into reusable agent domains, and derives handoffs and memory policies from those domains.Its online controller proposes coupled structural changes and retains candidates only when they are structurally valid and improve evaluated reward.Source: §1 · p. 2

2 RELATED WORK

• Automatic design searches computation graphs, agentic programs, and workflows, while many systems encode atomic roles or workflow nodes rather than reusable task-and-tool responsibility domains.Examples include GPTSwarm, ADAS, AFlow, AutoAgents, MASS, ARG-Designer, and MAS-Orchestra.Source: §2 · p. 2
• Other work adapts communication networks or organizes graph-based reasoning and memory, but does not jointly derive task ownership, tool authority, handoffs, and memory visibility from shared topology.These lines include dynamic agent networks, graph-conditioned reasoning, topological learning, and structured or episodic memory.Source: §2 · p. 3
• EvoMAS jointly evolves roles, prompts, models, tools, and communication, yet co-editing does not ensure compatible capabilities, handoffs, and memory permissions after structural changes.TOCOMAS instead derives these relations from shared task-and-tool regions.Source: §2 · p. 3

3 PROBLEM FORMULATION

• A multi-agent system configuration contains a communication graph, agent configurations, and designated input and output agents.Each agent configuration specifies a backbone model, prompt, and accessible tool set.Source: §3 · p. 3
• For each task, a tool-grounded topology and responsibility and ownership maps produce a task-conditioned configuration with collaboration and memory policies.Coherence requires capable owners for responsibility regions, compatible handoffs for required cross-region dependencies, and memory visibility consistent with ownership boundaries.Source: §3 · p. 3
• Candidate reward is accepted execution quality minus a weighted resource cost, and traces guide proposals retained only after structural checks and reward improvement.The weight β controls the performance–efficiency trade-off.Source: §3 · p. 3

4.1 TOPOLOGICAL AGENT ORGANIZATION

• Operationally compatible task nodes form responsibility regions, whose quotient preserves cross-region dependencies and must remain acyclic.Regions merge only when task and tool capacities are respected; an agent may own multiple compatible regions, while distinct regions remain separated.Source: §4.1 · pp. 4–5

4.2 STRUCTURE-ADAPTIVE COLLABORATIVE ORCHESTRATION

• Collaboration combines dependency-induced handoffs with profile-conditioned communication opportunities, while routing exposes only artifacts required downstream.A verifier request may also be triggered when required.Source: §4.2 · p. 5

4.3 BOUNDARY-PRESERVING MEMORY COORDINATION

• Memory visibility follows responsibility boundaries: ownership and sharing permissions filter records before semantic retrieval and typed graph expansion.When task-region ownership changes, supported records transfer with provenance and updated access metadata, preventing orphaned experience and unintended global sharing.Source: §4.3 · pp. 5–6

4.4 COHERENCE-CONSTRAINED STRUCTURAL EVOLUTION

• TOCOMAS derives ownership, collaboration, and memory policies from shared task-topology maps rather than imposing independent structural penalties.Concrete memory records are runtime state governed by the policy, not genes in the evolutionary configuration; proposals may change only a subset of policies while reconciling affected boundaries.Source: §4.4 · p. 6
• TOCOMAS accepts a proposed organization only after checking capable task-node ownership, required handoffs, and memory visibility against induced boundaries.Valid candidates are executed and selected against their parent using a prescribed reward margin; accepted organizations can be used by subsequently launched tasks.Source: §4.4 · p. 6

5.1 EXPERIMENTAL SETUP

• The study evaluates reasoning, stateful tool use, repository repair, and executable workflows, with native evaluators and controlled backbone and baseline comparisons.CoMemBench measures terminal success, verified progress, accepted handoffs, and memory isolation; its clean and polluted instances assess workflow quality.Source: §5.1 · pp. 6–7, §5 · p. 6

5.2 MAIN RESULTS

• On Qwen3.8-27B CoMemBench, TOCOMAS attains 14.30% SR, 41.60% VNCR, 51.00% VHS, and 84.90% ICS, compared with EvoMAS’s 1.00%, 30.42%, 30.73%, and 26.80%, respectively.With GPT-6-luna, TOCOMAS reaches 65.07% WorkBench SR and 49.58% CoMemBench VNCR, and leads EvoMAS on VHS, 54.57% versus 45.80%; CoMemBench SR is 9.00% for TOCOMAS and at most 0.50% for compared baselines.Source: §5.2 · p. 8

5.3 ABLATION STUDY

• Ablations associate responsibility assignment with verified progress, dependency-based handoffs with artifact acceptance, memory boundaries with isolation, and online evolution with task success.Canonical-order grouping lowers CoMemBench VNCR by 14.33 points; fixed predecessor handoffs reduce VHS by 40.85 points and SR to zero; globally visible verified records reduce ICS by 19.96 points; fixed structure lowers WorkBench SR by 6.52 points.Source: Table 2 · p. 8, §5.3 · p. 8

5.4 PARAMETER SENSITIVITY

• VNCR and VHS peak at 41.6% and 51.3% at organization-affinity threshold 0.60, while both measures peak at memory retrieval budget k = 3.Both measures decline at threshold 0.75 and as retrieval expands to k = 8.Source: §5.4 · p. 9, Figure 4 · p. 9

5.5 COST ANALYSIS

• At shared progress levels, TOCOMAS uses fewer tokens than other multi-agent curves on CoMemBench, while Direct LLM Call remains cheaper.On WorkBench, its plotted curve lies below Peer Review and SMoA but above Direct LLM Call and ADAS.Source: §5.5 · p. 9, Figure 5 · p. 9

6 CONCLUSION

• TOCOMAS grounds task nodes in tool requirements, groups compatible regions into agent responsibilities, and derives handoffs and memory boundaries from that organization.Online evolution retains improvements that satisfy executable and coherence constraints.Source: §6 · p. 10

REPRODUCIBILITY STATEMENT

• Native evaluators and retained execution receipts, handoff traces, and model-call ledgers support auditing.Source: REPRODUCIBILITY STATEMENT · p. 10

AI USE STATEMENT

• The authors report that generative AI tools assisted with manuscript drafting and language editing, and that they reviewed the material.Source: AI USE STATEMENT · p. 10

A.1 BENCHMARK INSTANCES

• BBEH evaluates difficult reasoning questions, WorkBench workplace tasks involving application tools, and SWE-Bench-Verified repository patches using each benchmark’s native evaluator.Source: §A.1 · p. 13
• CoMemBench contains 800 clean workflows and 800 matched polluted variants across stateful tool use, repository code, offline retrieval, and formal mathematics.Workflows specify task nodes, dependency edges, execution requirements, typed handoff contracts, resources, and a domain-native evaluator; verified receipts and artifact-exposure records support progress and handoff metrics.Source: §A.1 · p. 13

• BBEH answer accuracy, WorkBench task success rate, and SWE-Bench-Verified official resolved rate use their respective benchmark-level metrics.Source: §A.2 · p. 13
• CoMemBench reports Terminal Success Rate (SR) and Verified Node Completion Rate (VNCR); VNCR equally weights workflows and excludes private nodes and repeated attempts from its numerator.Source: §A.2 · p. 13
• Verified Handoff Success (VHS) counts a required handoff only when predecessor artifacts are exposed at the boundary, current, receipt-valid, explicitly consumed, and followed by verifier success.Source: §A.2 · p. 13
• Isolation Challenge Success (ICS) measures preservation of clean-run target success after an inapplicable artifact is introduced; eligible targets need clean target success, not full workflow success.Source: §A.2 · p. 13
• ICS is micro-pooled over eligible target pairs across four domains; polluted targets not reached or failing verification are excluded from P+, and cohorts without eligible cases are unavailable, not zero.Source: §A.2 · p. 13