Agent Flows Cookbook

​

The node palette at a glance

​

Recipe 1 — Answer from the knowledge graph

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.

​

Recipe 2 — Research the web

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.

​

Recipe 3 — Combine the graph and the web into one cited answer

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.

​

Recipe 4 — Classify, then route

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.

​

Recipe 5 — Research → write a report → Word document

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.

​

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.

​

Recipe 7 — Let an orchestrator decide

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.

​

Recipe 8 — MCP action (call external tools)

start → MCP action → end

• Point MCP action at a configured MCP server (admin MCP Servers) and whitelist the tools it may use.

​

Recipe 9 — Human-in-the-loop (review & approve)

start → LLM generate → Human review → LLM generate (revise) → end

• Human review pauses the run and surfaces the draft in the conversation’s flow-run panel (and, for staff, the Agent Inbox); a reviewer approves (or rejects with feedback). On approval the flow resumes; on rejection you can loop back to revise.

Revise the draft using this reviewer feedback:
{{ nodes.<review_id>.outputs.comment }}

​

Recipe 10 — Fan out work in parallel (map / join)

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. Bind the assembling node to the Join’s results_by_name rather than results — that port keys each branch’s result by the map item it came from — and fan the Map out over a list of distinct item names so the results key cleanly.
• Put a Condition on the Join’s ok in front of the assembling node and route false into a revise lane: failed_indexes is built from the branch count, so a Map that fanned out over an empty list leaves it empty and the assembling node would otherwise produce a document with nothing in it. See Join for the port detail.

​

Flagship templates

• Grunley Scope Merge — upload scope documents → index → LLM merge of the uploaded documents → human review → Merged Scope of Work .docx (the DOCX binds the review’s content, so an edit made at the gate reaches the delivered file, and rejecting the merged scope ends the run as a failure with no document rather than quietly completing). (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 (the DOCX binds the final review’s content, so a reviewer’s edits reach the delivered file). The chain hides two loops: rejecting the compliance matrix sends the run back to re-extract the requirements with the reviewer’s note instead of walking on into section authoring, and once those attempts run out it goes ahead with the matrix it has; the drafted sections have to pass a quality gate before assembly, and a rejection at the final review — or a draft that fails that gate — re-authors just the sections that need it through a second authoring lane and re-assembles, and when that loop runs out the run ends with no document and is reported as failed rather than delivering a .docx. The assembly step is handed the names of the sections the draft stage held back or could not produce at all, so any of them a later pass didn’t re-author surfaces in the assembled document under its planned heading with an explicit not-included note instead of vanishing. (Validated: a full proposal grounded in the RFP brief.)

​

Recipe 11 — Ask the copilot

• “Build a flow that pulls RFP requirements from an upload, drafts a response, and has someone review it before it’s sent.” On the list page, this produces a New-flow proposal already wired up; apply it and the editor opens with the draft in place.
• “This flow’s llm.extract node keeps producing garbled JSON in the sections field.” On the editor, the copilot reads the open definition, recognizes an untyped array in the extraction schema (lint L3), and proposes the fix as a small, targeted edit rather than rewriting the whole flow.
• “Why did run a1b2c3d4 fail?” It reads that run’s content-free diagnostics — the failed node, the error shape, timings and tokens — and explains what happened, without ever seeing the values your flow actually produced.
• “Add a review gate before the document gets generated.” It proposes inserting a human.review node ahead of the document step and rewiring the binding so the reviewed (possibly edited) content is what the document node actually renders — the same “bind to content, not the draft” rule from Recipe 9 above, which trips up hand-built flows too.

​

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.<id>.outputs.<port>), 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.

​

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