PaperlayerView exact revision on arXiv

Source-linked AI summary

Goal-Aware Dynamic Multi-Agent Collaboration for Long-Horizon Tasks

Xu Shen, Lingyong Yan, Shuaiqiang Wang, Jianmin Wu, Zhikai Chen, Jiliang Tang, Jie Ren

arXiv:2610.39193v1cs.AI

TL;DR

Long-horizon agents must manage changing duties and accumulated context, but single-agent verification often comes late and separating agents into distinct contexts does not ensure goal alignment or useful information exchange. GAD uses a growing execution graph to coordinate goal-aware subtasks, dependencies, and verification; it achieves the highest reported resolution rates across the evaluated benchmarks and base models.

  • Problem

    Long-horizon agents need to manage changing duties and growing context, yet verification often occurs late, duty-relevant information shrinks in shared histories, and multi-agent separation alone does not ensure goal alignment or useful information exchange.

    Source: §1 · p. 1

  • Method

    GAD uses a growing execution graph to organize subtasks and dependencies while retaining task goals and acceptance conditions in agent contexts and checking results for repair.

    Source: §1 · p. 2

  • Results

    GAD achieves the highest resolution rates across benchmarks and base models, beating the strongest single-agent harness by 14.6 and 7.8 percentage points on Terminal-Bench 2.1 and by 2.0% and 1.9% on Hard-51.

    Source: §5.2 · p. 7

  • Takeaways & Limitations

    Further analyses support component effectiveness and show lower token costs than multi-agent baselines on jointly solved tasks.

    Source: §1 · p. 2

Abstract

from arXiv · show

LLM-based agents are increasingly used to complete complex, long-horizon tasks without human intervention. To make progress toward the task goal, agents need to perform different duties, such as planning and verification, when needed. To understand how single agents manage these duties during long-horizon execution, we conduct a preliminary study. Our analysis shows that verification has the strongest association with task success, but often occurs late, leaving limited opportunities for correction. We also find that the proportion of duty-relevant information decreases as records from different duties accumulate in a shared context. These findings lead us to examine whether multi-agent systems (MAS) can address these problems by assigning duties to agents with separate contexts. Our analysis shows that this separation alone is insufficient. Agents can lose track of the overall goal and repeat prior investigations. They may also lack necessary background while receiving irrelevant information from others. To maintain goal awareness and coordinate collaboration as task needs change, we propose Goal-Aware Dynamic Multi-Agent Collaboration (GAD). It uses a growing execution graph to organize subtasks and their dependencies. To keep agents focused on their goals, each context retains the original instruction and the assigned task's goal and acceptance conditions. To adapt collaboration and information sharing during execution, agents can divide tasks into subtasks and specify dependencies based on execution evidence. These dependencies guide when agents work and which results they receive. Verification and recovery check subtask results and full task completion against their goals, providing feedback for repair when checks fail.

1 Introduction

Long-horizon agents must shift among duties such as planning and verification, but single agents often verify late and lose duty-relevant information in accumulated context. GAD organizes dynamic multi-agent collaboration around task goals, subtasks, and dependencies, while checking results and enabling repair.

1 Introduction

  • Long-horizon tasks involve repeated environment interactions and require agents to perform duties such as planning, reasoning, verification, and functional responsibilities as needed.The introduction frames duty allocation and switching as important to avoiding outdated plans and unchecked errors.Source: §1 · p. 1
  • Verification is strongly associated with task success but often occurs late, while duty-relevant information becomes a smaller share of the accumulated shared context.These findings motivate assigning duties to separate agents, though the introduction notes that separate contexts alone do not resolve the collaboration problem.Source: §1 · pp. 1–2
  • Existing multi-agent systems can lose track of the overall goal, repeat investigations, and exchange irrelevant information while agents lack necessary background.These limitations motivate maintaining goal awareness and dynamically coordinating duties and information exchange during execution.Source: §1 · p. 2
  • GAD organizes subtasks and their dependencies in a growing execution graph while retaining the original instruction and each assigned task’s goal and acceptance conditions in agent contexts.Agents can propose evidence-based dependencies that guide scheduling and information sharing; verification and recovery check subtask and full-task results and provide repair feedback when checks fail.Source: §1 · p. 2

