PaperlayerView exact revision on arXiv

Source-linked AI summary

AutoSwarm: Automating Agent Swarms

Zhonghang Li, Zongwei Li, Chao Huang

arXiv:2610.33048v1cs.MA

TL;DR

Distributing LLM-agent work does not by itself ensure complementary contributions, and dependencies can let local errors or blockers disrupt the task. AutoSwarm specifies responsibilities and result-acceptance conditions, then coordinates execution through shared state; across three benchmarks, it reports higher task completion than single-agent baselines and existing multi-agent frameworks.

  • Problem

    Multi-agent work can lack complementary contributions, while inter-agent dependencies can let local errors and blockers disrupt task completion.

    Source: §1 · p. 2

  • Method

    AutoSwarm defines contribution responsibilities and acceptance conditions, then uses shared state, dependencies, and supervisory relationships to coordinate execution, review, revision, and integration.

    Source: §1 · p. 2

  • Results

    Across three benchmarks, AutoSwarm achieves higher task completion than single-agent baselines and existing multi-agent frameworks, with consistent gains across LLM backbones.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The results highlight the value of task-specific organization and coordinated execution for multi-agent collaboration.

    Source: §1 · p. 2

Abstract

from arXiv · show

Large language model (LLM) agents increasingly automate complex tasks, with multi-agent systems seeking further performance gains through specialization and collaboration. However, distributing work across agents does not automatically yield complementary contributions, and inter-agent dependencies can turn local errors into task failure. To address these challenges, we propose AutoSwarm, a multi-agent framework for collaborative problem solving. Collaboration formation jointly defines responsibility boundaries and conditions for acceptance and downstream use, grounding capability allocation in contributions that other agents can assess and integrate toward a shared objective. Execution coordination couples agents' local progress through a shared state, using dependencies and supervisory relationships to govern agent activation, result handoffs, and integration while adapting subsequent actions to review feedback and emerging blockers. Experiments spanning long-horizon programming, interactive planning, and professional financial analysis demonstrate AutoSwarm's advantages over single-agent baselines and existing multi-agent frameworks. Source code is available at https://github.com/HKUDS/AutoSwarm.

1 Introduction

The introduction argues that distributing work across agents is not enough: responsibility boundaries and inter-agent dependencies must be managed to produce complementary, usable contributions. AutoSwarm addresses these challenges with collaboration formation and shared-state execution coordination, and reports higher task completion across three benchmarks.

1 Introduction

  • Single-agent loops handle multiple stages but concentrate evidence gathering, interpretation, and execution; analyses report cases where coordinated agents examine complementary evidence and perform better.The introduction frames these findings as motivation for distributing responsibilities across agents.Source: §1 · p. 1
  • Existing multi-agent approaches use specialization, structured workflows, or adaptive orchestration, yet assignment mismatches and failures coordinating dependent activities can limit their gains.The cited approaches include standardized procedures, feedback-based group adjustment, and orchestrator-led delegation and monitoring.Source: §1 · pp. 1–2
  • Responsibility splits can overlap or omit requirements, while unchecked results, missed revisions, and unanswered requests can stall dependent work or cause task failure.Collaboration must specify expected outputs, acceptance conditions, and downstream use, while coordination identifies what can proceed, needs correction, and who resolves blockers.Source: §1 · p. 2
  • AutoSwarm combines collaboration formation, which defines responsibilities and acceptance and downstream-use conditions, with execution coordination that tracks shared progress and dependencies.Review feedback and blockers update the shared state to adjust actions and assign execution, revision, or integration.Source: §1 · p. 2
  • Across three benchmarks, AutoSwarm achieves higher task completion than single-agent baselines and existing multi-agent frameworks, with consistent gains across LLM backbones.The benchmarks span multiple domains and task types.Source: §1 · p. 2

2 Preliminaries

The preliminaries model an agentic task through its objective, environment, and required result, then describe collaboration as organizing capabilities and coordinating interdependent work. AutoSwarm represents that collaboration with an organization, delegation graph, and shared execution state that evolve as new events arrive.

