Inherit-MAS: Test-Time Evolution of Multi-Agent Systems through Workflow and Execution Inheritance

1 Introduction

• Workflow weaknesses emerge only after execution, while broad revisions can disturb useful work and retaining prior configurations alone cannot ensure old results still apply.The paper frames the challenge as improving task performance while controlling test-time inference cost.Source: §1 · pp. 1–2
• Inherit-MAS synthesizes workflows, has a separately prompted judge score outputs and traces, then applies a diagnosis-targeted validated edit while inheriting eligible results only for matching requests and contexts.After the attempt budget, it returns the highest-ranked completed candidate’s stored output.Source: §1 · p. 2
• On WorkBench and HotpotQA FullWiki, Inherit-MAS outperforms EvoAgent, EvoMAS, and TacoMAS on overall completion and joint F1 while using less inference than EvoMAS and TacoMAS.Against independent reruns without execution inheritance, it avoids 29.1% and 34.6% of live worker inference and saves 5.3% and 18.1% of total tokens, respectively.Source: §1 · p. 2

2 Background and Problem Formulation

• An LLM-based MAS coordinates agents with complementary roles, while a workflow-based MAS represents agents or operations as graph nodes and intermediate results as directed edges.Executing the graph yields an output, observable trace, and cost ledger; utility scores the answer or resulting environment state.Source: §2 · pp. 2–3
• A workflow may place a planner, environment-interacting workers, an integrator, and a verifier between the external task and benchmark evaluator.The task, interface, and environment are external to the illustrated workflow.Source: §2 · p. 2, Figure 1 · p. 3
• Evolving MAS revise agent configurations and interactions using execution feedback to improve task performance under computational and interaction budgets.A system may select one candidate’s output or assemble an output from several candidates.Source: §2 · p. 3

3 Related Work

• Multi-agent design research spans programmable conversations, role-based workflows, agent-program search, graph optimization, modular designs, and query-dependent system construction.Other methods adapt team composition, communication topology, or evidence passed to a coordinator.Source: §3 · p. 3
• Evolving-MAS methods use feedback to revise configurations and communication structures through evolutionary operations, mutation and crossover, coupled update loops, textual feedback, or validated graph edits.Some approaches also evolve reusable orchestration knowledge and execution procedures.Source: §3 · p. 3
• Inherit-MAS addresses the unresolved validity of stored results after workflow changes by selecting components to retain, validating refinements, and inheriting results only when complete requests and contexts match.The related-work discussion notes that workflow updates can affect downstream computations.Source: §3 · p. 3, Figure 2 · p. 4

4.1 Overview

• The controller synthesizes and executes an initial workflow, judges each attempt, refines the latest completed candidate, applies execution inheritance, and returns the highest-ranked completed candidate.Invalid attempts and synthesis fallbacks are also handled by the controller.Source: §4.1 · p. 4

4.2 Initial Synthesis and Judgment

• A separately prompted judge scores the candidate’s output and trace and provides textual critique and node-level keep-or-fix recommendations.Its score includes completion likelihood, requirement coverage, artifact grounding, and overall quality.Source: §4.2 · p. 4

4.3 Workflow Inheritance

• Workflow inheritance starts from the latest completed candidate, may discard nodes judged unhelpful, and applies one validated edit to the kept workflow without guaranteeing repair or improved performance.Validation rejects cycles, incompatible connections, unauthorized tools, and other interface violations; resynthesis may replace ordinary refinement on the final attempt under specified conditions.Source: §4.3 · p. 5

4.4 Execution Inheritance

• Execution inheritance reuses an eligible node’s stored result only when its complete resolved request and execution context match a verified record; state-changing operations are never eligible.The request includes upstream records and execution settings, while the context fingerprint covers runtime, parser, initial environment, and fixed services.Source: §4.4 · pp. 5–6

4.5 Ranking and Return

• The controller ranks completed candidates by recorded execution errors and output validity before returning the selected candidate’s stored output without re-execution.Cost is excluded from the ranking key, and retaining completed candidates prevents a lower-ranked child from displacing its parent.Source: §4.5 · pp. 6–7

5.1 Experimental Setup

• The evaluation uses WorkBench completion and HotpotQA FullWiki joint F1, comparing systems on fixed task sets with reference answers and metrics withheld until post-run scoring.The configurations use GPT-4o-mini and Qwen3-32B worker backbones; the judge and meta-model do not observe reference actions, answers, supporting facts, or official metrics during runs.Source: §5.1 · p. 7