2 Related Work

Prior work addresses long-horizon execution through training and memory or subtask-management methods, while multi-agent research studies collaboration structures and coordination. GAD complements these directions by organizing execution-time collaboration through a growing graph that connects proposed subtasks, dependencies, information sharing, and verification.

2.1 Long-Horizon Agents

  • Long-horizon agent research includes supervised fine-tuning and multi-turn reinforcement learning, as well as methods for memory updates, history summarization, separate subtask trajectories, and independently checked progress.GAD is presented as complementary to policy training because it organizes collaboration during execution.Source: §2.1 · p. 2

2.2 Multi-Agent Systems

  • Multi-agent work ranges from predefined roles to learned or searched collaboration structures and execution-time orchestration, whereas GAD connects agent-proposed decomposition with dependency-guided execution and verification without a central LLM orchestrator.The passage situates GAD alongside work on collaboration structures and runtime coordination.Source: §2.2 · p. 2

3 Preliminary study

The preliminary study examines how agents allocate duties and use information during long-horizon execution, first in single-agent loops and then in multi-agent systems. It finds that late verification and diluted relevant context are not solved merely by separating agents into distinct contexts.

3.1 Auditing long-horizon loops by single agents

  • The single-agent audit covers 193 trajectories and 4,842 steps from a 45-task Terminal-Bench 2 subset, using an LLM judge to assign responsibility categories to agent outputs.The analysis considers verification’s relation to success and timing, alongside how current-duty information appears in growing interaction histories.Source: §3.1 · pp. 2–3
  • Verification is the smallest main duty, appears mainly near trajectory end, and pass rates rise from 36% in the lowest-verification group to 74% in the highest.No passing trajectory skips verification, but about a quarter of trajectories in the highest-verification group still fail.Source: §3.1 · p. 3
  • As trajectories grow, prior steps needed by the current duty increase from about 5 to 30, while relevant steps increase only from 1.4 to 3.0.The proportion of relevant context falls from 33% to 14% as records from different duties accumulate.Source: §3.1 · p. 3

3.2 Can multi-agent systems supply what a single agent lacks?

  • The multi-agent audit compares six paradigms with a single-agent baseline on the same 45-task subset, judging each agent’s steps with the responsibility audit.The configurations include a role pipeline, three static topologies, an orchestrator, and subagents.Source: §3.2 · pp. 3–4
  • Across the evaluated multi-agent systems, off-track behavior occurs 2–5 times more frequently than for the single agent, with nearly all off-track steps involving repeated actions already attempted.The study attributes this pattern to predefined roles and execution order, isolation from overall progress, and lack of feedback-driven adaptation.Source: §3.2 · p. 4
  • Between 4% and 30% of exchanged messages are irrelevant to their receivers, and delegated agents’ first two steps have failure rates up to 2.3 times those of later steps.More aggressive message compression has the highest irrelevance rates, and summarization may discard information needed downstream.Source: §3.2 · p. 4
  • The study concludes that long-horizon collaboration needs goal awareness and dynamic collaboration, adapting responsibilities and information exchange to evolving execution needs.Existing systems instead rely on predefined roles and communication structures, which can impede timely duties and relevant information exchange.Source: §3.2 · p. 4

4 Method

GAD uses a growing execution graph to keep task goals and dependencies explicit as agents decompose work in response to emerging needs. Dependency-aware contexts supply relevant information, while verification and recovery assess results and direct further execution when needed.

4 Method

  • GAD combines goal awareness and dynamic collaboration in a growing execution graph, with context construction and verification-and-recovery mechanisms supporting node execution.The graph expands through agent-proposed subtasks and dependencies, and verified results support integration and final verification of the original task.Source: §4 · p. 4, Figure 3 · p. 5, §4.2 · p. 6

