Skip to content

PATTERN Cited by 2 sources

Multi-agent supervisor routing

The pattern

A supervisor agent sits at the front of a multi-agent system, classifies an incoming user query's intent and complexity, and routes the query to one of several specialist sub-agents that each handle a structurally-different answer-shape. The sub-agents are alternatives, not collaborators — exactly one (or sometimes a small fan-out) is selected per query.

The canonical wiki instance is Virtue Foundation's VF Agent — a prototype natural-language-query layer on the VF Match Foundational Data Refresh:

        User free-text query
             │
             ▼
    ┌──────────────────────────────┐
    │ Medical Specialty Extractor  │  ← input normalisation
    │ free-text → standardized     │
    │ medical terminology          │
    └──────────────────────────────┘
             │
             ▼
    ┌──────────────────────────────┐
    │ Multi-Agent Supervisor       │  ← classify + route
    │ (intent + complexity)        │
    └──────────────────────────────┘
        │              │
        ▼              ▼
  ┌───────────┐  ┌───────────────┐
  │ Vector    │  │ Genie Agent    │
  │ Search    │  │ (analytical    │
  │ Agent     │  │  / structured) │
  │ (semantic │  │                │
  │  search)  │  │                │
  └───────────┘  └───────────────┘

(Source: sources/2026-05-20-databricks-virtue-foundation-medical-volunteers-72-countries)

Why route, not collaborate

Vector search and structured-analytical query are structurally different answer-shapes:

  • Vector search: best-similarity-first retrieval — semantic proximity over an embedding space; the answer is a ranked result list. Optimal for find-me-something-like-this queries: "find hospitals in Mongolia with orthopedic specialty".
  • Genie / SQL analytics: aggregate / group-by / filter against structured columns; the answer is a number, a chart, or a row set. Optimal for count / sum / breakdown queries: "how many facilities in Ghana have CT scanners, broken down by region".

A single LLM trying to do both ends up either bad at retrieval (treating everything as analytics) or bad at analytics (treating everything as similarity search). Routing per query preserves both modes' strengths.

  • patterns/orchestrated-multi-agent-entity-resolution — Claroty's three-role multi-agent pattern. The roles (NLP / Reasoning / HITL) collaborate on one canonicalisation task; here the sub-agents are alternatives selected per query. Different shape entirely.
  • patterns/specialized-agent-decomposition — broader per-domain agents shape (DB / traffic / etc.). Multi-agent supervisor routing is a specialisation: one supervisor at the front, one of N specialists selected.
  • patterns/llm-per-subagent-with-optimized-prompts — Genie's Multi-LLM design: per-sub-agent LLM assignment with optimised prompts. The sub-agents in Multi-LLM are pipeline-stage agents (planner / search / code-gen / judge); in supervisor routing they are alternative-answer-shape agents.
  • concepts/multi-llm-sub-agent-routing — broader concept of routing across sub-agents; supervisor routing is the one-supervisor-classifies-and-routes shape specifically.

Required components

  1. An input normaliser (optional but common). The Medical Specialty Extractor in VF Agent canonicalises this role: convert user free-text into a standardised representation (medical terminology, query type, structured intent) that the supervisor can route reliably.
  2. A supervisor classifier. An LLM (or trained classifier) that takes the normalised input and emits a routing decision. Inputs typically: intent type, query complexity, expected answer shape. Output: which sub-agent to invoke.
  3. A set of specialist sub-agents. Each handles a structurally-different answer shape. They share the underlying data substrate but expose different query interfaces.
  4. A routing graph substrate. LangGraph is the canonical instance — the supervisor is a node, the sub-agents are nodes, the routing decision is an edge condition.

When applies / doesn't fit

Applies when

  • The user query domain has clearly distinct answer shapes (search vs analytics; conversational vs transactional; etc.).
  • Each answer shape has a substrate optimised for it (vector store for semantic search; SQL warehouse for analytics).
  • Per-query routing decisions can be made cheaply (a small classifier LLM call).
  • Mixing the modes in one prompt-pool degrades both modes.

Doesn't fit when

  • The query domain is uniform (one answer shape works for everything).
  • Cross-mode synthesis is required (the user wants both similarity search and aggregation in one answer).
  • The classifier is unreliable enough that misrouting dominates the per-query value.

Failure modes

  • Supervisor misclassification. When the supervisor routes a similarity-search query to Genie or vice versa, UX degrades silently — the user sees a wrong-shape answer with no signal of misrouting. Mitigation: confidence-scored routing with fallback to try both, return best; explicit query-shape hints in the UI.
  • Single-supervisor bottleneck. Every query pays the supervisor LLM call. Mitigation: pre-compute embeddings of routing examples; use small-model classifier instead of large LLM for routing.
  • Sub-agent capability drift. When a sub-agent gains new capabilities, the supervisor's routing rules become outdated unless retrained. Mitigation: data-driven routing (the supervisor learns from observed routing-then-success).
  • Cross-mode queries dropped. Queries that genuinely need both vector-search and analytical-query ("find similar hospitals to X, then count their specialties") get routed to one or the other. Mitigation: a third "compound" sub-agent that orchestrates the two; or fan-out to both with LLM synthesis at the end.
  • Specialty-extractor errors propagate. Non-standard medical terminology that the extractor maps wrong sends the wrong query to both supervisor and downstream sub-agent. Mitigation: expose the extractor's normalisation to the user ("did you mean X?").

Composes with

Seen in

  • sources/2026-05-22-databricks-how-world-bank-group-uses-databricks-to-eradicate-poverty-through-shared-knowledge — fan-out generalisation, named explicitly in the canonical source for patterns/intent-domain-decomposer-agentic-router. World Bank Group's Knowledge 360 / Data 360 build is the wiki's first instance where the routing layer is explicitly set-output + decomposer + fan-out rather than alternative-selection. The post's three named classifiers (intent / domain / decomposer) are a strict superset of the single-supervisor shape this page documents — the domain classifier emits a set of sub-agents, and the query decomposer splits a multi-part question across them. Cross-domain example named verbatim: "what is my commitment in India and what are my actions" fans out to two per-domain Genie instances. The visualisation agent runs as a peer of the per-domain Genie sub-agents and the RAG agent rather than buried inside any one of them. The World-Bank shape is the canonical instance of the fan-out-and-aggregate pattern; this page's single-supervisor alternative-selection shape is the simpler sibling. Caveat: the three classifiers' model choice and decomposition strategy are not disclosed.

  • sources/2026-05-20-databricks-virtue-foundation-medical-volunteers-72-countries — canonical wiki source. Virtue Foundation's VF Agent prototype: four named agents (Medical Specialty Extractor + Multi-Agent Supervisor + Vector Search Agent + Genie Agent) on LangGraph, where the supervisor classifies normalised query intent + complexity and routes to either the Vector Search sub-agent or the Genie sub-agent. Caveat: prototype, not production.

Last updated · 542 distilled / 1,571 read