2 Preliminaries

  • An agentic task pairs natural-language objectives and requirements with an execution environment, and specifies a result such as an answer, artifact, or completed environment change.The environment includes initial context, relevant resources, and available tools.Source: §2 · p. 2
  • The paper focuses on how collaboration organizes available capabilities and coordinates interdependent work to satisfy task requirements.Source: §2 · p. 3
  • AutoSwarm represents collaboration with an organization O, delegation graph G_t, and shared state s_t; graph nodes bind scoped goals to agents, expected results, acceptance conditions, and parent objectives.Edges encode required handoffs; the organization assigns task-specific responsibilities and supervisory relationships before execution.Source: §2 · p. 3
  • New delegations, submitted results, review feedback, and blockers update task units and handoff conditions, release dependencies or require revision, and assign execution, review, revision, or integration actions.The organization stays fixed while the graph and state adapt; accepted contributions are integrated into a result assessed against the original requirements.Source: §2 · p. 3

3 Methodology

AutoSwarm’s methodology divides collaboration into formation and execution coordination, linking agent responsibilities to task units and connecting local work through dependencies and a shared execution state.

3.1 Collaboration Formation

  • Collaboration formation establishes a team around task functions and translates responsibilities into scoped task units with outputs and relationships.Supervisory relationships establish accountability, while result dependencies specify how contributions support one another.Source: §3.1 · p. 3

3.1.1 Adaptive Team Composition

  • Team planning matches roles and agent profiles to task complexity, required expertise, tools, and execution capabilities.Each role is justified by the contribution lost if it were removed or merged, and the team is established before execution.Source: §3.1.1 · p. 3

3.1.2 Structured Task Delegation

  • Task units specify scope, outputs, ownership, acceptance criteria, dependencies, and review relationships, while graph edges represent required accepted-result handoffs.Handoffs convey results, supporting evidence, remaining limitations, and intended use; supervisors assess whether contributions address the objective and can be integrated.Source: §3.1.2 · p. 4

3.2 Execution Coordination

  • Execution coordination uses a shared state to track unit progress, unresolved issues, and next actions while connecting local work to review, integration, and blockers.The state adapts as interaction proceeds.Source: §3.2 · p. 4

3.2.1 State-Based Task Execution

  • Task-unit lifecycles move through execution, review, and terminal outcomes, with corrective feedback returning a unit for revision.Units retain their goal, observations, output, and feedback across turns; integration combines accepted child contributions and checks parent requirements.Source: §3.2.1 · pp. 4–5
  • The shared state determines which agent executes, assesses, or integrates a contribution, and acceptance governs whether its result is available to other agents.A unit advances from READY to IN PROGRESS when the dependency gate is satisfied and necessary information is available; independent eligible units can advance concurrently.Source: §3.2.1 · p. 5

3.2.2 Event-Driven Interaction

  • Scoped messages and execution events link emerging information needs to affected units, evidence, and the role responsible for the next action.Replies update shared state; timeouts or unsuccessful contributions activate supervisory coordination for clarification, correction, replacement, or justified dependency revisions.Source: §3.2.2 · p. 5

4 Experiments

Experiments evaluate AutoSwarm on long-horizon programming, interactive planning, and professional financial analysis, comparing it with single-agent systems, multi-agent frameworks, and collaboration designs. Across these settings, AutoSwarm improves task completion, while ablations examine contribution specifications and supervisory review.

4 Experiments

  • The experiments address long-horizon single-agent comparisons, multi-agent comparisons, professional-domain generalization, and collaboration design.RQ5 execution case studies are reported in Appendix A.4.Source: §4 · p. 5

4.1.1 Benchmarks

  • The benchmarks cover 20 LongCLI-Bench programming tasks, 117 Plancraft-small planning problems, and 80 Investment Banking Analyst tasks.They assess executable tests, target-item production or infeasibility identification, and expert-rubric fulfillment, respectively.Source: §4.1.1 · p. 6

4.1.2 Baselines and Configurations

  • Single-agent AutoSwarm configurations use the corresponding baseline agent’s backbone; RQ2 configurations run once on all 117 problems using GPT-5.6-Luna at max, except Codex (ultra), which uses ultra mode.Each single-agent configuration is evaluated twice on all 20 tasks, with arithmetic mean pass rates reported; collaboration architectures are evaluated once on all 117 Plancraft-small problems.Source: §4.1.2 · p. 6

