LLM Orchestration Patterns

Compound Actions give you a handful of building blocks: parallel, for, switch, return, and LLM Actions. Most tasks only need one of them. This catalog covers what to do when a single one isn’t enough: recurring ways to combine a few of them into a reliable workflow.

These are reference architectures, not step-by-step tutorials. The YAML in each pattern uses pseudocode that is realistic enough to teach the shape. You will need to adapt it to your actual systems and validate the behavior before you rely on it.

Before you reach for a pattern

Each pattern below combines a few building blocks to solve a specific problem, and each page also tells you when a single block would have been enough. So before reaching for a pattern, check whether one block already solves your problem on its own:

parallel fans out to several systems and hands back their raw results side by side.
A single LLM Action classifies, extracts, summarizes, or generates in one call.
switch (inside a Compound Action) or a Decision Policy (inside a Conversational Process) routes by a fixed rule, with no LLM involved. Reach for switch when the routing happens entirely in the backend; reach for a Decision Policy when the route changes what the user is asked next.
DSL in action mappings or return.output_mapper already combines, filters, and reshapes data when the transformation follows fixed rules. Reach for an LLM Action instead when the transformation needs judgment.

If one of these already covers your case, use it and stop there. Only reach for a pattern below when the problem genuinely needs more than one block working together. Two existing guides can help you make that call:

Decision Frameworks

Six decision trees: action type, CP vs Compound Action, slot type, LLM vs DSL, and more.

Compound Actions vs. Conversational Processes

When routing and orchestration belong in a Compound Action versus a Conversational Process.

Choose a pattern

Pattern	Problem it solves	What it’s built from	When not to use it
Fan out and synthesize	You need one coherent answer that draws on several independent systems at once.	`parallel` → LLM Action → `return`	For raw results side by side, use `parallel` → `return`; to merge or calculate them, use DSL in `return.output_mapper`.
Categorize and route	Too many labels for one reliable classification, so classify broadly first (IT, HR), then again within that category (VPN, Laptop).	LLM Action → route on the result (`switch` in a Compound Action, or a Decision Policy in a Conversational Process) → second LLM Action	One flat classification is accurate enough, or the top-level category already comes from a known field or rule.

Combine patterns

These patterns aren’t limited to use on their own; you can chain them into bigger workflows:

A fan out and synthesize flow can feed its summary into categorize and route to file the result correctly.

Whenever you chain patterns, keep each stage doing one job, name every output_key clearly, and define what gets returned at the boundary between stages.

The patterns

Fan out and synthesize

Query several systems in parallel, then use an LLM Action to turn their combined results into one answer. To just merge or calculate the results, use DSL in return instead.

Categorize and route

For a large label hierarchy, classify the top-level category first, then choose one of its subcategories.