Skip to content

PATTERN Cited by 1 source

Intent-domain-decomposer agentic router

The pattern

A three-classifier agentic layer sits in front of a fleet of specialist sub-agents (typically: multiple per-domain Genie instances + a RAG agent over an unstructured-document index, optionally a visualisation agent), classifies and decomposes the incoming query, and fans out to one or more sub-agents in parallel. Sub-agent results are assembled into a single response.

The three classifiers are explicitly:

  1. Intent classifier — what is being asked (analytical structured-data query / document-search / visualisation-change / compound).
  2. Domain classifier — which sub-agent(s) to invoke. Output is a set, not a single choice — a query can fan out to multiple per-domain Genies plus the RAG agent.
  3. Query decomposer — split a multi-part question into per-domain sub-queries, each routable to a single sub-agent.

The shape is named in the canonical wiki source's verbatim disclosure:

"The World Bank Group built a single interface backed by an intent classifier, a domain classifier and a query decomposer. When a question comes in, the intent classifier identifies what's being asked, the domain classifier determines which agent or agents need to be called, and the query decomposer breaks complex multi-part questions into components and routes each to the right place. Results are assembled and returned as a single response." (Source: World Bank Group on Databricks)

        User free-text question
                  │
                  ▼
        ┌─────────────────────┐
        │ Intent Classifier   │  what shape of answer is needed
        └─────────────────────┘
                  │
                  ▼
        ┌─────────────────────┐
        │ Domain Classifier   │  set of sub-agents to invoke
        └─────────────────────┘
                  │
                  ▼
        ┌─────────────────────┐
        │ Query Decomposer    │  multi-part → per-domain sub-queries
        └─────────────────────┘
            │      │      │
            ▼      ▼      ▼
   ┌────────────┐ ┌─────────┐ ┌────────────┐
   │ Genie A    │ │ Genie B │ │ RAG Agent  │
   │ (domain A) │ │(domain B)│ │ (vector    │
   └────────────┘ └─────────┘ │  search)   │
                              └────────────┘
            │      │      │
            ▼      ▼      ▼
        ┌─────────────────────┐
        │ Result Assembly     │
        └─────────────────────┘
                  │
                  ▼
        ┌─────────────────────┐
        │ Visualisation Agent │  (optional re-render tier)
        └─────────────────────┘
                  │
                  ▼
              Response

The post's self-description: "It's not unlike traditional multi-tier web design, with front end, application layer, business logic and database, updated for an AI context."

Why this shape (vs single-supervisor alternative-selection)

The pattern's existence is forced by two structural constraints present in many real multi-domain knowledge platforms:

  1. Per-Genie / per-metrics-layer pinning. Each Genie instance is built against a specific metrics layer / data domain (see the World Bank case + patterns/metrics-layer-for-deterministic-genie-answers). A question that legitimately spans two domains ("what is my commitment in India and what are my actions") cannot be served by a single Genie — different domains have different metrics layers, different schemas, different business semantics.
  2. Cross-domain queries are the hard ones. Single-domain queries are easier to get right; cross-domain queries are what end users actually ask when they reach for a unified knowledge interface. The pattern is specifically designed for the cross-domain case.

