Workflow Examples
Each example lists its nodes, how they connect, and what to put in each node. They use the builder's real variable syntax:
${attribute.topic}— an attribute value entered on the Missions launch form.${node_2_result}— the output of nodenode_2.${initial_message}— the text the run started with (the event, for webhook runs).
Node IDs such as node_2 are examples. In the builder, type $ and pick the node so the reference points at your node. For everything you can reference, see Passing Data Between Steps.
Examples that use attributes must be launched from Build → Missions. Scheduled and webhook runs get no attribute values.
1. Two-step pipeline
Goal: research a topic, then write a report.
Trigger → Researcher (node_2) → Writer (node_3)
| Node | Settings |
|---|---|
| Researcher (Agent) | Input: Research the following topic thoroughly: ${attribute.topic} |
| Writer (Agent) | Input: Using this research, write a clear, structured report: followed by ${node_2_result} |
Attributes: topic — Text Input, Required.
Any "produce raw material, then refine it" process fits this shape.
2. Content pipeline with options
Goal: research, write and review a blog post, with choices for audience and tone.
Trigger → Researcher (node_2) → Writer (node_3) → Reviewer (node_4)
| Node | Input Message Template |
|---|---|
| Researcher | Research "${attribute.blog_topic}" for a ${attribute.audience} audience. Include recent developments and key statistics. |
| Writer | Write a blog post from this research. Tone: ${attribute.tone}. Length: about ${attribute.word_count} words. then ${node_2_result} |
| Reviewer | Review this post for accuracy, clarity and engagement. List problems and suggested fixes. then ${node_3_result} |
Attributes:
| Name | Type | Options / default |
|---|---|---|
blog_topic | Text Input | — |
audience | Dropdown | General, Technical, Executive |
tone | Dropdown | Professional, Conversational, Academic |
word_count | Text Input | Default 800 |
3. Quality gate
Goal: assess content and either publish it or send it for revision.
┌─ PUBLISH ──────────→ Publisher (node_4)
Trigger → Analyst (node_2) → Condition (node_3)
└─ REVISE (default) ─→ Reviser (node_5)
| Node | Settings |
|---|---|
| Analyst (Agent) | Input: Assess the quality of this content. End your reply with one line: RECOMMENDATION: PUBLISH or RECOMMENDATION: REVISE. then ${attribute.content} |
| Condition | Branch PUBLISH: Source Analyst → result, contains, RECOMMENDATION: PUBLISH. Default Branch: REVISE. |
| Publisher (Agent) | Connected from the PUBLISH handle. Input: Format this content for publication: then ${attribute.content} |
| Reviser (Agent) | Connected from the REVISE (default) handle. Input: Revise the content using this feedback. then Content: ${attribute.content} and Feedback: ${node_2_result} |
Ask agents for a fixed, unambiguous marker line. A rule like contains publish would also match "do not publish".
4. Several perspectives with a Concurrent team
Goal: analyse a business scenario from several angles at once, then combine them.
Trigger → Analysis Team (node_2) → Synthesiser (node_3)
| Node | Settings |
|---|---|
| Analysis Team (Team) | A team using the Concurrent pattern with, for example, market, financial and risk analyst agents. Input: Analyse this scenario from your area of expertise: then ${attribute.scenario} |
| Synthesiser (Agent) | Input: Combine these analyses into an executive brief with key findings and recommended actions: then ${node_2_result} |
See Team Orchestration Patterns for team types.
5. Fan out, then merge
Goal: turn one piece of research into three deliverables in parallel, then package them.
┌→ Blog Writer (node_3) ──┐
Trigger → Researcher (node_2) → Email Drafter (node_4) → Packager (node_6)
└→ Slide Outliner (node_5) ┘
| Node | Settings |
|---|---|
| Researcher | Input: Research ${attribute.topic}. |
| Blog Writer, Email Drafter, Slide Outliner | Each connected from Researcher. Inputs such as Write a 600-word blog post from: then ${node_2_result} |
| Packager | Connected from all three. Join Mode left at the default (wait for all). Input: Blog: ${node_3_result} Email: ${node_4_result} Slides: ${node_5_result} and an instruction to package them. |
The three writers run at the same time. Packager waits until all three finish.
6. Data pipeline with functions
Goal: fetch data, transform it, and have an agent interpret it.
Trigger → Fetch (node_2, Function) → Transform (node_3, Function) → Summariser (node_4)
| Node | Settings |
|---|---|
| Fetch | Your function that takes a url parameter. Argument url: ${attribute.source_url} |
| Transform | Your function that takes input_data and format. Arguments: input_data = ${node_2_result}, format = ${attribute.output_format} |
| Summariser (Agent) | Input: Summarise this data. Highlight trends and anomalies: then ${node_3_result} |
Attributes: source_url (Text Input), output_format (Dropdown: JSON, CSV, Markdown Table).
Function arguments are passed as text after variables are filled in, so write your function to accept text.
7. Write, critique, revise
Goal: draft content, then improve it until a critic approves or three rounds pass.
Trigger → Loop Start (node_2) → Writer (node_3) → Critic (node_4) → Loop End (node_5) → Finaliser (node_6)
| Node | Settings |
|---|---|
| Loop Start | Loop Type Count, Max Iterations 3. Track output across iterations on, Output variable name round. |
| Writer (Agent) | Input: Write, or improve, a piece on ${attribute.topic}. The previous draft and its critique are below (empty on the first round): then ${round} |
| Critic (Agent) | Input: Critique this draft for clarity, accuracy and engagement. If it needs no changes, reply with only the word APPROVED. Otherwise list specific improvements. then ${node_3_result} |
| Loop End | Break Condition: Source Critic → result, contains, APPROVED. |
| Finaliser (Agent) | Connected from Loop End. Input: Format this for delivery: then ${node_3_result} |
${round} holds the previous round's draft and critique, so each round builds on the last.
8. Poll until done
Goal: check an external job every five minutes until it completes, for up to an hour.
Trigger → Loop Start (node_2) → Wait (node_3) → Check Status (node_4) → Loop End (node_5) → Reporter (node_6)
| Node | Settings |
|---|---|
| Loop Start | Count, Max Iterations 12. |
| Wait | Duration 5, Unit Minutes. |
| Check Status (Function) | Your function that takes job_id. Argument: ${attribute.job_id} |
| Loop End | Break Condition: Source Check Status → result, contains, complete. |
| Reporter (Agent) | Input: The job has finished (or we stopped waiting). Summarise its status: then ${node_4_result} |
Keep each step in a straight line inside the loop. A Wait node can pause for at most 24 hours.
9. Scheduled daily briefing
Goal: every weekday morning, research industry news and email a briefing.
Trigger (Scheduled) → Kill Switch (node_2) → News Researcher (node_3) → Briefing Sender (node_4)
| Node | Settings |
|---|---|
| Trigger | Trigger Type Scheduled, Frequency Custom (Cron), Cron Expression 0 19 * * 0-4 (19:00 UTC Sunday–Thursday = 7:00 am NZST Monday–Friday, or 8:00 am during daylight saving). |
| Kill Switch | On. Turn it off to pause the briefing without touching the schedule. |
| News Researcher (Agent) | Input with fixed text: Research the last 24 hours of developments in New Zealand fintech: market moves, regulation, competitor activity and notable deals. |
| Briefing Sender (Agent) | An agent with an email tool. Input: Email this briefing to the team: then ${node_3_result} |
Scheduled runs get no attribute values, so the topic is written into the node. Nobody is watching a scheduled run: if the email tool requires approval, pin it to Never require or the run will end Failed. See Scheduling Workflows.
10. Webhook-triggered triage
Goal: when a support system posts a new ticket, triage it and draft the right kind of reply.
┌─ URGENT ────────────→ Escalation Agent (node_4)
Trigger (Webhook) → Triage Agent (node_2) → Condition (node_3)
└─ ROUTINE (default) ─→ Support Agent (node_5)
| Node | Settings |
|---|---|
| Trigger | Trigger Type Webhook (optional — for reference). Create the webhook in Settings → Webhooks with Linked Workflow set to this workflow. |
| Triage Agent | Input: Triage this support ticket. End with one line: PRIORITY: URGENT or PRIORITY: ROUTINE. then ${initial_message} |
| Condition | Branch URGENT: Source Triage Agent → result, contains, PRIORITY: URGENT. Default Branch: ROUTINE. |
| Escalation Agent | Input: Draft an acknowledgement saying a specialist will follow up within the hour. then ${initial_message} |
| Support Agent | Input: Draft a helpful reply to this ticket. then ${initial_message} and Triage notes: ${node_2_result} |
${initial_message} contains the event type, a summary and the raw JSON payload. See Triggering Workflows with Webhooks.
11. Composing sub-workflows
Goal: reuse a data-collection workflow and an analysis workflow inside a larger one.
Trigger → Collect Data (node_2, Mission) → Analyse (node_3, Mission) → Summariser (node_4)
| Node | Settings |
|---|---|
| Collect Data (Mission) | Workflow: your data-collection workflow. Input: Collect data on ${attribute.company} from all available sources. |
| Analyse (Mission) | Workflow: your analysis workflow. Input: Analyse this collected data and report findings: then ${node_2_result} |
| Summariser (Agent) | Input: Write an executive summary with actionable insights and key risks: then ${node_3_result} |
Inside each sub-workflow, read the input with ${initial_message} — sub-workflows don't receive the parent's attributes. A Mission node's output is a JSON object of every node result in the sub-workflow.
12. One-step routing to several handlers
Goal: route a ticket to one of three handlers with a single Condition.
┌─ URGENT ─────────────→ Urgent Handler (node_4)
Trigger → Triage (node_2) → Condition (node_3) ─ TECHNICAL ───────→ Technical Team (node_5)
└─ GENERAL (default) ──→ General Agent (node_6)
| Node | Settings |
|---|---|
| Triage (Agent) | Input: Classify this ticket. Reply with one line: CATEGORY: URGENT, CATEGORY: TECHNICAL or CATEGORY: GENERAL. then ${attribute.ticket} |
| Condition | Branch URGENT: Triage → result contains CATEGORY: URGENT. Branch TECHNICAL: contains CATEGORY: TECHNICAL. Default Branch: GENERAL. |
| Handlers | Each connected from its branch handle, each with input ${attribute.ticket}. |
Branches are checked top to bottom and the first match wins, so put the most specific branch first.
13. Human sign-off before acting
Goal: draft a customer reply, have a person approve it, then send it.
Trigger → Drafter (node_2) → Approval (node_3) ──Approved──→ Sender (node_4)
| Node | Settings |
|---|---|
| Drafter (Agent) | Input: Draft a reply to this customer message: then ${attribute.customer_message} |
| Approval | Approval Title Send reply to customer?, Approval Message Check the Drafter's output before approving., Timeout 86400 (one day). |
| Sender (Agent or Function) | Connected from the Approved handle. Input: Send this reply: then ${node_2_result} |
Leave the Rejected handle unconnected — rejecting ends the run. See Using Approval Gates.
14. Debate, then decide
Goal: have agents with different views debate a proposal, then decide.
Trigger → Debate Team (node_2) → Decision Agent (node_3)
| Node | Settings |
|---|---|
| Debate Team (Team) | A Group Chat team of agents with contrasting roles (for example optimist, sceptic, pragmatist). Output Mode: Entire Chat, so the whole debate is passed on. Input: Debate the merits of this proposal from your perspective: then ${attribute.proposal} |
| Decision Agent | Input: From this debate, give a balanced recommendation: key arguments for and against, risks, and a recommended course of action. then ${node_2_result} |
15. End to end: due diligence
Goal: collect company data, analyse it in parallel, check compliance, dig deeper only when risk is high, and write a report.
Trigger → Fetch Company Data (node_2, Function)
→ Financial Team (node_3, Concurrent team)
→ Risk Assessor (node_4)
→ Compliance Check (node_5, Mission)
→ Risk Condition (node_6)
├─ HIGH ───────────→ Deep Dive (node_7) ─→ Final Report (node_8)
└─ LOW (default) ──────────────────────→ Final Report (node_8)
| Node | Settings |
|---|---|
| Fetch Company Data | Your function. Arguments: company_name = ${attribute.company}, data_types = financials,filings,news,leadership |
| Financial Team | Concurrent team (revenue, profitability and growth analysts). Input: Analyse the financial data for ${attribute.company}: then ${node_2_result} |
| Risk Assessor | Input: Assess the risk profile from this analysis. End with one line: RISK: HIGH or RISK: LOW. then ${node_3_result} |
| Compliance Check | Mission running your compliance workflow. Input: Run compliance checks for ${attribute.company} in ${attribute.jurisdiction}. |
| Risk Condition | Branch HIGH: Risk Assessor → result contains RISK: HIGH. Default Branch: LOW. |
| Deep Dive | From the HIGH handle. Input: Investigate the high-risk findings in depth: then ${node_4_result} |
| Final Report | Connected from Deep Dive and the LOW handle. Join Mode: ∨ Any parent (OR-join). Input: Company: ${attribute.company} / Financials: ${node_3_result} / Risk: ${node_4_result} / Compliance: ${node_5_result} / Further investigation (if any): ${node_7_result}, then an instruction to write the report. |
Attributes: company (Text Input), jurisdiction (Dropdown: NZ, AU, UK, EU, US).
Final Report can be reached from either branch, and only one branch runs, so its Join Mode must be Any parent — with the default it would wait for both and never run. On the low-risk path ${node_7_result} is simply empty.
Pattern summary
| Pattern | Key nodes | Example |
|---|---|---|
| Sequential pipeline | Agent → Agent | 1, 2 |
| Gate / routing | Condition with named branches and a default | 3, 10, 12 |
| Parallel perspectives | Team (Concurrent) | 4 |
| Fan-out and merge | One node → several → one (AND-join) | 5 |
| Mechanical steps | Function | 6 |
| Iterative refinement | Count loop + break condition + tracked output | 7 |
| Polling | Loop + Wait + break condition | 8 |
| Scheduled automation | Scheduled Trigger + Kill Switch | 9 |
| Event-driven | Webhook + ${initial_message} | 10 |
| Composition | Mission (sub-workflow) | 11, 15 |
| Human in the loop | Approval | 13 |
| Branches that rejoin | OR-join on the merge node | 15 |
| Working through a list | For Each loop | Ralph Loops |
There is no "on failure, go here" connection: if a node fails after its Max Retries, the run fails. Make steps that may fail report their outcome as text (for example STATUS: FAILED) and route on it with a Condition instead.