Overview
The swarm workflow is triggered by settingforce_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
X-Workflow-ID: Temporal workflow identifier (same astask_id)X-Session-ID: Session identifier
Submit + Stream
Use the combined endpoint to submit and get a stream URL in one call: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 inconfig/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). Theforce_swarm flag is removed from context to prevent recursive failures.
Related Endpoints
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