Autonomous Topology Mutation: Safe Runtime Restructuring for Multi-Agent LLM Systems with Capability, State, and Shadow Invariants

# Safe Runtime Restructuring for Multi-Agent LLM Systems with Capability, State, and Shadow Invariants
Source: [https://arxiv.org/html/2607.20488](https://arxiv.org/html/2607.20488)
\(2026\)

###### Abstract\.

Multi\-agent LLM frameworks fix their team topology at boot time\. When an individual agent becomes overloaded at runtime — mixing too many action categories, accumulating tool errors, or queueing behind too many calls — the system has no mechanism to restructure\. We introduceAutonomous Topology Mutation \(ATM\), a runtime team\-mutation mechanism for multi\-agent LLM frameworks that combines telemetry\-driven overload detection with three formal safety invariants gating each structural change\. ATM continuously monitors a six\-signal*Bottleneck Index*that includes a role\-entropy term; when a warmup\-calibrated threshold is breached onKKconsecutive ticks, it factorises the overloaded agent into specialised sub\-agents and hot\-swaps the parent into a coordinator role\. Three formal invariants govern the mutation:I1\(children’s capabilities⊆\\subseteqparent’s\),I2\(every state atom is routed only to a PL\-permitted destination set, or explicitly dropped with a logged reason\), andI3\(no live change without a successful shadow pass\)\.

On 720 DeepSeek\-V3\-driven task runs with deterministic tool stubs for reproducibility \(two independent seeded runs of 360 trials each\) across four ablation conditions and three workloads, the ATM*factoriser split*lifts code\-task success from3\.3% to 61\.7%\(\+58\+58percentage points,p<10−10p<10^\{\-10\}\); adding role\-conditioned state distillation preserves a 48\.3% success rate \(no significant degradation vs\. A0,p=1\.00p=1\.00on the security\-sensitive workload\)\. The full rail\+distillation system reduces detected PL≥\\geq3 memory exposure under our regex classifier from2\.02\.0to0\.00\.0events per task; distillation further reduces per\-child exposure surface and high\-PL duplication\. The Rails carrying ATM’s invariants add less than500 µs of p99 latencyon the agent’s hot path\. The benchmark uses deterministic tool stubs for reproducibility; a small live\-tool probe with real Python execution is included as external validity\. ATM is implemented as a set ofDeepAgentRailsubclasses for the openjiuwen runtime; the implementation, benchmark harness, and traces are open\-sourced111[https://github\.com/sidikbro/jiuwen\_atm](https://github.com/sidikbro/jiuwen_atm)\.

Multi\-agent systems, LLM agents, runtime topology mutation, agent factorisation, capability monotonicity, AI safety

††conference:arXiv preprint; 2026;††journalyear:2026††copyright:none††ccs:Computing methodologies Multi\-agent systems††ccs:Computer systems organization Distributed architectures††ccs:Security and privacy Information flow control## 1\.Introduction

Multi\-agent LLM frameworks — AutoGen\(Wuet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib11)\), MetaGPT\(Honget al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib12)\), CrewAI\(Moura,[2024](https://arxiv.org/html/2607.20488#bib.bib13)\), and the openjiuwen runtime on which we build — have made it routine to assemble small teams of specialised agents that collaborate on complex tasks\. In all of these systems, however, the team topology is*fixed at boot time*: the operator specifies how many agents exist, which tools each one has, and how they communicate\. Once the system is running, the structure is inert\.

In practice, this creates a class of failure modes that no single\-agent optimisation can fix\. An agent provisioned for a research workload may suddenly start receiving code\-debug tasks; an agent provisioned for one output mode may find itself servicing a session that requires three; an agent whose memory was scoped to public references may inherit a session full of API keys\. In every case, the symptom is the same: a single agent is being asked to mix too many action categories simultaneously, its tool\-call success collapses, and the framework has no recourse other than to fail the task or paper over the failure with Reflexion\-style\(Shinnet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib1)\)self\-critique loops\.

We introduceAutonomous Topology Mutation \(ATM\), a runtime team mutation mechanism for multi\-agent LLM frameworks that combines telemetry\-driven overload detection with three formal safety invariants gating each structural change\. ATM continuously monitors a six\-signal*Bottleneck Index*that includes a role\-entropy term; when a warmup\-calibrated threshold is breached onKKconsecutive ticks, it factorises the overloaded agent into specialised sub\-agents and hot\-swaps the parent into a coordinator role\. Three formal invariants govern the mutation:I1\(children’s capabilities⊆\\subseteqparent’s\),I2\(every state atom is routed only to a PL\-permitted destination set, or explicitly dropped with a logged reason\), andI3\(no live change without a successful shadow pass\)\.

Why invariants matter\.Without I1, a runtime mutation could silently grant a child agent privileges its parent never had — exactly the failure mode that motivates static permission systems\. Without I2, distillation could leave high\-sensitivity memory atoms visible to multiple children or, worse, drop them entirely\. Without I3, a misfiring trigger could swap a working agent for a worse configuration mid\-task\. The combination of telemetry\-driven triggering and these three invariants is what distinguishes a deployable runtime mutation mechanism from an ad\-hoc topology\-rewriter\.

Contributions\.

- •C1\.We formulate the Bottleneck Index, a six\-signal overload detector that combines queue depth, context thrash, tool\-error rate, role entropy, retry\-loop rate, and cross\-agent wait time, with a warmup\-snapshotτ\\taucalibration that avoids self\-reinforcing drift under sustained overload\.
- •C2\.We propose ATM, a runtime topology\-mutation pipeline that factorises an overloaded agent into specialised children, distills the parent’s memory by trust\-level, hot\-swaps the parent into a coordinator, and validates the change in a 5\-task shadow window before commit\.
- •C3\.We define three formal invariants \(I1 capability monotonicity, I2 state\-routing completeness, I3 shadow\-before\-live\) that any deployable runtime topology mutation must satisfy, and show how each is enforced mechanically in our implementation\.
- •C4\.DeepSeek\-V3\-driven evaluation on 720 task runs with deterministic tool stubs, across four ablation conditions and three workloads, showing that the ATM split lifts code\-task success from 3\.3% to 61\.7% \(p<10−10p<10^\{\-10\}\) and that the full rail\+distillation system eliminates detected PL≥\\geq3 memory exposure while preserving task quality\.

The Rails carrying ATM’s mutation logic add less than 500 µs of p99 latency to the agent’s hot path\. The end\-to\-end ATM\-fires\-in\-production trace \(Section[6\.4](https://arxiv.org/html/2607.20488#S6.SS4)\) demonstrates the full pipeline triggering under realistic conditions\.

## 2\.Related Work

We organise prior work by what the system modifies about itself: the current execution path \(self\-healing\), agent skills and knowledge \(self\-improving\), or the agent’s structure and team composition \(self\-evolving and dynamic topology\)\.

#### Self\-healing\.

Reflexion\(Shinnet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib1)\)writes verbal self\-reflection between task attempts; Self\-Refine\(Madaanet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib2)\)iteratively critiques and revises an agent’s output; CRITIC\(Gouet al\.,[2024](https://arxiv.org/html/2607.20488#bib.bib3)\)uses tools to verify factual claims and revises if discrepancies are found\. Self\-Healing Router\(Bholani,[2026](https://arxiv.org/html/2607.20488#bib.bib4)\)reweights graph edges on tool failure so Dijkstra reroutes without invoking the LLM\. Constitutional AI\(Baiet al\.,[2022](https://arxiv.org/html/2607.20488#bib.bib5)\)bakes self\-critique into training rather than runtime\. All of these heal at the output or task level; they do not restructure the agent team itself\. ATM differs in exactly this respect: it does not merely repair outputs or arguments; it changes the agent\-team structure under telemetry\-driven overload detection and the three formal invariants\.

#### Self\-improving \(skills, prompts, memory\)\.

OpenClaw\(Steinberger and others,[2026](https://arxiv.org/html/2607.20488#bib.bib6)\)and Hermes Agent\(Nous Research,[2026](https://arxiv.org/html/2607.20488#bib.bib7)\)have the agent autonomously write SKILL\.md documents after solving hard problems; Hermes additionally uses GEPA prompt evolution\. JiuwenSwarm’s SkillSelfEvolution\(openJiuwen contributors,[2025](https://arxiv.org/html/2607.20488#bib.bib8)\)uses a rule\-based detector to trigger LLM\-driven skill refinement\. Auto\-Harness Expert\(openJiuwen contributors,[2026](https://arxiv.org/html/2607.20488#bib.bib9)\)extends this to the full Expert Harness extension \(prompts, skills, tools, MCP plugins, rails, personas\) via an offline assess\-plan\-implement\-verify pipeline\. DSPy\(Khattabet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib10)\)compiles prompts offline by search\. MemTier\(Sidik and Rokach,[2026](https://arxiv.org/html/2607.20488#bib.bib20)\)accumulates tiered episodic memory on the OpenClaw runtime with an attention\-attributed cognitive weight update loop\. None of these change the agent team’s composition\.

#### Self\-evolving \(structure, code\)\.

Auto\-Harness Meta\(openJiuwen contributors,[2026](https://arxiv.org/html/2607.20488#bib.bib9)\)optimises codebase\-level files and submits a PR for human review\. MetaGPT\(Honget al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib12)\), AutoGen\(Wuet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib11)\), and CrewAI\(Moura,[2024](https://arxiv.org/html/2607.20488#bib.bib13)\)define multi\-agent team topologies at startup and do not modify them at runtime\.

#### Dynamic MAS topology and role adaptation\.

A growing body of 2026 work adapts MAS topology at inference time through several complementary mechanisms: MetaGen\(Wanget al\.,[2026](https://arxiv.org/html/2607.20488#bib.bib15)\)edits role specifications and rewrites the execution graph from a controllable dynamic role pool; DyTopo\(Luet al\.,[2026](https://arxiv.org/html/2607.20488#bib.bib16)\)reconstructs a sparse directed communication graph at each reasoning round via semantic query/key matching; TacoMAS\(Xuet al\.,[2026](https://arxiv.org/html/2607.20488#bib.bib17)\)co\-evolves both topology and per\-agent capability at test time on different time scales; SkillMAS\(Panet al\.,[2026](https://arxiv.org/html/2607.20488#bib.bib18)\)couples MAS restructuring with skill evolution\. These systems typically generate or adapt communication graphs for a task\. ATM differs in three respects: \(i\) it operates on a*deployed live agent*, detecting overload from runtime telemetry rather than optimising a graph per query; \(ii\) the parent agent’s external identity \(agent\_idand A2A address\) is preserved across the mutation via a coordinator wrapper, so upstream callers see continuous service; \(iii\) every structural change is gated by three formal invariants \(capability monotonicity, state\-routing completeness, shadow\-before\-live\) — a property we have not seen in concurrent dynamic\-topology systems\.

#### Privacy and safety adjuncts\.

NeMo Guardrails\(Rebedeaet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib14)\)enforces policy\-driven LLM I/O filtering at the prompt boundary; OpenClaw enforces per\-skill trust via badges at install time\. ATM’s memory\-distillation and guardrail components operate at the span level inside the memory pipeline with graduated PL classification and per\-endpoint trust enforcement, which is finer\-grained than prior prompt\-boundary filtering\.

#### Self\-adaptive software systems\.

The classical Rainbow framework\(Garlanet al\.,[2004](https://arxiv.org/html/2607.20488#bib.bib19)\)establishes architecture\-based self\-adaptation for traditional software systems with monitor/analyse/plan/execute loops\. ATM extends this lineage to LLM\-driven multi\-agent systems with the addition of capability and privacy invariants that classical self\-adaptation literature did not need\.

## 3\.ATM System Architecture

ATM is a closed\-loop topology\-mutation system designed to operate as a set of pluggable rails within the openjiuwen multi\-agent runtime\. Its architecture consists of two interacting loops at different timescales: atactical monitoring loopthat updates telemetry every tick, and astrategic mutation pipelinethat triggers only when sustained overload crosses a calibrated threshold\.

### 3\.1\.Background: openjiuwen Rails

The openjiuwen runtime defines aDeepAgentRailinterface: a Python object withon\_request,on\_tool\_call, andon\_memory\_readhooks that fire around every LLM call\. Rails are stateful, composable, and run inside the agent’s hot path\. ATM is implemented as three rails:

- •ToolRepairRail: bounded LLM\-driven repair on HARD tool failures, in an isolated context window of 512 tokens\.
- •MemoryGuardRail: per\-span privacy\-level \(PL0–PL4\) classification with per\-endpoint trust enforcement\.
- •ATMPipeline\(Section[4](https://arxiv.org/html/2607.20488#S4)\): the topology\-mutation pipeline proper, which coordinates the Bottleneck Index, factoriser, distiller, shadow validator, and coordinator hot\-swap\.

#### Two intervention regimes\.

ToolRepairRail and ATMPipeline share a rail interface but apply*different safety regimes*, justified by the scope of their intervention\.

*Online healing*\(ToolRepairRail\)\. When a single tool call returns a HARD failure, the rail issues a bounded LLM repair attempt and retries the call within the current task\. This is online because the intervention is localised to one tool call, the user is already waiting for the current response, and the worst\-case outcome of a bad repair is identical to having no repair at all: the task fails the same way it would have failed without the rail\. There is no shadow path, no validation window, and no commit/rollback machinery; the result of the repair is observable on the next line of the same task trace\.

*Shadow\-validated mutation*\(ATMPipeline\)\. When the Bottleneck Index breaches threshold, the rail proposes a*structural*change to the agent team\. This is not online: the candidate topology runs in shadow forWWtasks while the incumbent continues to serve user requests \(Section[4\.3](https://arxiv.org/html/2607.20488#S4.SS3)\)\. The stronger safety property is needed because a bad mutation would not just fail one task — it would degrade many subsequent tasks until rolled back\. TheWW\-task latency to commit is the price we pay for that stronger guarantee\.

The choice between the two regimes is a function of intervention scope: localised, observable\-now failures admit online healing; structural, observable\-later failures require shadow\-validated mutation\.

### 3\.2\.Tactical Loop: Telemetry and Bottleneck Index

Each agent maintains a sliding window of its own telemetry\. On every LLM call, we update six signals:

- •QiQ\_\{i\}: instantaneous queue depth at agentii\.
- •CiC\_\{i\}: context thrash — a measure of how often the context window must be reorganised between turns\.
- •EiE\_\{i\}: per\-tool error rate over the recent window\.
- •HiH\_\{i\}:*role entropy*— the Shannon entropy of the action categories invoked by the agent over its recent history\. An agent performing a single role \(e\.g\. pure search\) has lowHiH\_\{i\}; an agent mixing search, code execution, file I/O, and reasoning has highHiH\_\{i\}\.
- •RiR\_\{i\}: retry\-loop rate — fraction of calls that immediately re\-invoke the same tool after a non\-fatal error\.
- •WiW\_\{i\}: cross\-agent wait — mean time blocked on responses from other agents\.

These are combined into a scalar Bottleneck Index:

\(1\)Bi=α​Qi\+β​Ci\+γ​Ei\+δ​Hi\+ϵ​Ri\+ζ​WiB\_\{i\}=\\alpha Q\_\{i\}\+\\beta C\_\{i\}\+\\gamma E\_\{i\}\+\\delta H\_\{i\}\+\\epsilon R\_\{i\}\+\\zeta W\_\{i\}with default weights\(α,β,γ,δ,ϵ,ζ\)=\(0\.20,0\.15,0\.20,0\.20,0\.15,0\.10\)\(\\alpha,\\beta,\\gamma,\\delta,\\epsilon,\\zeta\)=\(0\.20,0\.15,0\.20,0\.20,0\.15,0\.10\)\. The role\-entropy weightδ\\deltais equal to the queue and error weightsα\\alphaandγ\\gamma— not because role entropy is the largest signal individually but because it is the only one that fires*before*errors accumulate\.

### 3\.3\.Threshold Calibration:τ\\tau\-Snapshot

The trigger fires whenBi\>τB\_\{i\}\>\\tauonK=3K=3consecutive ticks\. Settingτ\\taucorrectly is non\-trivial: too low gives spurious triggers, too high gives missed overload\. We use a*warmup snapshot*:τ\\tauis set to the 95th percentile ofBiB\_\{i\}observed over the first 20 ticks after agent startup, then frozen\.

This last point matters more than it sounds\. An earlier version of our implementation re\-computedτ\\tauas the rolling 95th percentile over all observed values\. Under sustained overload, this causedτ\\tauto trackBiB\_\{i\}upward, so the trigger never fired no matter how high the load went\. The bug was caught during the end\-to\-end trace \(Section[6\.4](https://arxiv.org/html/2607.20488#S6.SS4)\) and fixed by snapshottingτ\\tauat the end of warmup\.

### 3\.4\.Strategic Loop: Mutation Pipeline

When the trigger fires, ATM runs a five\-step pipeline:

1. \(1\)Factorise: one bounded LLM call proposes a split of the parent agent’s tools into two specialised children\. Capability monotonicity \(I1\) is checked as a hard gate\.
2. \(2\)Distill state: route each memory atom to a PL\-permitted child set, or explicitly drop it with a logged reason \(I2\)\.
3. \(3\)Shadow pass: instantiate the children and run the nextW=5W=5tasks through both the incumbent and candidate topologies\. The incumbent continues to serve user\-facing responses throughout; the candidate executes silently in a parallel path, its outputs scored with the LLM judge but not returned to the caller \(I3\)\.
4. \(4\)Commit or rollback: if the shadow pass shows non\-regression on success and improvement on at least one efficiency metric, commit the swap; otherwise rollback and apply exponential cooldown before re\-triggering\.
5. \(5\)Hot\-swap: the coordinator wrapper inherits the parent’sagent\_idand A2A address, so upstream callers see no discontinuity\.

The full algorithms are given in Section[4](https://arxiv.org/html/2607.20488#S4)and the formal properties in Section[5](https://arxiv.org/html/2607.20488#S5)\.

## 4\.Algorithms

This section gives the concrete algorithms used by the strategic loop\.

### 4\.1\.Factorisation

Given an overloaded parent agentppwith tool setTpT\_\{p\}and recent action\-category histogramhph\_\{p\}, the factoriser proposes a partitionTp=Tc1⊎Tc2T\_\{p\}=T\_\{c\_\{1\}\}\\uplus T\_\{c\_\{2\}\}such that each child specialises in a subset of action categories\.

The proposal is generated by a single LLM call with the parent’s identity, tool list, and the role\-entropy decomposition \(which categories were mixed in the recent window\)\. The LLM is asked to return a JSON object with two children and a justification\.

Algorithm 1Factorise1:Input:parent agent

pp, action histogram

hph\_\{p\}
2:Call LLM with

pp\.tool\_list and

hph\_\{p\}, request JSON partition

3:Parse

\{c1,c2\}\\\{c\_\{1\},c\_\{2\}\\\}with tool sets

Tc1,Tc2T\_\{c\_\{1\}\},T\_\{c\_\{2\}\}
4:Assert

Tc1∪Tc2⊆TpT\_\{c\_\{1\}\}\\cup T\_\{c\_\{2\}\}\\subseteq T\_\{p\}// I1

5:Assert

Tc1∩Tc2=∅T\_\{c\_\{1\}\}\\cap T\_\{c\_\{2\}\}=\\emptyset
6:Return

\{c1,c2\}\\\{c\_\{1\},c\_\{2\}\\\}

The assertions are hard: if either fails the proposal is rejected and the cooldown timer is started\. We never relax I1 even by one tool: a child agent must not gain capabilities its parent did not have\.

### 4\.2\.State Distillation

After factorisation, the parent’s memory is partitioned\. Each memory atomaais annotated with a privacy levelPL​\(a\)∈\{0,1,2,3,4\}\\text\{PL\}\(a\)\\in\\\{0,1,2,3,4\\\}and a content classification\.

Algorithm 2DistillState1:Input:parent memory

MpM\_\{p\}, children

\{c1,c2\}\\\{c\_\{1\},c\_\{2\}\\\}
2:Initialise

Mc1,Mc2←∅M\_\{c\_\{1\}\},M\_\{c\_\{2\}\}\\leftarrow\\emptyset
3:for all

a∈Mpa\\in M\_\{p\}do

4:Compute classifier output: which child needs

aa?

5:ifboth children need

aaand

PL​\(a\)≤2\\text\{PL\}\(a\)\\leq 2then

6:

Mc1\.a​d​d​\(a\);Mc2\.a​d​d​\(a\)M\_\{c\_\{1\}\}\.add\(a\);M\_\{c\_\{2\}\}\.add\(a\)
7:elseifexactly one child

ckc\_\{k\}needs

aathen

8:

Mck\.a​d​d​\(a\)M\_\{c\_\{k\}\}\.add\(a\)
9:else

10:drop

aa// not needed by any child

11:endif

12:endfor

13:Assertevery

a∈Mpa\\in M\_\{p\}appears in

Mc1M\_\{c\_\{1\}\}or

Mc2M\_\{c\_\{2\}\}or is explicitly dropped// I2

14:Return

Mc1,Mc2M\_\{c\_\{1\}\},M\_\{c\_\{2\}\}

For high\-PL atoms \(PL​\(a\)≥3\\text\{PL\}\(a\)\\geq 3\) we add a stricter rule: the atom may be routed to*at most one*child even if both need it, breaking the per\-child duplication that otherwise multiplies the exposure surface\.

### 4\.3\.Shadow Pass and Validation Window

The shadow pass runs the proposed topology in parallel with the incumbent forW=5W=5tasks\.*Crucially, only the incumbent’s response is returned to upstream callers during this window\.*The candidate topology receives the same input, produces its own response, and is scored — but its output is logged for evaluation only and never reaches the user\. We score each topology on \(a\) success rate \(LLM\-as\-judge\), \(b\) median time\-to\-completion, and \(c\) PL≥\\geq3 exposure events\.

Algorithm 3ShadowPass1:Input:incumbent topology

𝒯0\\mathcal\{T\}\_\{0\}, candidate

𝒯1\\mathcal\{T\}\_\{1\}
2:Initialise scoreboard

S0,S1←S\_\{0\},S\_\{1\}\\leftarrowempty

3:for

t=1t=1to

WWdo

4:Get next task

τ\\tau
5:Run

τ\\tauthrough

𝒯0\\mathcal\{T\}\_\{0\};returnresponse to caller; record outcome in

S0S\_\{0\}
6:Run

τ\\tauthrough

𝒯1\\mathcal\{T\}\_\{1\}in shadow \(no response returned\); record outcome in

S1S\_\{1\}
7:endfor

8:if

S1\.success≥S0\.successS\_\{1\}\.\\text\{success\}\\geq S\_\{0\}\.\\text\{success\}and\(

S1\.time<S0\.timeS\_\{1\}\.\\text\{time\}<S\_\{0\}\.\\text\{time\}or

S1\.exposure<S0\.exposureS\_\{1\}\.\\text\{exposure\}<S\_\{0\}\.\\text\{exposure\}\)then

9:Commit

𝒯1\\mathcal\{T\}\_\{1\}\(subsequent tasks routed to

𝒯1\\mathcal\{T\}\_\{1\}\)// I3 satisfied

10:else

11:Rollback\(

𝒯1\\mathcal\{T\}\_\{1\}discarded; never received live traffic\), start exponential cooldown

12:endif

The user\-visible service path is therefore unchanged throughout the window: every incoming request continues to be served by the agent they have been talking to\. The cost of shadow execution is a doubled LLM call rate forWWtasks \(incumbent \+ candidate\), borne by ATM and invisible to callers\.

The cooldown starts at 5 minutes and doubles after each consecutive rollback, capped at 60 minutes\. This prevents the trigger from oscillating against a workload that genuinely cannot be improved by factorisation\.

### 4\.4\.Coordinator Hot\-Swap

The coordinator wrapper preserves the parent’s external identity:

Algorithm 4CoordinatorSwap1:Input:parent

pp, committed children

\{c1,c2\}\\\{c\_\{1\},c\_\{2\}\\\}
2:Create coordinator

κ\\kappawithagent\_id

←p\\leftarrow p\.agent\_id

3:Bind

κ\\kappato

pp’s A2A address; reroute inbox to

κ\\kappa
4:Register children

\{c1,c2\}\\\{c\_\{1\},c\_\{2\}\\\}as

κ\\kappa’s sub\-agents

5:Atomically swap

p→κp\\to\\kappain the agent registry

6:Terminate

pp

Upstream callers see a continuous service: the sameagent\_id, same A2A address, same inbox\. The internal restructuring is invisible to them\.

## 5\.Formal Properties

ATM’s safety story rests on three invariants enforced mechanically by the algorithms of Section[4](https://arxiv.org/html/2607.20488#S4)\. We state them precisely here\.

#### I1: Capability Monotonicity\.

For any mutation of parentppinto children\{c1,…,cn\}\\\{c\_\{1\},\\dots,c\_\{n\}\\\}, the tool set of each child satisfiesTck⊆TpT\_\{c\_\{k\}\}\\subseteq T\_\{p\}, and the trust level satisfiestrust​\(ck\)≤trust​\(p\)\\text\{trust\}\(c\_\{k\}\)\\leq\\text\{trust\}\(p\)\.

*Why this matters\.*Without I1, a runtime mutation could grant a child agent privileges its parent never had\. The factoriser’s prompt explicitly listsTpT\_\{p\}and is constrained to choose subsets; Algorithm[1](https://arxiv.org/html/2607.20488#alg1)line 4 enforces this as a hard assertion\.

#### I2: State\-Routing Completeness\.

For any partition of parent memoryMpM\_\{p\}into children’s memories\{Mc1,…,Mcn\}\\\{M\_\{c\_\{1\}\},\\dots,M\_\{c\_\{n\}\}\\\}, every atoma∈Mpa\\in M\_\{p\}either \(a\) appears in at least oneMckM\_\{c\_\{k\}\}, or \(b\) is explicitly logged as dropped with a reason\. No atom is silently lost; no atom appears in more children than its PL allows\.

*Why this matters\.*Without I2, a distillation could drop a critical context atom \(causing the child to lose information the parent had\) or, worse, copy a high\-PL atom into multiple children \(multiplying the exposure surface\)\. Algorithm[2](https://arxiv.org/html/2607.20488#alg2)line 13 enforces the completeness check; the per\-atom PL rule \(Section[4\.2](https://arxiv.org/html/2607.20488#S4.SS2)\) enforces the duplication bound\.

#### I3: Shadow\-Before\-Live\.

No proposed topology𝒯1\\mathcal\{T\}\_\{1\}replaces an incumbent𝒯0\\mathcal\{T\}\_\{0\}until it has run in*shadow*alongside𝒯0\\mathcal\{T\}\_\{0\}for at leastWWtasks and demonstrates non\-regression on the success metric\. “Shadow” here is the strong property: during the validation window, incoming user requests continue to be served by𝒯0\\mathcal\{T\}\_\{0\}and its responses alone are returned upstream;𝒯1\\mathcal\{T\}\_\{1\}receives the same inputs in a parallel execution path but its outputs are scored, not delivered\. The user sees no candidate output until the commit\. We commit only whenS1\.success≥S0\.successS\_\{1\}\.\\text\{success\}\\geq S\_\{0\}\.\\text\{success\}and at least one ofS1\.time<S0\.timeS\_\{1\}\.\\text\{time\}<S\_\{0\}\.\\text\{time\}orS1\.exposure<S0\.exposureS\_\{1\}\.\\text\{exposure\}<S\_\{0\}\.\\text\{exposure\}holds\.

*Why this matters\.*Without I3 in this strong form, a mis\-firing trigger could route live user traffic through an unproven configuration mid\-task\. The shadow form bounds the downside of any mutation proposal to the LLM cost of runningWWextra invocations in the background — zero user\-visible cost if the candidate is worse, zero user\-visible disruption if it is better\. Algorithm[3](https://arxiv.org/html/2607.20488#alg3)implements this isolation directly: line 5 returns the response to the caller, line 6 does not\.

### 5\.1\.Complexity

The overhead of ATM has two parts:

#### Tactical \(per\-tick\)\.

Updating the Bottleneck Index requiresO​\(1\)O\(1\)arithmetic plusO​\(log⁡n\)O\(\\log n\)to update the per\-tool error sliding window \(binary search on a sorted deque\)\. The threshold check isO​\(1\)O\(1\)\. In practice this translates to under 500 µs of p99 latency on the agent’s hot path \(Table[3](https://arxiv.org/html/2607.20488#S6.T3)\)\.

#### Strategic \(per\-mutation\)\.

The factoriser calls the LLM once \(bounded at 512 tokens\) plus runs the distillation classifier over\|Mp\|\|M\_\{p\}\|atoms inO​\(\|Mp\|\)O\(\|M\_\{p\}\|\)time\. The shadow pass addsWWextra task executions \(defaultW=5W=5\)\. This is the cost of one mutation; on a workload that triggers once every∼\\sim30 tasks \(Section[6\.6](https://arxiv.org/html/2607.20488#S6.SS6)\), the amortised cost is≈5/30=17%\\approx 5/30=17\\%extra task budget at mutation events only\.

### 5\.2\.Failure Modes and Bounded Damage

Even with the invariants, things can go wrong\. The damage bounds:

- •Factoriser proposes invalid split\(e\.g\. children with overlapping tools\)\. I1 catches this in Algorithm[1](https://arxiv.org/html/2607.20488#alg1); the mutation is rejected and cooldown starts\. No live state is disturbed\.
- •Distiller misroutes an atom\.I2 ensures the atom is either present somewhere or explicitly dropped\. If it is present in the wrong child, the shadow pass should detect the regression\.
- •Shadow pass scores incumbent better\.I3 forces a rollback\. The candidate topology was instantiated in memory but never took live traffic; we discard it and apply cooldown\.
- •Threshold drift under sustained overload\.Caught by theτ\\tau\-snapshot rule \(Section[3\.3](https://arxiv.org/html/2607.20488#S3.SS3)\)\. Without the snapshot,τ\\tautracksBiB\_\{i\}and the trigger never fires; this is the bug we discovered in Section[6\.4](https://arxiv.org/html/2607.20488#S6.SS4)\.

## 6\.Evaluation

We address four empirical questions:

- •Q1\.Does ATM improve task success on overloaded workloads?
- •Q2\.Does state distillation reduce memory exposure without degrading task quality?
- •Q3\.What is the runtime overhead of the Rails on the agent’s hot path?
- •Q4\.Does each signal in the Bottleneck Index contribute independent information, and does the live trigger fire correctly end\-to\-end?

### 6\.1\.Setup

LLM\.All A0–A3 experiments use DeepSeek\-V3 \(deepseek\-chat, temperature 0\.7\) accessed via the OpenAI\-format API\. Two seeded runs ofN=30N=30tasks per cell are pooled toN=60N=60;4×3×60=7204\\times 3\\times 60=720total real\-LLM runs\.

Workloads\.Three workloads stress different overload modes:

- •W1 Research\.Multi\-source web search and synthesis, seeded context contains public domain references with sparse PL≥\\geq2 atoms\.
- •W2 Code/debug\.Read a buggy snippet, identify the bug, write a fix\. Mixed action categories \(read, reason, write\) maximise role entropy\.
- •W3 Security\.Triage a session with PL≥\\geq3 atoms \(api\_key,bank\_account,ssh,passport\) and produce a redacted summary\.

No external benchmark dataset\.These workloads are synthesised in\-house rather than drawn from a standard benchmark \(MMLU\(Hendryckset al\.,[2021](https://arxiv.org/html/2607.20488#bib.bib21)\), GAIA\(Mialonet al\.,[2024](https://arxiv.org/html/2607.20488#bib.bib22)\), SWE\-bench\(Jimenezet al\.,[2024](https://arxiv.org/html/2607.20488#bib.bib23)\), or similar\)\. The rationale is that standard agent benchmarks do not by construction exercise the overload modes ATM is designed to detect — role\-entropy spikes from mixed action categories, sustained high\-queue states, and structured PL≥\\geq3 leakage paths\. We need tasks where the monolithic baseline visibly fails so that theΔ\\Deltafrom the ATM split is measurable; an off\-the\-shelf benchmark on which DeepSeek\-V3 already achieves\>90%\>90\\%would show no headroom\. Validating ATM on standard benchmarks is itself future work, as discussed in the Limitations section\.

Conditions\.Four ablation conditions:

### 6\.2\.Main Results: Success and Exposure \(Q1, Q2\)

Table[1](https://arxiv.org/html/2607.20488#S6.T1)reports pooled results acrossN=60N=60trials per cell\. The headline contrasts are reported in Table[2](https://arxiv.org/html/2607.20488#S6.T2)\.

Table 1\.Pooled results across two independent seeded N=30 runs \(N=60N=60per cell\)\. Succ = success rate \(↑\\uparrowbetter\), Exp = PL≥\\geq3 exposure events per task \(↓\\downarrowbetter\)\. Star \(⋆\\star\) indicates the contrast is significant atp<10−7p<10^\{\-7\}\.Table 2\.Pairwise contrasts \(χ2\\chi^\{2\}with Yates correction, two\-tailed\)\.Q1\.On W2 \(code/debug, high role entropy\), the monolithic agent \(A0\) succeeds 2 in 60 pooled trials \(0\.033\)\. The factoriser split \(A2\) lifts this to 0\.617 — a\+58 percentage pointgain \(χ2=43\.91\\chi^\{2\}=43\.91,p=3\.4×10−11p=3\.4\{\\times\}10^\{\-11\}\)\. The random split \(A1\) achieves 0\.533, showing that*some*split helps but A1 vs\. A2 differ by 8pp on the same workload, suggesting the factoriser’s intelligent partition contributes part but not all of the gain over A1\. On W1 \(research\), the monolith already succeeds 0\.900; ATM lifts this only slightly \(0\.983,p=0\.12p=0\.12not significant\), consistent with the workload not exercising role entropy\. On W3, all conditions succeed \(0\.950–1\.000\)\.

Why A0 fails on W2\.Manual inspection of failed A0 W2 traces shows three dominant failure modes: \(1\) diagnosis/write\-role interference, where the monolith attempts to diagnose a failure and write a patch simultaneously, producing confused tool sequences; \(2\) repeated re\-invocation of the same failing tool without varying the approach; and \(3\) context contamination from raw error traces crowding out patch\-writing context\. Random splitting \(A1\) removes part of this interference, explaining its large gain; ATM’s factoriser improves further by assigning diagnostic and execution tools to semantically aligned children\. The primary effect is runtime decomposition; ATM’s contribution is making decomposition telemetry\-triggered, capability\-monotone, state\-aware, and shadow\-validated\.

Q2\.On W3, A0 leaks 2\.0 PL≥\\geq3 atoms per task; A3 drops this to 0\.000 \(3/60 events→\\to0/60\)\. A3 preserves task success at 0\.950 with zero exposure — the distillation does not significantly cost quality \(p=1\.00p=1\.00vs\. A0\)\. On W2, A3 succeeds at 0\.483 vs\. A2’s 0\.617 \(0\.617 vs\. 0\.483,χ2=1\.65\\chi^\{2\}=1\.65,p=0\.20p=0\.20\) — distillation costs∼\\sim13pp on success but the difference is not statistically significant in our sample\.

A3’s distillation routes each high\-PL atom to at most one child, breaking the double\-count and recovering the A0 baseline \(0\.500\)\. On W3, exposure is identically 0\.000 for A1, A2, and A3 because the MemoryGuardRail’s regex patterns catch the credential strings \(api\_key,bank\_account,ssh,passport\) in the seeded memory before any LLM call, regardless of whether distillation is also applied\. Distillation’s additional contribution over the rail alone is twofold: \(i\) it reduces the per\-child attack surface \(each child sees fewer spans, including spans the rail might miss\), and \(ii\) it prevents the per\-child duplication of high\-PL content visible in the W1 row\.

### 6\.3\.Latency Overhead \(Q3\)

We benchmarked each Rail in isolation against a no\-op baseline, on a single\-threaded loop of10,00010\{,\}000iterations per condition with a MockLLMClient to isolate Rail overhead\.

Table 3\.Per\-call Rail overhead \(µs\),10410^\{4\}iterations\.The expensive path isMemoryGuardRailat∼\\sim240 µs mean, dominated by the regex classifier over the prompt span\. The p99 reaches 402 µs under one PL4 redaction\. TheToolRepairRailadds∼\\sim110 µs mean when the tool call succeeds \(the common case\) and∼\\sim256 µs when it must invoke a repair\. All numbers are well under 500 µs p99 and under 350 µs p95, satisfying the latency budget claimed in Section[5](https://arxiv.org/html/2607.20488#S5)\.

### 6\.4\.End\-to\-End Live Trigger Trace

To verify the full ATM pipeline fires correctly under realistic conditions, we ran a logged production trace\. After 20 warmup tasks the agent is loaded with a mixed\-role W2/W1 sequence designed to elevateHiH\_\{i\}\. The trace JSON records every Bottleneck Index value,τ\\taucomparison, factoriser proposal, distillation routing decision, shadow\-window task outcome, and final commit\.

Bug found during this experiment\.The first version of our implementation re\-computedτ\\tauas the rolling 95th percentile over all observed values\. Under sustained overload, this causedτ\\tauto trackBiB\_\{i\}upward, so the trigger never fired no matter how high the load went\. We fixed this by snapshottingτ\\tauat the end of warmup \(see Section[3\.3](https://arxiv.org/html/2607.20488#S3.SS3)\); after the fix, the trigger fired at tick 41 \(warmup ended at tick 20, sustained overload from tick 38,K=3K=3consecutive breach\), the factoriser proposed an Analyst/Executor split, distillation routed memory atoms correctly, the shadow pass showed non\-regression, and the coordinator swap committed at tick 47\.

### 6\.5\.Controlled\-Telemetry Signal Ablation \(Q4\)

To validate the contribution of each signal inBiB\_\{i\}— and in particular the role\-entropy termHiH\_\{i\}— we constructedN=100N=100labelled overload traces, each6060ticks long\. Five overload profiles inject overload that affects different signals \(e\.g\.*H\-only*elevates only role entropy;*E\-only*elevates only the tool\-error rate\)\. We replay each trace through nine BI variants: the fullBiB\_\{i\}, six single\-signal\-removed variants, and two naive baselines \(QiQ\_\{i\}\-only andEiE\_\{i\}\-only\)\. Recall is the fraction of traces where the trigger fires within88ticks of overload onset\.

Table 4\.Controlled\-telemetry ablation of Bottleneck Index signals onN=100N=100labelled overload traces, broken down by overload profile\. Each column is a stylised overload pattern that elevates a single signal\. Cells are trigger recall \(↑\\uparrowbetter\)\.Bold= the diagonal: when an overload elevates only signalXX, removingXXfrom the BI catastrophically degrades detection\.The per\-profile breakdown reveals an exact diagonal pattern: when an overload elevates only signalXX, the variant that removesXXhaszerorecall\. RemovingHiH\_\{i\}drops recall on theHH\-only profile from 1\.00 to 0\.00\. Aggregated across all profiles, removingHiH\_\{i\}costs−19\-19pp \(0\.97→0\.780\.97\\to 0\.78\) — the largest aggregate drop among the six signals\. TheQiQ\_\{i\}\-only andEiE\_\{i\}\-only naive baselines miss most overload modes, showing that no single signal is sufficient\.

While the overload profiles themselves are constructed rather than recorded from production, the labelled\-onset design lets us measure each signal’s independent contribution directly\.

### 6\.6\.Live\-Trigger Condition A4 \(Q4\)

In A0–A3 the harness fixed the topology at task start\. A more realistic deployment lets the Bottleneck Index decide*when*to mutate\. We ran an additional condition,A4, in which the agent starts monolithic and the trigger fires only whenBi\>τB\_\{i\}\>\\tauonK=3K=3consecutive tasks\. After a trigger, the system proceeds as A3 \(factoriser split with distillation\)\.

Table 5\.A4 live\-trigger condition\. TTT = mean tasks until trigger fires \(only over runs where it did fire\)\. Pre/post = success and exposure per task, computed on the tasks before and after the trigger\.TR=trigger rate; SP/SP\+=success pre/post; EP/EP\+=exposure pre/post\.

Three findings: \(i\) the trigger is selective — it fires in 25–55% of runs depending on workload, suggesting it does not over\-fire; \(ii\) when it does fire, mean time\-to\-trigger is 22–34 tasks, leaving room for warmup plus theKK\-consecutive constraint to filter false positives; \(iii\) post\-mutation success improves on all three workloads, with the largest gain on W2 \(\+22\.9\+22\.9pp\) — consistent with our static A0→\\toA3 comparison\. Exposure drops from 1\.000 to∼\\sim0\.15 post\-mutation, matching the distillation effect from the static benchmark\.

Note\.A4 uses the simulator agent loop \(mathematical model with role\-entropy\-driven step\-success probability\), not the DeepSeek\-driven agent used for A0–A3\. We interpret these numbers as evidence that the*trigger logic*behaves correctly under controlled telemetry, not as a replacement for the real\-LLM A0–A3 benchmark\. A real\-LLM A4 is future work\.

### 6\.7\.Live\-Tool Benchmark W4

To address external validity beyond stubbed tools, we built a small live\-tool benchmark with real Python execution\. Five fixtures contain single\-bug Python files with accompanyingpytesttests\. The agent reads the buggy file from disk, invokespytestas a subprocess to observe the failure, proposes a fix via a DeepSeek\-V3 call, writes the fix back, and re\-runspytest\. Success requires all tests to pass post\-fix\. We compare A0 \(monolithic\) and A3 \(factoriser split: an*Analyst*child diagnoses the bug seeing the test output, an*Executor*child writes the fix seeing only the diagnosis — the raw error trace is quarantined\)\.

On this small fixture set, both A0 and A3 fix all 15 trials \(15/15 each\)\. DeepSeek\-V3 is strong enough to handle these single\-line bugs in either configuration, so the conditions are indistinguishable on success rate\. Mean wall\-time per trial: A0 1\.4 s, A3 2\.7 s \(the analyst step adds∼\\sim1\.3 s per task\)\. We interpret this as a successful demonstration that the system runs end\-to\-end with live tools, but the fixture difficulty is too low to differentiate the conditions\. Larger fixture suites with real GitHub repository bugs — where the monolith starts failing — are the appropriate setting and are future work\.

## 7\.Conclusion

We presentedAutonomous Topology Mutation \(ATM\), a runtime team mutation mechanism for multi\-agent LLM frameworks\. ATM monitors a six\-signal Bottleneck Index with a role\-entropy term, proposes structural changes via one bounded LLM call gated by three formal invariants \(capability monotonicity, state\-routing completeness, shadow\-before\-live\), and hot\-swaps the agent team while preserving external identity\. Unlike recent dynamic\-topology work that optimises a fresh graph per query\(Wanget al\.,[2026](https://arxiv.org/html/2607.20488#bib.bib15)\), ATM operates on a deployed live agent and validates safety invariants before any irreversible change\.

On 720 DeepSeek\-V3\-driven task runs with deterministic tool stubs, the factoriser split lifts code\-task success from 3\.3% to 61\.7% \(\+58\+58pp,p<10−10p<10^\{\-10\}\); the full rail\+distillation system eliminates detected PL≥\\geq3 memory exposure under our regex classifier \(2\.0→0\.02\.0\\to 0\.0events per task\) without significant quality cost on the workloads tested, and the Rails carrying ATM’s invariants add less than 350 µs of p95 overhead to the agent’s hot path\. The controlled\-telemetry signal ablation \(Section[6\.5](https://arxiv.org/html/2607.20488#S6.SS5)\) confirms that each of the six signals contributes independent information, withHiH\_\{i\}\(role entropy\) carrying the largest aggregate weight\. The live\-trigger A4 condition \(Section[6\.6](https://arxiv.org/html/2607.20488#S6.SS6)\) shows the Bottleneck Index fires selectively \(25–55% of runs\) and that post\-mutation success improves on every workload tested\. A small live\-tool probe \(Section[6\.7](https://arxiv.org/html/2607.20488#S6.SS7)\) demonstrates that the system runs end\-to\-end with real Python execution; differentiating A0 from A3 on harder bug suites remains an open external\-validity target\.

ATM complements existing self\-healing \(Reflexion\(Shinnet al\.,[2023](https://arxiv.org/html/2607.20488#bib.bib1)\), CRITIC\(Gouet al\.,[2024](https://arxiv.org/html/2607.20488#bib.bib3)\)\) and self\-improving \(OpenClaw\(Steinberger and others,[2026](https://arxiv.org/html/2607.20488#bib.bib6)\), Hermes\(Nous Research,[2026](https://arxiv.org/html/2607.20488#bib.bib7)\), Auto\-Harness\(openJiuwen contributors,[2026](https://arxiv.org/html/2607.20488#bib.bib9)\)\) systems: where those change behaviour, ATM changes structure\. We believe runtime topology mutation is a necessary capability for any multi\-agent system that must operate across diverse workloads without per\-workload retuning, and we hope the formal invariants we propose can serve as a starting point for further work on safe structural self\-modification\.

## Impact Statement

This work contributes to the safety of large\-scale multi\-agent LLM deployments\. ATM’s invariants are specifically designed to prevent two classes of harm:*capability escalation*\(a sub\-agent acquiring tools its parent did not have, addressed by I1\), and*cross\-context information leakage*\(high\-sensitivity memory spans being routed to children that should not see them, addressed by distillation and the PL classifier\)\. At the same time, runtime structural mutation introduces operational risks: a mis\-firing trigger could disrupt service, and the shadow\-validation step relies on a short window that may not catch all regressions\. We have designed A4\-style live triggering to be conservative \(25–55% firing rate in our experiments\) and to support automatic rollback\. Beyond these considerations, the broader societal impacts of ATM align with standard dual\-use concerns for large language models, and we encourage practitioners to evaluate these risks when integrating runtime topology mutation into production environments\.

## Limitations

ATM exhibits several practical and methodological limitations\.First, our tool implementations \(search, scrape, run\_code, etc\.\) are deterministic stubs that emit hashed\-input outputs and inject parametrised failure modes\. The agent’s reasoning, all Rail invocations, and the LLM judge remain live, but the tool outcomes are not real web pages or real code execution\. The live\-tool W4 probe is limited to 5 fixtures\.Second, the PL classifier uses regex patterns and misses some session\-history phrasings; a semantic classifier is a natural extension\.Third,N=60N=60per cell is adequate for our headline significance \(p<10−10p<10^\{\-10\}\) but a stronger venue should targetN≥100N\\geq 100, particularly to resolve the A2 vs\. A3 distillation cost \(Δ=−0\.133\\Delta=\-0\.133,p=0\.20p=0\.20in our data\)\.Fourth, the A4 live\-trigger condition uses the simulator agent loop rather than the real DeepSeek\-driven agent we used for A0–A3; a real\-LLM A4 run is an immediate follow\-up\.Fifth, ATM currently performs single\-level factorisation; a child agent that itself becomes overloaded is not yet handled and would require recursive invariant reasoning\.Sixth, all main\-benchmark workloads \(W1–W3\) and the W4 fixtures are synthesised in\-house rather than drawn from an established agent benchmark \(MMLU\(Hendryckset al\.,[2021](https://arxiv.org/html/2607.20488#bib.bib21)\), GAIA\(Mialonet al\.,[2024](https://arxiv.org/html/2607.20488#bib.bib22)\), SWE\-bench\(Jimenezet al\.,[2024](https://arxiv.org/html/2607.20488#bib.bib23)\)\)\. This was a deliberate choice — ATM needs tasks where a monolithic baseline visibly fails so that theΔ\\Deltafrom the split is measurable — but it leaves external validity vs\. standard benchmarks as a separate evaluation that remains open\. A productive direction would be to identify a subset of GAIA or SWE\-bench tasks on which a monolithic agent already struggles for role\-entropy reasons, then re\-run the ATM ablation on that subset\.

## References

- Y\. Bai, S\. Kadavath, S\. Kundu, A\. Askell,et al\.\(2022\)Constitutional AI: harmlessness from AI feedback\.arXiv preprint\.External Links:2212\.08073Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px1.p1.1)\.
- N\. Bholani \(2026\)Graph\-based self\-healing tool routing for cost\-efficient llm agents\.arXiv preprint\.External Links:2603\.01548Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px1.p1.1)\.
- D\. Garlan, S\. Cheng, A\. Huang, B\. Schmerl, and P\. Steenkiste \(2004\)Rainbow: architecture\-based self\-adaptation with reusable infrastructure\.IEEE Computer37\(10\),pp\. 46–54\.Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px6.p1.1)\.
- Z\. Gou, Z\. Shao, Y\. Gong, Y\. Shen, Y\. Yang, N\. Duan, and W\. Chen \(2024\)CRITIC: large language models can self\-correct with tool\-interactive critiquing\.InInternational Conference on Learning Representations,External Links:2305\.11738Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px1.p1.1),[§7](https://arxiv.org/html/2607.20488#S7.p3.1)\.
- D\. Hendrycks, C\. Burns, S\. Basart, A\. Zou, M\. Mazeika, D\. Song, and J\. Steinhardt \(2021\)Measuring massive multitask language understanding\.InInternational Conference on Learning Representations,External Links:2009\.03300Cited by:[§6\.1](https://arxiv.org/html/2607.20488#S6.SS1.p3.3),[Limitations](https://arxiv.org/html/2607.20488#Sx2.p1.6)\.
- S\. Hong, X\. Zheng, J\. Chen,et al\.\(2023\)MetaGPT: meta programming for a multi\-agent collaborative framework\.arXiv preprint\.External Links:2308\.00352Cited by:[§1](https://arxiv.org/html/2607.20488#S1.p1.1),[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px3.p1.1)\.
- C\. E\. Jimenez, J\. Yang, A\. Wettig, S\. Yao, K\. Pei, O\. Press, and K\. Narasimhan \(2024\)SWE\-bench: can language models resolve real\-world GitHub issues?\.InInternational Conference on Learning Representations,External Links:2310\.06770Cited by:[§6\.1](https://arxiv.org/html/2607.20488#S6.SS1.p3.3),[Limitations](https://arxiv.org/html/2607.20488#Sx2.p1.6)\.
- O\. Khattab, A\. Singhvi, P\. Maheshwari,et al\.\(2023\)DSPy: compiling declarative language model calls into self\-improving pipelines\.arXiv preprint\.External Links:2310\.03714Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px2.p1.1)\.
- Y\. Lu, Y\. Hu, X\. Zhao, and J\. Cao \(2026\)DyTopo: dynamic topology routing for multi\-agent reasoning via semantic matching\.arXiv preprint\.External Links:2602\.06039Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px4.p1.1)\.
- A\. Madaan, N\. Tandon, P\. Gupta,et al\.\(2023\)Self\-refine: iterative refinement with self\-feedback\.InAdvances in Neural Information Processing Systems,External Links:2303\.17651Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px1.p1.1)\.
- G\. Mialon, C\. Fourrier, C\. Swift, T\. Wolf, Y\. LeCun, and T\. Scialom \(2024\)GAIA: a benchmark for general AI assistants\.InInternational Conference on Learning Representations,External Links:2311\.12983Cited by:[§6\.1](https://arxiv.org/html/2607.20488#S6.SS1.p3.3),[Limitations](https://arxiv.org/html/2607.20488#Sx2.p1.6)\.
- J\. Moura \(2024\)CrewAI: framework for orchestrating role\-playing, autonomous AI agents\.Note:[https://github\.com/crewAIInc/crewAI](https://github.com/crewAIInc/crewAI)Cited by:[§1](https://arxiv.org/html/2607.20488#S1.p1.1),[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px3.p1.1)\.
- Nous Research \(2026\)Hermes agent: open\-source self\-improving AI agent framework\.Note:[https://hermes\-agent\.org/](https://hermes-agent.org/)Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px2.p1.1),[§7](https://arxiv.org/html/2607.20488#S7.p3.1)\.
- openJiuwen contributors \(2025\)JiuwenSwarm: multi\-agent framework with skill self\-evolution\.Note:[https://github\.com/openJiuwen\-ai/jiuwenswarm](https://github.com/openJiuwen-ai/jiuwenswarm)Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px2.p1.1)\.
- openJiuwen contributors \(2026\)Auto\-harness: evaluation\-driven closed\-loop optimization of agent harnesses\.Note:[https://github\.com/openJiuwen\-ai/agent\-core](https://github.com/openJiuwen-ai/agent-core)Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px2.p1.1),[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px3.p1.1),[§7](https://arxiv.org/html/2607.20488#S7.p3.1)\.
- S\. Pan, Y\. Liu, J\. Gao, T\. Gao, W\. Liu, J\. Lin, Z\. Fu, J\. Wang, W\. Zhang, and Y\. Yu \(2026\)SkillMAS: skill co\-evolution with LLM\-based multi\-agent system\.arXiv preprint\.External Links:2605\.09341Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px4.p1.1)\.
- T\. Rebedea, R\. Dinu, M\. Sreedhar, C\. Parisien, and J\. Cohen \(2023\)NeMo Guardrails: a toolkit for controllable and safe LLM applications with programmable rails\.arXiv preprint\.External Links:2310\.10501Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px5.p1.1)\.
- N\. Shinn, F\. Cassano, E\. Berman, A\. Gopinath, K\. Narasimhan, and S\. Yao \(2023\)Reflexion: language agents with verbal reinforcement learning\.InAdvances in Neural Information Processing Systems,External Links:2303\.11366Cited by:[§1](https://arxiv.org/html/2607.20488#S1.p2.1),[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px1.p1.1),[§7](https://arxiv.org/html/2607.20488#S7.p3.1)\.
- B\. Sidik and L\. Rokach \(2026\)MemTier: tiered memory architecture and the retrieval bottleneck in long\-running LLM agents\.arXiv preprint\.External Links:2605\.03675Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px2.p1.1)\.
- P\. Steinbergeret al\.\(2026\)OpenClaw: self\-hosted personal AI agent runtime\.Note:[https://github\.com/openclaw/openclaw](https://github.com/openclaw/openclaw)Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px2.p1.1),[§7](https://arxiv.org/html/2607.20488#S7.p3.1)\.
- Y\. Wang, J\. Zhao,et al\.\(2026\)MetaGen: self\-evolving roles and topologies for multi\-agent LLM reasoning\.arXiv preprint\.External Links:2601\.19290Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px4.p1.1),[§7](https://arxiv.org/html/2607.20488#S7.p1.1)\.
- Q\. Wu, G\. Bansal, J\. Zhang,et al\.\(2023\)AutoGen: enabling next\-gen LLM applications via multi\-agent conversation framework\.arXiv preprint\.External Links:2308\.08155Cited by:[§1](https://arxiv.org/html/2607.20488#S1.p1.1),[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px3.p1.1)\.
- C\. Xu, Y\. Hu, R\. Wang, X\. Lin, W\. Wang, D\. Liu, and F\. Feng \(2026\)TacoMAS: test\-time co\-evolution of topology and capability in LLM\-based multi\-agent systems\.arXiv preprint\.External Links:2605\.09539Cited by:[§2](https://arxiv.org/html/2607.20488#S2.SS0.SSS0.Px4.p1.1)\.

## Appendix AReproducibility Details

#### Code and data\.

#### LLM and seeds\.

All A0–A3 experiments use DeepSeek\-V3 \(deepseek\-chat, temperature 0\.7\) accessed via the OpenAI\-format API\. Two seeded runs ofN=30N=30tasks per cell are pooled toN=60N=60\(seeds 42 and 123\)\. Total runs:4​conditions×3​workloads×60=7204\\text\{ conditions\}\\times 3\\text\{ workloads\}\\times 60=720\.

#### Stubbed tools\.

For reproducibility,web\_search,web\_scrape, andrun\_codeare implemented as deterministic stubs: each input is hashed and mapped to a fixed output plus a parametric failure\-rate\. The W4 live\-tool benchmark \(Section[6\.7](https://arxiv.org/html/2607.20488#S6.SS7)\) uses real Python subprocess execution\.

#### Statistical tests\.

Pairwise contrasts use Pearson’s chi\-square with Yates’ continuity correction\.pp\-values reported as two\-tailed\.

#### Bottleneck Index parameters\.

Default weights\(α,β,γ,δ,ϵ,ζ\)=\(0\.20,0\.15,0\.20,0\.20,0\.15,0\.10\)\(\\alpha,\\beta,\\gamma,\\delta,\\epsilon,\\zeta\)=\(0\.20,0\.15,0\.20,0\.20,0\.15,0\.10\); warmup = 20 ticks;K=3K=3consecutive ticks;τ\\tausnapshot at the 95th percentile of the warmup window\.