4.1 The Main Framework: Growing Execution Graph

  • Each graph node represents an assigned task with its own goal, acceptance conditions, and execution status; edges encode subtasks or required verified results.The root node begins with the original instruction as its goal and a completion requirement as its acceptance condition.Source: §4.1 · p. 5
  • Agents can request decomposition when new observations reveal subtask needs, proposing goals, acceptance conditions, dependencies, and references to prior execution steps.A lightweight rule-based controller validates requests against the graph, execution history, and remaining budgets before applying updates.Source: §4.1 · p. 5
  • The controller schedules nodes according to dependency and route outcomes, and the root completes only after passing verification against the original instruction and its acceptance conditions.Execution may also stop when budgets run out or no nodes can execute, but those conditions do not establish task completion.Source: §4.1 · p. 6

4.2.1 Dependency-Aware Context Construction.

  • Dependency-aware context construction combines task information and execution records with selected results, while retaining the original instruction, node goal, and acceptance conditions.Declared dependencies supply verified results directly; retrieval can supplement them with relevant results that have no explicit dependency link.Source: §4.2.1 · p. 6

4.2.2 Verification and Recovery.

  • Verification and recovery check whether node results satisfy their goals and acceptance conditions, using executable checks and an independent semantic review.The semantic review evaluates execution evidence and verified dependency results; when no executable check applies, recorded evidence is assessed directly.Source: §4.2.2 · p. 6
  • Accepted results become evidence-linked results for dependent contexts, while failed checks or reviews return feedback to the node for continued execution and repair.A rejected verification does not by itself fail the route.Source: §4.2.2 · p. 7

5 Experiments

Experiments compare GAD with single-agent and multi-agent systems on Terminal-Bench 2.1 and SWE-Bench Pro Hard-51. GAD leads the benchmark comparisons, while ablations and trajectory analyses examine its components, collaboration behavior, and cost.

5.1 Experimental Setup

  • Experiments use Terminal-Bench 2.1 and Hard-51 of SWE-Bench Pro, comparing single-agent harnesses, static and dynamic multi-agent systems, and GAD.The setup uses Claude Sonnet 4.6 and Qwen3.7-Plus as base models, with up to three concurrent workers per task.Source: §5.1 · p. 7

5.3 Ablation Studies

  • Removing either goal awareness or dynamic collaboration lowers resolution in all four settings; Sonnet 4.6 on SWE-Bench Pro falls from 66.7% to 58.8% and 52.9%, respectively.On Qwen3.7-Plus Terminal-Bench 2.1, removing goal awareness yields 60.7%, versus 61.8% without dynamic collaboration; Qwen decomposes only 2 of 89 tasks there.Source: §5.3 · p. 7, Table 2 · p. 8
  • On tasks GAD decomposes, disabling decomposition reduces solved tasks from 7 to 3 of 15 on Terminal-Bench 2.1 and from 15 to 10 of 24 on SWE-Bench Pro.The comparison reruns only tasks decomposed by the full GAD configuration, with each task proceeding through the root node when decomposition is disabled.Source: §5.3 · p. 7, Figure 4 · p. 8

5.2 Main Results

  • GAD exceeds the strongest multi-agent baseline by 6.7% and 6.7% on Terminal-Bench 2.1, and by 23.6% and 3.9% on Hard-51 under two base models.The table reports task resolution rates; the prose does not map each pair to a specific base model.Source: §5.2 · p. 7, Table 1 · p. 8
  • GAD achieves the highest resolution rate across benchmarks and base models, beating the strongest single-agent harness by 14.6 and 7.8 percentage points on Terminal-Bench 2.1 and 2.0% and 1.9% on Hard-51.Gains are larger on Terminal-Bench, while the strongest single-agent harness remains competitive on Hard-51.Source: §5.2 · p. 7, Table 1 · p. 8

