Agent Swarm Execution Mechanics

Agent Swarm uses multiple Agents collaborating to complete complex tasks. It suits work that can be split up, needs parallel exploration, or requires independent review — but it brings higher cost, latency, and coordination complexity.

Basic Flow

User task
  ↓
Orchestrator receives and validates
  ↓
Seed / initial analysis
  ↓
Proposal / sub-task plan
  ↓
Agent assignment and parallel execution
  ↓
Review / result review
  ↓
Retry or Reopen
  ↓
Aggregation
  ↓
Patch, test evidence, and final report

Key Stages

Seed

The Seed stage establishes an initial understanding of the task, including the goal, scope, repository structure, constraints, acceptance criteria, and potential risks. Seed is not the final plan — it's the shared context for the decomposition that follows.

Proposal

Proposal breaks the task into sub-tasks that can be executed or reviewed independently. A good decomposition reduces file conflicts, clarifies inputs and outputs, and assigns acceptance criteria to each sub-task.

Agent Execution

Each Agent executes its task according to its assigned role, model, tools, workspace, and budget. Whether different Agents share a workspace, context, and secrets depends on the specific deployment configuration.

Review

Review should examine the actual changes, test evidence, task scope, and potential regressions — not just evaluate a natural-language summary. A review can accept the result, require a retry, reopen the task, or escalate to manual handling.

Aggregation

Aggregation merges the valid output of multiple Agents into a final result. The aggregator should handle duplicate conclusions, conflicting changes, failed sub-tasks, and incomplete evidence.

The Role of the Team Lead

The Team Lead is responsible for coordination and decisions, and should not just forward other Agents' summaries. Typical responsibilities include:

• Judging whether a task needs further decomposition;
• Handling conflicts between Agents;
• Deciding whether to retry or reopen;
• Checking whether the final workspace and the summary are consistent;
• Flagging risks that cannot be verified;
• Requesting user approval when needed.

A Team Lead's approval does not mean the code has passed independent CI or manual review.

State Meanings

The exact state names may change across versions — rely on the current UI and API.

Retry & Reopen

Retry usually targets a temporary failure of the same sub-task, such as a model timeout, a tool failure, or a structured-output parsing failure. Reopen usually means the task was once considered complete, but the result was later found incomplete, tests failed, or acceptance did not pass.

Unlimited retries amplify cost and repeat the same errors. The system should set a maximum count, a backoff strategy, and failure classification.

Workspaces & Conflicts

Multiple Agents may use a shared workspace, separate branches, or separate Sandboxes. Whichever approach is used, make clear:

• When changes become visible to other Agents;
• How file conflicts are detected;
• Who holds the final merge authority;
• Whether a failed Agent's changes are kept;
• Which final state the tests run against.

Context & Memory

An Agent should not receive the entire history by default. To reduce context cost, the system may pass only the task summary, relevant files, tool results, and shared state. When a summary drops key constraints, an Agent may repeat work or drift from the goal.

Cost & Budget

The total cost of a Swarm is usually determined jointly by:

• The number of Agents;
• The model each Agent uses;
• Context length and output length;
• The number of tool calls;
• The number of retries / reopens;
• Sandbox or VM runtime.

Set limits on model, concurrency, rounds, tokens, time, and resources before submitting a task.

Completion Criteria

A Swarm task cannot be considered successful just because all Agents stopped running. The final result should include at least:

• A complete list of changed files;
• Conflict-resolution outcomes;
• The tests actually run and their exit codes;
• Unfinished or failed sub-tasks;
• A record of manual intervention;
• A final applicable patch or an explicit no-change conclusion.