The single-supervisor patterns/multi-agent-supervisor-routing shape (Virtue Foundation's VF Agent: supervisor → vector-search OR Genie) is the alternative-selection generalisation. This pattern is the fan-out-and-aggregate generalisation, with explicit decomposition as the third classifier stage.

  • patterns/multi-agent-supervisor-routing — single supervisor classifies + routes to one of N alternatives (alternative-selection). This pattern is the fan-out generalisation: the domain classifier emits a set and the query decomposer enables splitting one user question across multiple sub-agents.
  • patterns/orchestrated-multi-agent-entity-resolution — Claroty's NLP / Reasoning / HITL roles collaborate on one entity-resolution task. This pattern's sub-agents are per-domain alternatives or fan-out targets, not collaborators on one task.
  • patterns/specialized-agent-decomposition — broader per-domain agents shape; this pattern is the classified- routed-and-decomposed specialisation with three explicit classifier stages.
  • patterns/llm-per-subagent-with-optimized-prompts — the Genie-internal Multi-LLM design (per-pipeline-stage agents: planner / search / code-gen / judge). This pattern's sub-agents are per-domain answer-shape agents, not pipeline-stage agents. The two compose: each per-domain Genie sub-agent could itself use the LLM-per-sub-agent design internally.
  • concepts/multi-llm-sub-agent-routing — broader concept family; this pattern is the three-classifier-with-fan-out shape specifically.

Required components

  1. An intent classifier — typically an LLM (or trained classifier) emitting a small set of intent labels (analytical / document-retrieval / visualisation-change / compound). Inputs: raw user text. Outputs: intent label.
  2. A domain classifier — emits a set of sub-agent IDs given the user query + intent. May be LLM-based (zero-shot over a domain-taxonomy schema) or trained / hand-rule-based. The set-output shape is what enables fan-out.
  3. A query decomposer — splits multi-part queries into per-domain sub-queries. May be LLM-based (decomposition prompt) or grammar-based for structured query languages.
  4. A fleet of specialist sub-agents — typically multiple per-domain Genie instances (each pinned to its domain's metrics layer), a RAG agent over an unstructured-document index (UC Volumes + Vector Search in the canonical case), and optionally a visualisation agent.
  5. A result-assembly stage — re-stitches sub-agent outputs into a coherent response. The mechanism is not disclosed in the canonical source (LLM-based summarisation? template- based concatenation? citation-preserving merge?).
  6. A routing-graph substrate — LangGraph is the canonical Databricks-ecosystem instance; not explicitly named in the World Bank post but consistent with sibling Databricks deployments.
  7. (Optional) A visualisation tier — separate from the query tier; re-renders chart-type changes without re-running the underlying query.
  8. (Optional) A control-plane gateway — Databricks AI Gateway in the canonical case; gates per-agent identity, cost, and security as agent count grows.

When applies / doesn't fit

Applies when

  • The data substrate is multi-domain, with each domain having its own metrics layer / schema / business semantics.
  • Users routinely ask cross-domain questions that legitimately span two or more domains.
  • A single-Genie / single-RAG approach has been tried and fails (per-domain Genie pinning makes cross-domain queries produce incomplete or wrong answers).
  • Determinism for structured-data answers is required (each per-domain Genie composes with patterns/metrics-layer-for-deterministic-genie-answers).
  • The agent fleet is large enough that centralised access / cost / security control becomes operationally meaningful (see AI Gateway).

Doesn't fit when

  • Single-domain platform — one Genie + optional RAG agent suffices; the three-classifier overhead is not justified.
  • Alternative-selection routing is sufficient — if cross- domain queries don't exist or are rare, the simpler patterns/multi-agent-supervisor-routing (one supervisor → one of N) is the right shape.
  • Latency-critical UI — three sequential classifier stages add cumulative LLM-call latency; for end-user-facing conversational UIs this can dominate. Mitigation: small-model classifiers; caching of intent / domain / decomposition decisions for common query patterns.
  • The domain taxonomy is fluid — if domain boundaries change frequently, the classifier and decomposer require continuous re-training / re-prompting. Stable domain taxonomies are a precondition.
  • Result-assembly semantics aren't well-defined — when sub-agent outputs conflict or don't compose, the assembly step becomes the system's failure mode. Without a clear resolution model, the pattern surfaces internal contradictions to the user instead of resolving them.

Failure modes

  • Three sequential classifier stages compound latency. Each classifier is a separate LLM call; a four-LLM-call sequence (intent → domain → decompose → per-sub-agent execution) is the floor for a single user question. Mitigation: pre-compute intent / domain / decomposition for common query patterns; use small-model classifiers; parallelise where possible (intent + domain can run concurrently if the intent label doesn't constrain the domain set).
  • Domain classifier misclassification fans out to wrong agents. The domain classifier's set-output shape means a misclassification can simultaneously omit the correct domain and include an irrelevant one. Mitigation: confidence-scored domain selection with conservative thresholds; user-visible "queried domains: X, Y" feedback.
  • Decomposer produces incoherent splits. A multi-part question split inappropriately can yield sub-queries each of which is individually answerable but jointly incoherent (e.g., decomposing "compare commitment in India versus Pakistan" into "commitment in India" + "commitment in Pakistan" drops the "compare" relation). Mitigation: decomposer-output validation; preserve the relational operator in the result-assembly prompt.
  • Result-assembly hallucination. The assembly LLM may hallucinate connective tissue between sub-agent outputs that the data does not support. Mitigation: structured result- assembly templates with explicit citation back to each sub-agent's response.
  • Per-Genie cross-domain answer drift. When two Genies serve adjacent domains and produce subtly inconsistent numbers for shared dimensions (e.g. different definitions of "India" across two domain schemas), the assembled response silently surfaces the inconsistency. Mitigation: shared dimension definitions across per-domain metrics layers; UC governed-tags as the disambiguation primitive.
  • Visualisation-agent re-render reveals stale data. If the visualisation tier caches the underlying query result and the data has changed since, chart-type re-render shows stale data with new visual presentation. Mitigation: TTL on cached query results; user-visible "data as of X" indicator.
  • Sub-agent timeouts in a fan-out. When the domain classifier emits a set, partial-failure semantics matter. If one of N sub-agents times out, does the assembly stage return a partial answer or fail the whole query? Disclosure-gap in the canonical source.

Composes with

  • patterns/metrics-layer-for-deterministic-genie-answers — each per-domain Genie sub-agent is pinned to its domain's metrics layer, which is what makes the per-domain pinning necessary in the first place. The two patterns are practically inseparable for any deployment with financial / operational reporting requirements.
  • patterns/llm-per-subagent-with-optimized-prompts — each per-domain Genie sub-agent can internally use the LLM-per-pipeline-stage design (planner / search / code-gen / judge) for its own per-domain tasks.
  • Unity AI Gateway — the centralised gateway gates the fan-out's per-agent identity / cost / security; without it, observability and cost control scale linearly with sub-agent count.
  • Unity Catalog — the governance substrate; each per-domain sub-agent inherits UC-row-level security from the user's identity passed through the gateway.

Seen in

What we don't yet know

The canonical source is mechanism-light. Open questions for any future ingest on this pattern:

  • Are the three classifiers separate LLM calls, or is the three-stage flow collapsed into a single multi-step prompt?
  • What model class? Frontier LLM (high accuracy / high latency) or small-model classifier (low latency / lower accuracy)?
  • What's the decomposition-strategy: rule-based, LLM-based, grammar-based?
  • How does result assembly resolve contradictions across per-domain sub-agent outputs?
  • What's the partial-failure / timeout / retry semantics in the fan-out?
  • Where does the user-visible "queried domains" feedback live in the UI (if it exists)?

A future engineering retrospective from any of WBG, Databricks internal, or another customer with a similar multi-domain Genie deployment would close these gaps.

Last updated · 542 distilled / 1,571 read