5.4 Improvement on the two limitations in MAS

  • Only 10.2% of GAD steps leave their assigned subgoal, versus 14.9% for subagents and 37.7% for MetaGPT, in an audit of seven decomposed Terminal-Bench tasks.The authors suggest that subgoals formed during execution give agents clear targets with acceptance criteria.Source: §5.4 · p. 8, Figure 4 · p. 8
  • GAD’s newly assigned agents have tool errors on 10.1% of their first two steps and 9.8% later; Chain’s first-two-step error rate is 35.7%, versus 17.6% later.The authors attribute GAD’s early performance to agents receiving verified results from dependent subgoals before starting.Source: §5.4 · p. 8, Figure 4 · p. 8

5.5 Efficiency Analysis

  • On shared solved tasks on Terminal-Bench 2.1 with Sonnet 4.6, GAD uses about 50k tokens per task, versus 105–170k for multi-agent systems and 2.6M for the long-horizon harness.The token count includes input and output tokens across all agents, including GAD verification calls; the authors say GAD adds structure only when needed.Source: Figure 4 · p. 8, §5.5 · p. 9

6 Conclusion

The conclusion presents GAD as a way to maintain goal awareness and coordinate collaboration as execution reveals new needs. Experiments on two benchmarks report gains of up to 6.7 percentage points over the strongest baseline.

6 Conclusion

  • GAD organizes subtasks and information sharing with a growing execution graph, while each agent context retains the original instruction, task goal, and acceptance conditions.Agents can divide tasks and specify dependencies during execution; verification and recovery check subtask results and full task completion, feeding failed checks into repair.Source: §6 · p. 9
  • The preliminary analysis finds verification most associated with task success but often late, declining duty-relevant information in growing contexts, and goal tracking and information-sharing problems in existing multi-agent systems.The conclusion states that context separation alone does not ensure effective information sharing.Source: §6 · p. 9
  • Experiments with Claude Sonnet 4.6 and Qwen3.7-Plus on Terminal-Bench 2.1 and SWE-bench Pro Hard-51 show gains of up to 6.7 percentage points over the strongest baseline.Source: §6 · p. 9

A Details of the Audit

The audit examines configurations, duty allocation, and the relevance of earlier context to a current step. Judges classify step content by duty and identify which earlier steps are needed.

A Details of the Audit

  • The audit covers five configurations on a 45-task Terminal-Bench 2 subset, varying harness with Opus 4.6 fixed or model with ReAct fixed.The subset contains 4 easy, 26 medium, and 15 hard tasks; trajectories without a verifier run are excluded.Source: A Details of the Audit · p. 11, Table 3 · p. 11
  • A judge divides each step’s generated content among seven duties as fractions summing to one, using the instruction, reasoning, command, and resulting observation.The judge does not see the authors’ step labels.Source: A Details of the Audit · p. 11, Table 4 · p. 11
  • Context relevance is measured by sampling 30 steps across five trajectory segments and counting the earlier steps each current step needs.Sampled steps come from trajectories of at least six steps and have at least three preceding steps; earlier observations are cut to 8,000 characters and rendered histories to 60,000.Source: A Details of the Audit · p. 11

B Pseudo-code for GAD

GAD repeatedly selects ready tasks, acts from local context, and updates its execution graph and results. Only verification of the root establishes task completion.

B Pseudo-code for GAD

  • The loop stops when the root passes verification, the budget is exhausted, or no ready nodes remain; only root verification establishes task completion.In concurrent execution, the controller waits for running agents before treating an empty frontier as a stopping condition.Source: B Pseudo-code for GAD · p. 11
  • At each iteration, GAD updates node states, checks stopping conditions, selects a ready node, and generates an action from its local context.It then handles environment execution, task decomposition, and retrieval; accepted decompositions expand the graph, while rejected requests return feedback.Source: B Pseudo-code for GAD · p. 11
  • GAD checks node completion and publishes a result only after verification; failed checks retain feedback for repair.An active node can return to READY.Source: B Pseudo-code for GAD · p. 11

C Implementation Details