4.2 Long-Horizon Performance (RQ1)

  • 12.5 percentage points is AutoSwarm’s average overall Pass Rate gain across three backbones on LongCLI-Bench, with gains recurring in both runs.The gains are 10.0 points for MiniMax-M3, 12.5 for DeepSeek-V4-Flash, and 15.0 for GPT-5.6-Luna.Source: §4.2 · p. 6, Figure 3 · p. 7

4.3 Multi-Agent Comparison (RQ2)

  • 74.36% success on Plancraft-small exceeds Codex’s 60.68% and the strongest existing multi-agent baseline, Teamwork, by 11.11 points.All configurations correctly identify the 20 unsolvable problems; on solvable goals, AutoSwarm reaches 69.07% versus Teamwork’s 55.67%.Source: Figure 4 · p. 7, §4.3 · p. 7

4.4 Professional Generalization (RQ3)

  • 41.25% Pass@1 is the highest listed on the APEX-Agents 1.1 banking subset, exceeding GLM-5.1 by 1.65 points.AutoSwarm also improves Mean Score and Pass@1 over the official GPT-5.6-Luna reference by 6.09 and 5.95 percentage points, respectively.Source: §4.4 · pp. 7–8, Table 1 · p. 8

4.5 Collaboration Design (RQ4)

  • AutoSwarm reaches 74.36% on Plancraft-small, surpassing the strongest architectural baseline, Independent, by 4.27 points overall and 3.09 on solvable problems.Removing contribution specifications lowers success to 70.09%; removing supervisory review lowers it by 12.82 points to 61.54%. Both variants retain 100% unsolvable success.Source: Figure 5 · p. 8, §4.5 · p. 8

5 Conclusion

AutoSwarm coordinates agent capabilities into contributions toward a shared objective. Its evaluations show higher task completion than single-agent baselines and existing multi-agent frameworks, with consistent gains across LLM backbones.

5 Conclusion

  • AutoSwarm establishes distinct responsibilities and specifies each agent’s expected output and the conditions for accepting and using it.These conditions ground execution coordination in contribution progress and dependencies tracked through a shared state.Source: §5 · p. 8
  • Feedback and emerging blockers update the shared state, guiding execution, review, revision, and integration as work unfolds.Source: §5 · p. 8
  • Evaluations across three benchmarks show higher task completion than single-agent baselines and existing multi-agent frameworks, with consistent gains across different LLM backbones.Source: §5 · p. 8

A Supplementary Material

The appendix adds methodological detail, related-work review, supplementary experimental configurations, and paired case studies of AutoSwarm’s collaboration mechanisms.

A Supplementary Material

A.1 Methodological Details

This section expands AutoSwarm’s interaction mechanisms, linking communication to task responsibilities and emerging coordination needs to the shared execution state.

A.1 Methodological Details

  • The section expands interaction mechanisms underlying Sections 3.1.2 and 3.2.Source: §A.1 · p. 11
  • These mechanisms associate communication with task responsibilities.Source: §A.1 · p. 11
  • They connect emerging coordination needs to the shared execution state.Source: §A.1 · p. 11

A.1.1 Asynchronous Communication

AutoSwarm uses persistent, role-addressed messages tied to task units and their evidence. Asynchronous delivery supports independent work while explicit response obligations track pending exchanges and their resolution.

A.1.1 Asynchronous Communication

  • Persistent, role-addressed messages link each exchange to its sender, recipient, task unit or parent objective, intent, and content.Messages also retain timing, response requirements, links to earlier requests, and evidence or artifact references.Source: §A.1.1 · p. 11
  • Asynchronous delivery lets senders continue independent work, while a request can require a response before a specified decision proceeds.Source: §A.1.1 · p. 11
  • Explicit response obligations record the pending question, recipient, waiting interval, and continuation or supervisory pathway; replies link back to the original request.Acknowledging receipt is distinct from satisfying the obligation, which requires a linked reply.Source: §A.1.1 · p. 11