5.2 Main Results

• Across both benchmarks and worker backbones, Inherit-MAS outperforms evolving-MAS baselines and is the only evolving system to match or exceed Single ReAct in all four settings.On WorkBench, it leads Single ReAct by 13.8 points with GPT-4o-mini and matches it at 46.2% with Qwen3-32B; on HotpotQA, it leads Single ReAct by 3.7 and 5.6 points, respectively.Source: §5.2 · p. 8, Table 1 · p. 8, Table 2 · p. 8

5.3 Performance across Refinement Rounds

• Official performance rises at every refinement round, gaining 5.0 points in total on HotpotQA and 9.2 points on WorkBench.The first WorkBench refinement round contributes 6.9 points; the reported final results are the R4 points.Source: §5.3 · p. 9, Figure 3 · p. 9

5.4 Execution Inheritance and Token Cost

• Execution inheritance saves 29.1% and 34.6% of worker tokens on WorkBench and HotpotQA, while total token savings are 5.3% and 18.1%, respectively.The savings arise when edits leave requests unchanged; prompt edits inherit 47.3% and 75.0% of worker-token equivalents, respectively. In the WorkBench rerun, full execution also reaches 55.4% completion, matching execution inheritance.Source: §5.4 · p. 9, Figure 4 · p. 9, §5.2 · p. 9

6 Conclusion

• Inherit-MAS preserves useful nodes, applies one validated diagnosis-targeted edit, and reuses stored results only for unchanged requests.The conclusion reports higher primary-metric scores than evolving-MAS baselines on both benchmarks with GPT-4o-mini and Qwen3-32B workers.Source: §6 · p. 9

A.1 Workflow Design and Optimization

• Workflow-optimization methods vary in what they optimize and when; Inherit-MAS instead focuses on how an executed task-specific MAS supplies components and completed computation for its next refinement.The passage contrasts validation-split optimization by AFlow (Zhang et al., 2025c) with query-dependent methods including MaAS (Zhang et al., 2025a), FlowReasoner (Gao et al., 2025), and MAS-GPT (Ye et al., 2025).Source: §A.1 · p. 13

A.2 Workflow Evolution

• Unlike approaches that carry configurations or feedback forward, Inherit-MAS explicitly verifies whether a stored node result remains valid after workflow revision.Select keeps useful incumbent nodes, Edit preserves workflow outside its declared scope, and execution inheritance checks the complete resolved request and execution context.Source: §A.2 · p. 13

A.3 Execution Reuse and Caching

• Execution inheritance restores eligible prior node outputs, tool observations, and artifacts unchanged only when the complete resolved request and execution context match.Unlike cached-response methods that regenerate failing regions, Figure 4 compares avoided execution with independent reruns of the same controller without inheritance.Source: §A.3 · p. 13
• Table 3 reports incumbent-to-candidate transitions, with binary completion for WorkBench and joint F1 for HotpotQA, alongside improvement, affected-region, inheritance, and cost measures.Its transitions are post-hoc aggregates from sealed trajectories.Source: Table 3 · p. 14
• The passage characterizes the reported associations as descriptive, not randomized edit effects, and does not present them as findings from randomized edit interventions.Source: §A.3 · p. 14

B.1 Ranking Headroom and Failure Modes

• 55.4% WorkBench completion and 49.7% HotpotQA joint F1 are achieved by online ranking, versus 49.2% and 44.7% for initialization and 50.0% and 44.4% for the last candidate.Later candidates are not uniformly better; the returned-candidate scores do not decrease across prefixes, while offline oracle prefixes reach 63.1% and 56.3%.Source: §B.1 · p. 14
• 34.7%–44.0% of worker-token equivalents are inherited on WorkBench and 44.0%–63.2% on HotpotQA at refinement indices 1–3, falling to 17.6% and 21.0% at index 4.The final-round restart produces the returned workflow for 25 WorkBench tasks and 47 HotpotQA questions, making that round less inheritance-friendly.Source: §B.1 · p. 14

B.2 Edit-Level Outcomes and Locality