The implementation combines per-task execution budgets with worker contexts containing task goals and relevant artifacts. A separate verifier checks each complete node goal and its acceptance clauses.

C Implementation Details

  • Claude Sonnet 4.6 and Qwen3.7-Plus serve as base models, with the same model used for node execution and semantic verification within each setting.All methods share a per-task execution budget within each evaluation setting; Growing-DAG workers share tool and model-call budgets, and verification commands count toward the tool-call budget.Source: C Implementation Details · p. 11
  • Each worker receives the original task, its assigned node and acceptance conditions, dependency information, recent local records, and relevant shared artifacts.Retrieved candidates are reusable only after contract and dependency compatibility checks.Source: C Implementation Details · p. 11
  • A separate verifier evaluates the complete node goal and every acceptance clause; finishing child nodes alone does not verify their parent.The reference worker instructions include a verification-request format, with braced fields populated by the runtime.Source: C Implementation Details · p. 11
  • The algorithm initializes a root task and graph, executes actions, expands the graph after accepted decomposition, and publishes a node result only when verified.The supplied workflow also retrieves results for later context and returns a verified result to the shared results store.Source: C Implementation Details · p. 12

Role and Coordination Rules

GAD’s worker instructions restrict each worker to one obligation node and make decomposition evidence-based. Child completion supports a parent retry but does not itself verify the parent.

Role and Coordination Rules

  • A local worker owns one obligation node, should not produce a global plan, and may decompose only after concrete local execution evidence reveals prerequisites or blockers.Each decomposition must cite prior local evidence step IDs; the runtime rejects graph growth without them.Source: Role and Coordination Rules · p. 12
  • Decomposition creates an alternative AND-route, so every child must be verified before the parent can be retried, and the parent must still pass its own acceptance check.Children must be narrower, more local, and more verifiable than the parent; route and child counts are bounded by configured limits.Source: Role and Coordination Rules · p. 12
  • Workers should search for reusable artifacts rather than duplicate work; published claims need prior local step evidence, and only runtime verification creates verified artifacts.The instructions prohibit access to hidden benchmark solutions, hidden verifier state, credentials, and host data.Source: Role and Coordination Rules · p. 12

Execution and Retrieval

The instructions define a choice between running one coherent shell command and searching for reusable artifacts.

Execution and Retrieval

  • Choose RUN to execute one coherent shell command, returning its reason, mode, command, write targets, and any useful published information.For INSPECT or TEST, use no write targets unless the command intentionally mutates persistent state.Source: Execution and Retrieval · p. 12
  • Return exactly one JSON object and keep command choices focused and complete.The output format specifies one action per response.Source: Execution and Retrieval · pp. 12–13
  • Choose SEARCH to look for reusable artifacts by query, with an optional publication list.Source: Execution and Retrieval · p. 13

Evidence-Grounded Decomposition

The runtime supports evidence-grounded task decomposition, verification and control actions, using local graph and execution context to inform an agent’s next step.

Evidence-Grounded Decomposition

  • DECOMPOSE a node into narrower obligations with goals, acceptance conditions, scopes, and dependencies grounded in execution evidence.Dependencies may refer to children in the route or visible dependency nodes, but not the parent.Source: Evidence-Grounded Decomposition · p. 13

Verification and Control Actions

  • When acceptance conditions are incomplete, VERIFY with up to four non-destructive checks, preferring mechanical checks where possible.If no command can reasonably verify the node, leave commands empty for a strict semantic verifier to inspect concrete evidence.Source: Verification and Control Actions · p. 13
  • ABANDON only an unproductive method, BLOCK only when concrete evidence prevents progress, or YIELD when another ready node should proceed or no useful local action remains.Blocking fails the containing route; abandoning a method does not fail the node.Source: Verification and Control Actions · p. 13

Local Input Context

  • The local context supplies the original task, node goals and acceptance conditions, graph dependencies, execution evidence, artifacts, and retrieved results.Source: Local Input Context · p. 13

Related papers

Loading 2610.39193v1…