AdvisorSwarm implements the advisor strategy — a cheaper executor model drives the task end-to-end while a more capable advisor model is consulted on-demand between executor turns for strategic guidance. Both agents read from and write to a shared conversation, so the executor sees the advisor’s notes on the next turn.
This is well-suited to tasks where most of the per-turn work is cheap but a few pivotal decisions benefit from a stronger model — code review, multi-step debugging, research planning, document refinement.
How Advisor Swarm Works
- The user task is added to a shared
Conversation. - Before each executor turn, if
advisor_uses < max_advisor_uses, the advisor reads the full conversation and writes strategic guidance back to it. - The executor reads the same conversation — task, any prior output, and any advisor guidance — and produces its turn output.
- Steps 2–3 repeat for
max_loopsexecutor turns. - The formatted conversation history is returned per
output_type.
Key Characteristics
- Executor-driven loop: the executor runs every turn; the advisor is optional.
- Budgeted advisor calls:
max_advisor_usescaps how often the expensive model is invoked. - Shared context: both agents see the same conversation, so guidance compounds across turns.
- Provider-agnostic: any LiteLLM-supported model works for either role.
- Tools on executor only: the executor can be a pre-configured
Agentwith tools or MCP; the advisor stays tool-free.
Basic Example: Code Review
A natural fit for the executor/advisor split — the executor does the line-by-line review work, the advisor sets priorities and catches what the executor misses.What happens each turn
Withmax_loops=3 and max_advisor_uses=2, the run looks like this:
The advisor’s “look here next” notes carry forward in the shared conversation, so the executor’s later turns are guided by both its own prior output and the strategic direction the advisor set earlier.
Custom Executor with Tools
Pass a pre-configuredAgent as executor_agent to give it tools, MCP connections, or any other agent setting. The advisor stays tool-free so its role remains strategic.
Tuning the Advisor Budget
max_advisor_uses and max_loops together control cost vs. quality:
If a task is well-scoped and the executor model handles it confidently,
max_advisor_uses=0 is fine — you just get a cheap-model run with the AdvisorSwarm plumbing in place for when you do want guidance.
Mixing Providers
Provider-agnostic — the executor and advisor don’t need to come from the same vendor.When to Use AdvisorSwarm
- Cost-sensitive workloads where most turns are routine but a few decisions matter
- Long-running tasks where periodic strategic re-checks add value
- Tasks with tools or MCP where you want a smaller tool-using executor plus a tool-free strategic overseer
- Domains where direction matters more than throughput — code review, research planning, document polish
When NOT to Use AdvisorSwarm
- Single-shot prompts where one model call is enough — use a bare
Agent - Pure parallel workloads with no inter-turn strategy — use
ConcurrentWorkfloworMixtureOfAgents - Strict sequential pipelines with fixed roles per stage — use
SequentialWorkflow - All turns equally critical — just use the strong model directly
Related Architectures
- MixtureOfAgents: Parallel experts with aggregation — peers, not executor/advisor
- HierarchicalSwarm: Director-worker with task distribution — many workers, not one paired advisor
- SequentialWorkflow: Fixed pipeline of agents — no on-demand consultation