Skip to main content

Overview

The swarm workflow is triggered by setting force_swarm: true in the task context. It uses the same POST /api/v1/tasks endpoint as all other workflows — no separate endpoint is needed. Swarm mode decomposes your query into subtasks, spawns persistent agents that work in parallel with inter-agent messaging, and synthesizes results into a unified response.

Submitting a Swarm Task

Endpoint

Request Body

Swarm-Specific Context Parameters

All standard task parameters (session_id, mode, model_tier, model_override, provider_override) work with swarm tasks.
The force_swarm flag must be set inside the context object, not as a top-level parameter. The swarm must also be enabled in the server configuration (workflows.swarm.enabled: true in features.yaml).

Example: Basic Swarm Task

Response

Headers:
  • X-Workflow-ID: Temporal workflow identifier (same as task_id)
  • X-Session-ID: Session identifier

Submit + Stream

Use the combined endpoint to submit and get a stream URL in one call:
Response (201 Created):

Monitoring Swarm Progress

SSE Event Stream

Swarm-Specific Events

Example SSE Output

Task Status Response

Swarm Metadata

When a swarm workflow completes, the status response includes swarm-specific metadata:

Metadata Fields

Server Configuration

Swarm parameters are configured in config/features.yaml under workflows.swarm:

Error Handling and Fallback

Partial Failure

If some agents fail but at least one succeeds, the swarm workflow still produces a result using the successful agents’ outputs. If all agents fail, the response includes an error:

Automatic Fallback

If the entire swarm workflow fails (decomposition error, all agents fail, etc.), Shannon automatically falls back to standard workflow routing (DAG or Supervisor). The force_swarm flag is removed from context to prevent recursive failures.

Submit Task

POST /api/v1/tasks (full reference)

Get Status

GET /api/v1/tasks/

Stream Events

SSE event streaming

Cancel Task

POST /api/v1/tasks//cancel