• Only 8/24 WorkBench and 37/134 HotpotQA strictly improving transitions had affected regions smaller than the workflow; most improvements were nonlocal even under a permissive definition.Source: §B.2 · p. 14
• Local edits inherited 57.5% and 81.8% of worker-token equivalents on WorkBench and HotpotQA, versus restart costs of 4,134 and 4,667 live worker tokens.Source: §B.2 · p. 15
• Across WorkBench edits and restarts and HotpotQA subtask, tool, and topology edits (where restarts have a negative mean), evidence supports inheritance as a cost mechanism, but not locality as a proxy for edit quality.Source: §B.2 · p. 15
• Positive-mean edit families differed by benchmark, while prompt edits inherited 47.3% and 75.0% of worker-token equivalents and occasionally improved.Source: §B.2 · p. 15
• A WorkBench context-edge change inherited 2,452 worker-token equivalents versus 760 live tokens, while a HotpotQA repair raised joint F1 from 0.667 to 1.000 with every node rerun.Source: §B.2 · p. 15

B.3 Paired Headline Effects

• HotpotQA shows a larger win/loss margin, although some improvement may reflect broader retrieval exposure across candidates rather than topology changes.Source: §B.2 · p. 15, §B.3 · p. 15, Table 4 · p. 15

C.1 Complete Controller

• The controller refines the latest completed candidate through validated pruning and editing, and inherits stored results only for eligible nodes outside the affected region when request and execution context match.A final-round restart can instead begin from a fresh workflow; inherited execution errors still count toward hard failures.Source: §C.1 · pp. 16–17

C.2 Inherit-MAS Settings

• Table 5 identifies implementation settings shared across benchmark runs; benchmark-specific roles, tools, schemas, and runtime limits are specified separately.The supplied passage does not provide Table 5's setting values.Source: §C.2 · p. 17, Table 5 · p. 17

C.3 Workflow and Output Rules

• A shared controller uses benchmark adapters to define typed workflow rules, while validators enforce graph structure, compatible inputs and outputs, authorized tools, and execution constraints.HotpotQA workflows have two to seven nodes, one synthesizer, and at least one retrieval-capable researcher; WorkBench workflows have a deterministic executor as their sole sink.Source: §C.3 · pp. 17–18

C.4 Prompts, Scores, and Role Guides

• Separate controller prompts guide synthesis, skeptical judging, node selection, and single-edit proposals, with one JSON-repair attempt permitted after validation failure.The judge uses observed outputs and artifacts rather than benchmark reference answers, and the proposer is shown validated edits that address reported defects.Source: §C.4 · pp. 18–20

C.5 Worker Role Prompts

• Worker wrappers give WorkBench nodes role-specific instructions and provide HotpotQA nodes with ordered reports and rules to cite only observed indexed sentences.WorkBench instructions distinguish read-only workers from integrators, verifiers, and critics; HotpotQA instructions distinguish planners, researchers, verifiers, and synthesizers.Source: §C.5 · pp. 20–21

C.6 Output Schemas and Runtime Limits

• HotpotQA candidates receive four BM25 calls in total, while tool-enabled nodes run for at most five turns and language-model nodes have a 900-token output limit.A change in retrieval-node allocation can place affected nodes in the execution region; WorkBench worker and controller limits are also specified.Source: §C.6 · p. 21

C.7 Search Inputs and Offline Scoring

• The judge receives each candidate's workflow, node outputs, and observed task-specific artifacts, while reference answers, actions, supporting facts, and official metrics are reserved for post-run scoring.The judge prompt is separate from synthesis and refinement prompts and can use node outputs to identify useful or unhelpful components.Source: §C.7 · p. 21
• Candidates with hard execution failures are rejected; remaining candidates are ranked by output validity, overall quality, requirement coverage, artifact grounding, and then earlier execution.Offline scoring includes four scores on a 0–100 scale: overall quality, completion likelihood, requirement coverage, and artifact grounding.Source: §C.7 · p. 22

D Evaluation Protocol and Baselines

• Evaluation uses 130 WorkBench tasks from 13 held-out template clusters and 300 hash-selected HotpotQA IDs, excluding earlier development IDs.WorkBench Overall is the completion rate across all tasks, with domains weighted by task counts. HotpotQA joint F1 is averaged over questions and penalizes correct answers without valid supporting facts; integrity audits passed for 1,859 inherited WorkBench results and 751 inherited HotpotQA results.Source: D Evaluation Protocol and Baselines · p. 22

