SwarmRouter is the universal entry point for multi-agent orchestration in Swarms. Instead of importing and configuring different swarm classes, you keep the same agents list and just change the swarm_type to switch between Sequential, Concurrent, AgentRearrange, MixtureOfAgents, HierarchicalSwarm, and more.
This page walks through one runnable example per common swarm_type, plus a strategy-comparison pattern and a production-ready configuration.
How SwarmRouter Works
- Single interface — one class, one
run(task)method, regardless of which architecture you select. - Strategy via parameter — set
swarm_type="SequentialWorkflow","ConcurrentWorkflow","MixtureOfAgents", etc. - Per-architecture options — some swarm types accept extra kwargs (e.g.
rearrange_flow,aggregator_agent). - Same agents everywhere — define your
Agentinstances once and reuse them across architectures.
Basic Example: Switching Architectures Without Rewriting Code
Define your agents once, then run the same task through three different architectures by changing onlyswarm_type.
Example: Sequential Workflow via SwarmRouter
Each agent’s output flows into the next. Ideal for ordered pipelines like research → write → edit.Example: Concurrent Workflow via SwarmRouter
All agents see the same task and run in parallel. Use for independent perspectives, redundancy, or fan-out queries.Example: AgentRearrange via SwarmRouter
Mix sequential and parallel execution in one flow using the DSL.-> chains agents; , runs them in parallel.
Example: Mixture of Agents via SwarmRouter
Workers respond independently, then an aggregator agent synthesizes a final answer. Pass a dedicatedaggregator_agent.
Example: Hierarchical Swarm via SwarmRouter
A director agent decomposes the task and delegates subtasks to worker agents.Pattern: Strategy Comparison
Run the same task through multiple architectures and compare outputs. Useful when you don’t know which architecture suits your task best.Pattern: Dynamic Architecture Selection
Pick the architecture at runtime based on task characteristics. This is a common production pattern when one server handles tasks of varying complexity.Pattern: Production-Ready Configuration
Combinerules, autosave, and explicit output_type for a deployable router. The router will save its config, state, and metadata after every run.
Batch and Concurrent Execution
SwarmRouter exposes the same task-execution helpers regardless of which architecture is selected.
Choosing a swarm_type
| Situation | swarm_type |
|---|---|
| Linear A → B → C pipeline | "SequentialWorkflow" |
| Same task, many agents at once | "ConcurrentWorkflow" |
| Mix of sequential + parallel via DSL | "AgentRearrange" |
| Multiple models, one synthesized answer | "MixtureOfAgents" |
| Director delegates to specialists | "HierarchicalSwarm" |
| Deep multi-loop analysis | "HeavySwarm" |
| Round-table discussion / brainstorming | "GroupChat" |
| Discrete consensus answer | "MajorityVoting" |
| Adversarial debate with a judge | "DebateWithJudge" |
| Council deliberates, judge rules | "CouncilAsAJudge" |
| Round-robin task distribution | "RoundRobin" |
| Batched grid execution | "BatchedGridWorkflow" |
| LLM-driven council decisions | "LLMCouncil" |
| Task-aware routing to one agent | "MultiAgentRouter" |
What to Avoid
- Don’t add the aggregator to
agentswhen usingMixtureOfAgents— pass it via the dedicatedaggregator_agentkwarg so it isn’t also run as a worker. - Don’t omit
rearrange_flowwhen usingAgentRearrange— it is required and validated at construction time. - Don’t reuse a SwarmRouter across unrelated tasks expecting clean state — construct a new one per logical job, or reset its internal conversation between runs.