> ## Documentation Index
> Fetch the complete documentation index at: https://docs.experio.cloud/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent Flows Cookbook
> What you can build with Agent Flows — validated example flows, the patterns behind them, and how to build each one in the admin canvas.
Agent Flows let you compose **typed nodes** into a graph that runs as a real LangGraph agent: pull from the knowledge graph, research the web, call MCP tools, classify and route, fan out work in parallel, pause for human review, and generate documents — then let the chat agent launch the whole thing as a background sub-agent, or run it from the canvas.
This cookbook is a set of **example flows that have been run end-to-end and validated**, the reusable patterns behind them, and step-by-step instructions for building each in the admin canvas (**AI & Agents → Agent Flows**).
Every example below was built, published, run, and checked against its real output (knowledge-graph rows, live web results, generated `.docx` files, MCP calls). Where a flow uses a question, point it at data you actually have — the demo knowledge graph contains `Project` and `Deliverable` data, so "list our projects" / "what deliverables exist" return real results.
Looking for what a specific block does, its settings, and which one to pick? See the [Flow Blocks Reference](/admin-guide/agent-flows-blocks) — a plain-language guide to every node type, with decision helpers (classify vs extract vs generate, Map vs Loop, KG Query vs research agents, and more).
## The node palette at a glance
| Category | Node | What it does |
| ----------- | ------------------------ | ----------------------------------------------------------------------------------------------------- |
| **Control** | Start / End | Entry and exit. `End` collects the flow's result (bind `result`). |
| | Condition | Branch on a predicate (route to one of several next nodes). |
| | Map / Join | Fan a list out to parallel branches, then collect them. |
| | Loop | Bounded repeat (e.g. a revise-until-approved loop). |
| | Merge | Converge branches from a Condition fan-out. |
| **Data** | Knowledge Graph Query | Ask the knowledge graph; returns rows + a synthesized, cited answer. |
| | Index uploads | Index uploaded files so later nodes can use their content. |
| | Generate DOCX | Render text/sections into a downloadable Word document (optionally branded with a Document Template). |
| | Generate PPTX | Render sections into a downloadable PowerPoint deck (one slide per section). |
| | Generate file | Render into a chosen format — Word, PowerPoint, PDF, or HTML — with one block. |
| **LLM** | LLM generate | Free-form generation from a prompt (the general "writer"). |
| | LLM extract | Structured extraction into a typed schema. |
| | LLM classify | Classify input into one of a set of labels. |
| **Agents** | Knowledge research agent | Deep, self-directed investigation over the **internal** knowledge graph + documents. |
| | Web research agent | Deep investigation over the **web** (Tavily), with cited sources. |
| | Orchestrator agent | A coordinator that calls other nodes as **tools** and decides the path at runtime. |
| | MCP action | Calls tools on a configured MCP server. |
| **Human** | Human review | Pause the run for a person to approve / edit / reject, then resume. |
**How data flows:** an edge sets execution order; the **data** flows through each node's input bindings. Connecting two nodes auto-wires compatible ports, and you can drag port-to-port to wire a specific value. To feed the user's request into a node, bind the input to **Chat message** (`$.params.message`) — the chat agent forwards it when it launches the flow. To pass one node's output to another, bind to `$.nodes..outputs.`.
***
## Recipe 1 — Answer from the knowledge graph
**Use it for:** grounded Q\&A over your own data (projects, deliverables, contracts, people…).
```
start → Knowledge Graph Query → end
```
* **Knowledge Graph Query**: set **Output mode = report** (returns a written, cited answer, not just rows). Bind its **`query`** input to **Chat message** so the user's question drives it.
* **end**: bind `result` ← `Knowledge Graph Query.text`.
**How to build:** New flow → drag `Knowledge Graph Query` from **DATA** → connect `start → KG → end` → select the KG node → Output mode = report → wire its `query` input to **Chat message** → wire `end.result` to the KG `text` output → **Publish** → enable the **Sub-agent** toggle and write a description so the chat agent can launch it (or use the **Run** tab).
**Validated:** returns real `Project`/`Deliverable` rows with an evidence-cited narrative.
***
## Recipe 2 — Research the web
**Use it for:** current, externally-sourced answers with citations.
```
start → Web research agent → end
```
* **Web research agent**: set the **goal** to your question (it supports `{{ params.message }}` to use the chat message). It runs multiple live searches and returns a sourced report on its `text` output.
* **end**: `result` ← `Web research agent.text`.
**Validated:** ran live Tavily searches and produced a sourced brief (e.g. a Python 3.13 summary citing the official "What's New" page).
***
## Recipe 3 — Combine the graph **and** the web into one cited answer
**Use it for:** "answer using what we know internally **plus** what's current on the web," with `[KG]` / `[Web]` attribution.
```
start → Knowledge Graph Query (report) ┐
├→ LLM generate (synthesize) → end
start → Web research agent ┘
```
* The two sources run **in parallel**; `LLM generate` waits for both (a node with two incoming edges auto-defers until both finish).
* **LLM generate** prompt fuses both: reference `{{ nodes.web_research.outputs.text }}` and bind its `context` input to the KG node's `text`; instruct it to tag claims `[KG]` vs `[Web](url)`, note agreements/conflicts, and end with a Sources list.
* **end**: `result` ← `LLM generate.text`.
Don't use `Merge` + `Knowledge Graph Query` (report mode) to "combine" the two sources — `Merge` is for Condition fan-outs (it forwards one branch), and `Knowledge Graph Query` (report mode) only writes from a knowledge-graph retrieval handoff. The general writer for fusing arbitrary sources is **LLM generate**.
***
## Recipe 4 — Classify, then route
**Use it for:** sending different question types down different paths.
```
start → LLM classify → Condition → ┌ LLM generate (technical) ┐
└ LLM generate (general) ┘ → Merge → end
```
* **LLM classify** labels the input (e.g. `technical` | `general`); **Condition** routes on that label; the unused branch is skipped; **Merge** converges the chosen branch to `end`.
**Validated:** a technical question classified `technical`, routed to the technical branch (general branch correctly skipped), and produced a grounded answer.
***
## Recipe 5 — Research → write a report → Word document
**Use it for:** turning a research request into a polished, downloadable deliverable.
```
start → Web research agent → LLM generate (report) → Generate DOCX → end
```
* **Web research agent** gathers sourced findings → **LLM generate** writes a structured report from them → **Generate DOCX** renders it to a `.docx` artifact you can download.
**Validated:** produced a 40 KB Word document (54 paragraphs) from a live web research pass.
Give the Web research agent a reasonable budget (≈12+ model calls). Very small budgets can exhaust mid-investigation.
***
## Recipe 6 — Knowledge graph → structured extraction → document
```
start → Knowledge Graph Query (report) → LLM extract → Generate DOCX → end
```
* Pull grounded data from the graph, **LLM extract** it into a typed structure (e.g. a list of `{name, …}` objects), then render a document.
**Validated:** KG returned 39 rows (`MATCH (p:Project)-[:HAS_DELIVERABLE]->(d:Deliverable)`), extracted structured names, and produced a 90-paragraph `.docx`.
***
## Recipe 7 — Let an orchestrator decide
**Use it for:** open-ended requests where you can't predict which sources are needed; the agent picks and iterates.
```
start → Orchestrator agent (tools: Knowledge Graph Query, Web research, Generate DOCX) → end
```
* Give the **Orchestrator** a goal and a set of **allowed tools** (other nodes become its tools). At runtime it decides whether to query the graph, research the web, generate a document, or combine them — and writes the final answer itself.
**When to prefer it:** open-ended/iterative tasks. For always-run-both-in-parallel with a fixed shape, prefer Recipe 3 (deterministic, predictable cost).
***
## Recipe 8 — MCP action (call external tools)
**Use it for:** taking actions or fetching data through a configured MCP server.
```
start → MCP action → end
```
* Point **MCP action** at a configured MCP server (admin **MCP Servers**) and whitelist the tools it may use.
**Validated:** a live run against the `time-mcp` server returned the real current UTC time.
Servers that need OAuth (Google, Slack, HubSpot…) must be connected first. No-auth servers (e.g. time, sequential-thinking) work immediately.
***
## Recipe 9 — Human-in-the-loop (review & approve)
**Use it for:** anything that needs sign-off before it finalizes.
```
start → LLM generate → Human review → LLM generate (revise) → end
```
* **Human review** pauses the run and surfaces the draft in the **Agent Inbox**; a reviewer approves (or rejects with feedback). On approval the flow resumes; on rejection you can loop back to revise.
**Feed the reviewer's note into the revise step.** The review card lets the reviewer add a **note** — optional on approve, required on reject. Bind it into the revise step's prompt so the feedback actually drives the rewrite:
```
Revise the draft using this reviewer feedback:
{{ nodes..outputs.comment }}
```
Route the loop on `{{ nodes..outputs.decision }}` (`"approved"` / `"rejected"`) — or the boolean `{{ nodes..outputs.approved }}` — so a rejection goes back to **LLM generate (revise)** with the note applied, and an approval finishes the run. See the [Human review node](/admin-guide/agent-flows-blocks#human-nodes) for the full list of outputs.
**Validated:** the run paused at `Human review`, resumed on approval, and the revise step produced the final answer.
***
## Recipe 10 — Fan out work in parallel (map / join)
**Use it for:** doing the same step over many items at once (e.g. author each section of a document).
```
start → LLM extract (a list) → Map → LLM generate (per item) → Join → LLM generate (assemble) → end
```
* **Map** fans the list out to parallel branches (one per item), **Join** collects them, and a final node assembles the pieces.
**Validated:** a 3-item list fanned to 3 parallel branches; Join collected all three; the summary combined them coherently. (This is the same engine the **RFP Response Pipeline** template uses to author 17 sections in parallel.)
***
## Flagship templates
Two ready-made templates combine many of the above (start them from **Agent Flows → Templates → Use template**):
* **Grunley Scope Merge** — upload scope documents → index → LLM merge of the uploaded documents → human review → **Merged Scope of Work** `.docx`. *(Validated: two uploaded scope docs → a consolidated, cited SOW grouped by project.)*
* **RFP Response Pipeline** — upload an RFP → extract requirements → route (standard/bespoke) → compliance matrix → human review → **parallel section authoring (orchestrator + map)** → assemble → final review → RFP response `.docx`. *(Validated: a full proposal grounded in the RFP brief.)*
***
## Building a flow in the admin — the short version
1. **AI & Agents → Agent Flows → New flow**, give it a name (the system handles the internal id).
2. Drag nodes from the **palette** onto the canvas; **connect** them (`start → … → end`). Connecting auto-wires compatible data; drag **port-to-port** for a specific value, or use **Fix wiring** to complete required inputs.
3. **Select a node** to configure it (Inspect panel); bind inputs to **Chat message** (`$.params.message`), to another node's output (`$.nodes..outputs.`), or to an uploaded file slot.
4. **Validate**, then **Publish** (publishing snapshots an immutable version).
5. **Run it** from the **Run** tab (provide params/files), or enable the **Sub-agent** toggle (and write a good description) so the chat agent can launch it during a conversation.
**Edit as JSON:** the canvas toolbar has an **Edit as JSON** action to export the flow definition (copy/download) and paste an edited definition back. Applying runs the same validation as the canvas, so a malformed definition is rejected before it loads — handy for copying a flow between environments or making bulk edits.
## Tips
* **Feed the user's question in** by binding the entry node's `query`/`context` to **Chat message** — don't rely on a hard-coded value.
* **Parallel + converge:** a node with two incoming edges waits for both — no explicit Join needed for simple fan-in (use Join when you fanned out with Map).
* **Pick the right writer:** `LLM generate` for fusing arbitrary sources; `Knowledge Graph Query` (report mode) for graph-grounded answers; `LLM extract` for structured data.
* **Budgets:** give research/orchestrator nodes enough model-call budget for the task.
## On the roadmap
A **natural-language flow builder** — describe what you want in the admin and have an agent assemble the flow for you — is planned. Until then, this cookbook + the templates are the fastest way to start.