A.1.2 Role Activation and Context

Role activation follows continuing responsibilities, while each action receives context tied to its specific objective and obligation.

A.1.2 Role Activation and Context

  • Action context combines the current objective, expected contribution, available results, correspondence, and prior feedback so the agent addresses a specific obligation.Informational updates enrich context; requests, required reviews, and unresolved decisions create pending response or supervisory actions.Source: §A.1.2 · p. 11
  • A new actionable exchange can reactivate a role after its prior assignment ends, while an occupied agent receives pending work in a later execution context.Separate tracking of role activation and contribution lifecycle, plus interaction-history checks, guards against treating completed contributions as unfinished or activating redundantly.Source: §A.1.2 · p. 11

A.1.3 Waiting and Supervisory Decisions

Waiting suspends execution only for required replies, while timeout handling preserves unresolved requirements and routes supervisory decisions without accepting missing results.

A.1.3 Waiting and Supervisory Decisions

  • Required replies suspend the requesting agent, but unrelated execution, assessment, and integration remain eligible to proceed.Before waiting, the mechanism checks that the respondent can reply without depending on completion of the requester’s contribution, guarding against circular waits.Source: §A.1.3 · p. 11
  • Matched replies resolve the corresponding obligations, while waiting records retain the request, respondent, unresolved requirements, and continuation context.On timeout, the unresolved question and elapsed context persist; a continuation does not treat a missing required result as accepted.Source: §A.1.3 · p. 11
  • Timeouts direct the original objective, requested information, intended respondent, and available evidence to the responsible agent’s supervisor for a next-step decision.The supervisor may seek clarification, assign replacement work, or revise an obsolete dependency, then update the affected unit’s pending action and inputs.Source: §A.1.3 · pp. 11–12

A.1.4 Review and Dependency Updates

This block describes review and dependency controls, prior work on LLM and multi-agent systems, collaboration configurations, and selected execution trajectories.

A.1.4 Review and Dependency Updates

  • Review links each output to its parent requirement and acceptance conditions; feedback can trigger revision, while satisfied dependencies alone release downstream execution.Failed or cancelled units provide no accepted ordinary input; supervisors may arrange replacements, revise obsolete dependencies, or close blocked branches.Source: §A.1.4 · p. 12

A.2.1 LLM Agents

  • LLM-agent work spans interleaved reasoning and action, feedback-based reflection, reusable workflow memories, and environment-grounded software or web actions.The cited work includes Yao et al. (2023), Shinn et al. (2023), and Yang et al. (2024).Source: §A.2.1 · p. 12

A.2.2 Multi-Agent Systems

  • Prior multi-agent systems use role-conditioned dialogue, standardized workflows, adaptive recruitment, graph-based communication, and automated workflow design.Misaligned responsibilities and insufficiently verified handoffs remain concerns motivating AutoSwarm’s links between contribution requirements and dependency-controlled execution.Source: §A.2.2 · p. 12

A.3.1 Collaboration Configurations

  • Plancraft comparisons cover four collaboration procedures and two mechanism variants: without CS removes contribution standards, while without SR removes review and corrective feedback.Each variant used the same benchmark instructions and success criteria and was evaluated in one complete run on all 117 problems.Source: §A.3.1 · pp. 12–13

A.4 Collaboration Case Study (RQ5)

  • In the piston and buffer-pool cases, distinct contribution ownership supplied reusable evidence and covered required functionality that the single-agent runs left confused or incomplete.The buffer-pool contributions were independently tested during integration; the single agent left the required LRU-K replacer as an empty stub.Source: §A.4 · p. 13
  • The sticky-piston case illustrates prerequisite-aware ordering: AutoSwarm used recipe information before acting, preserving a scarce log for the feasible plan.The single agent instead converted the only log to charcoal and declared the goal infeasible.Source: §A.4 · p. 13
  • Focused tests and supervisory confirmation corrected a duplicate-binding defect, while explicit completion checks prevented stopping before the target entered inventory.The goldenchestplate single-agent run stopped with the target in the crafting output slot.Source: §A.4 · p. 13

Related papers

Loading 2610.33048v1…