• Baseline controllers use pinned upstream releases with benchmark-specific adaptations, and the reported GPT-4o-mini configurations are distinct from the Qwen configurations.Source: §D.1 · p. 22
• EvoAgent uses a ported population mechanism; its WorkBench setup omits quality filtering, while HotpotQA retains role-quality filtering and allows four BM25 calls per agent.Source: §D.1 · p. 22
• WorkBench EvoMAS retains memory, persistent per-domain pools, mutation and crossover, and fresh winner reevaluation, with its worker palette fixed to GPT-4o-mini.Source: §D.1 · p. 22
• HotpotQA EvoMAS retains serial task order, persistent pools and memory, two parents, two evolution steps per task, and model mutation within a GPT-4o-mini worker palette.Source: §D.1 · pp. 22–23
• HotpotQA TacoMAS adapts fast capability and slow topology mechanisms to the shared runtime and structured answer/supporting-fact interface, without execution inheritance.Source: §D.1 · p. 23
• WorkBench TacoMAS uses native agent-state and graph mechanisms with a compiler and deterministic executor, but its main-table run is a benchmark adaptation rather than a verbatim upstream implementation.Source: §D.1 · p. 23

D.2 Qwen3-32B Backbone Evaluation

• The Qwen3-32B evaluation keeps Inherit-MAS’s controller, judge, prompts, edit family, and scoring rules while replacing only its worker model.The Qwen workers use non-thinking mode at temperature zero; synthesis, refinement, and judging remain assigned to GPT-5.4-mini, and the baseline implementations include stated routing and search differences.Source: §D.2 · pp. 23–24

E.2 Detailed Cost Ledgers

• The cost ledgers separate task-solving Worker calls from Meta/judge calls for synthesis, node selection, refinement, and critique.Table 7’s role-based accounting includes integration and benchmark-output compilation under Worker.Source: §E.1 · p. 24

E.1 Inference and Search Cost

• Inherit-MAS is more accurate and less costly than EvoMAS and TacoMAS under the reported configurations, while Single ReAct remains a cheaper non-MAS reference.Figure 5 shows observed quality–cost operating points, with provider cost normalized within each benchmark to Single ReAct = 1×.Source: §E.1 · p. 24, Figure 5 · p. 25

E.3 Inheritance Ledger and Full Traversal

• Execution inheritance uses the complete resolved-request digest as the authority for reuse, including when an affected path resolves to a previously seen request.An inheritance hit contributes zero live worker tokens; the inherited token equivalent is counterfactual and is not added to provider usage.Source: §E.3 · p. 25
• Full traversal and change-localized execution have the same live model-call miss set; change localization supports auditability and subgraph accounting, not additional worker-token savings.The affected region distinguishes unchanged nodes from request reconvergence, while both cases verify a complete digest.Source: §E.3 · p. 25

E.4 Full-Execution Reruns and Store Footprint

• 2.08M and 1.98M WorkBench worker tokens and 5.50M HotpotQA worker tokens were recorded in full-execution reruns, against original-run usage of 1.44M and 3.60M, respectively.Charging each inheritance hit its stored original usage predicts 1.97M and 5.53M worker tokens under full execution, within 3% of the mean WorkBench rerun usage and the HotpotQA rerun usage, respectively.Source: §E.4 · pp. 25–26
• The deterministic-runtime audit found byte-identical node outputs and score vectors across three execution conditions on 240 frozen candidate-problem pairs.This audit used a local deterministic Qwen3-14B and LiveCodeBench substrate; for remote models, inheritance does not assert fresh-call byte identity.Source: §E.4 · p. 26

E.5 Candidate-Prefix Cost

• The fifth candidate has higher cumulative live cost because its final-round restart frequently produces a new workflow rather than a local edit suited to inheritance.Table 10 reports cumulative live cost through candidate prefixes, with total provider tokens and summed model-call wall time.Source: §E.5 · p. 27, Table 10 · p. 27

E.6 Artifacts and Accounting

• Runs record frozen manifest digests, source and configuration fingerprints, per-call usage, task wall time, tool or retrieval calls, invalid attempts, and atomic completion records.Stored record identity and content are digest-checked on each load; any mismatch is a blocking integrity error.Source: §E.6 · p. 27

F Code and Data Availability

• The implementation, evaluation task lists, and scoring scripts are available at the project repository, while benchmark data remain subject to their original licenses.Restricted source data will not be redistributed.Source: F Code and Data Availability · p. 27