Skip to main content
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

  1. The user task is added to a shared Conversation.
  2. Before each executor turn, if advisor_uses < max_advisor_uses, the advisor reads the full conversation and writes strategic guidance back to it.
  3. The executor reads the same conversation — task, any prior output, and any advisor guidance — and produces its turn output.
  4. Steps 2–3 repeat for max_loops executor turns.
  5. The formatted conversation history is returned per output_type.
The advisor never calls tools and never produces user-facing output — it only writes guidance for the executor to consume.

Key Characteristics

  • Executor-driven loop: the executor runs every turn; the advisor is optional.
  • Budgeted advisor calls: max_advisor_uses caps 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 Agent with 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

With max_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-configured Agent as executor_agent to give it tools, MCP connections, or any other agent setting. The advisor stays tool-free so its role remains strategic.
The advisor sets the audit strategy (“start with the login flow — that’s where the highest-impact bugs live”); the executor uses its tools to actually fetch and read the code.

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 ConcurrentWorkflow or MixtureOfAgents
  • Strict sequential pipelines with fixed roles per stage — use SequentialWorkflow
  • All turns equally critical — just use the strong model directly
  • 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

Learn More