Skip to content
Documentation
Workflows
Examples

Examples

These examples illustrate common workflow patterns. Each one describes the states, transitions, guards, and tools involved.

Sales Agent

A three-state workflow that qualifies a lead, searches for matching products, and handles checkout.

States:

  1. Gather Preferences (Conversation) – Ask the customer about their needs, budget, and timeline. Required fields: product_type, budget, timeline.
  2. Search Options (Action) – Use search_products to find matching items based on gathered data. Present results to the user.
  3. Checkout (Conversation) – Walk the user through purchase confirmation. Use create_order when they are ready.

Transitions:

  • Gather Preferences -> Search Options: Guard all_required_answered (all three fields recorded)
  • Search Options -> Checkout: Guard tool_called (the search_products tool has been called)
  • Checkout is a terminal state

Tools: record_data (global), search_products (Search Options), create_order (Checkout)

Document Processing

A three-state workflow for extracting data from uploaded documents, sending it to an external system, and confirming delivery.

States:

  1. Extract Data (Conversation) – Ask the user to upload a document. Use extract_document to parse it and record_data to store the extracted fields.
  2. Send to System (Action) – Use an HTTP tool to POST the extracted data to an external API. Record the response status.
  3. Confirm Delivery (Conversation) – Report the result to the user and ask if they want to process another document.

Transitions:

  • Extract Data -> Send to System: Guard data_contains (key extracted_data is present)
  • Send to System -> Confirm Delivery: Guard always (advance immediately after the action completes)
  • Confirm Delivery is a terminal state

Tools: record_data (global), extract_document (Extract Data), a custom HTTP tool (Send to System)

Approval Flow

A four-state workflow for submitting a request, checking entitlement, routing to an approver, and updating a calendar.

States:

  1. Gather Request (Conversation) – Collect the request details from the user: type, dates, and reason. Required fields: request_type, start_date, end_date, reason.
  2. Check Entitlement (Action) – Query an external system to verify the user has sufficient entitlement. Record the result as entitled: true/false.
  3. Request Approval (Conversation) – If entitled, notify the user’s manager and wait for an external approval event via webhook. If not entitled, inform the user and end.
  4. Update Calendar (Action) – On approval, use a calendar tool to block the requested dates and notify the user.

Transitions:

  • Gather Request -> Check Entitlement: Guard all_required_answered
  • Check Entitlement -> Request Approval: Guard data_contains (key entitled equals true)
  • Check Entitlement -> terminal “Not Entitled” state: Guard data_contains (key entitled equals false)
  • Request Approval -> Update Calendar: Guard external_event (event type approval_granted)
  • Request Approval -> terminal “Denied” state: Guard external_event (event type approval_denied)
  • Update Calendar is a terminal state

Tools: record_data (global), a custom HTTP tool for entitlement checks (Check Entitlement), send_email (Request Approval), a calendar HTTP tool (Update Calendar)

Report Collection

A workflow that uses the Task state to fan out report requests to multiple team members, then compiles and distributes the results.

States:

  1. Collect Reports (Task) – Fan out a “Submit your weekly status report” task to each member of the team. Participants are resolved from a dataset query against the team_members dataset. Each participant receives the request via their preferred channel and responds independently.
  2. Compile Report (Action) – Once all participant tasks are complete, combine the individual reports into a single summary using save_content.
  3. Send to Management (Action) – Use send_email to deliver the compiled report to the management distribution list.

Transitions:

  • Collect Reports -> Compile Report: Guard all_tasks_complete
  • Compile Report -> Send to Management: Guard always
  • Send to Management is a terminal state

Tools: record_data (global), save_content (Compile Report), send_email (Send to Management)

Task template configuration: The Task state in “Collect Reports” uses a task template with participant resolution set to dataset_query against the team_members dataset. Each participant receives the task instructions and can respond via any enabled channel. See Task Templates for details on configuring participant resolution.

Expense Reimbursement (Logic States + Approval Gate)

A workflow that collects an expense claim, validates it with deterministic logic, routes for approval, and processes the reimbursement. Demonstrates Logic states, conditional branching, and the approval gate feature.

States:

  1. Collect Details (Conversation) – Ask the user for the expense type, amount, receipt, and description. Required fields: expense_type, amount, receipt_url, description.
  2. Validate & Route (Logic) – A deterministic state that checks the amount and routes accordingly:
    • Operation 1: transform – convert amount to a number using to_number
    • Operation 2: conditional_branch – if amount > 500, route to “Manager Approval”; otherwise route to “Process Reimbursement”
  3. Manager Approval (Conversation) – Present the expense summary to the user and wait for manager approval. This state has require_human_approval: true with approval_contacts set to {gathered_data.manager_email}.
  4. Process Reimbursement (Logic) – A deterministic state that calls the finance API:
    • Operation 1: http_request – POST to the finance system with the expense details
    • Operation 2: set_data – store the transaction ID from the response
    • Operation 3: send_notification – email the user a confirmation with the transaction ID
  5. Done (Conversation) – Confirm the reimbursement to the user.

Transitions:

  • Collect Details -> Validate & Route: Guard all_required_answered
  • Validate & Route -> Manager Approval: Via conditional_branch (amount > 500)
  • Validate & Route -> Process Reimbursement: Via conditional_branch (amount <= 500)
  • Manager Approval -> Process Reimbursement: Guard always (fires after approval is granted)
  • Process Reimbursement -> Done: Guard always
  • Done is a terminal state

Retry policy: The “Process Reimbursement” state has a retry policy of max_attempts: 3, backoff_seconds: 10 in case the finance API is temporarily unavailable.

Employee Onboarding (Subworkflow)

A workflow that orchestrates new employee onboarding by nesting reusable sub-processes as child workflows.

States:

  1. Collect Employee Info (Conversation) – Gather the new hire’s name, role, department, start date, and equipment preferences. Required fields: employee_name, role, department, start_date.
  2. IT Setup (Subworkflow) – Runs the “IT Provisioning” workflow as a child process. Input mapping sends employee_name, role, and department to the child. Output mapping receives laptop_id, email_address, and vpn_credentials back.
  3. HR Paperwork (Subworkflow) – Runs the “HR Document Collection” workflow. Input mapping sends employee_name and start_date. Output mapping receives documents_complete: true/false.
  4. Welcome Email (Logic) – Sends a welcome email with all provisioned details:
    • Operation: send_notification – email to {gathered_data.email_address} with a template referencing laptop ID, VPN credentials, and start date
  5. Complete (Conversation) – Notify the requesting manager that onboarding is finished and provide a summary.

Transitions:

  • Collect Employee Info -> IT Setup: Guard all_required_answered
  • IT Setup -> HR Paperwork: Guard always
  • HR Paperwork -> Welcome Email: Guard data_equals (key documents_complete equals true)
  • Welcome Email -> Complete: Guard always
  • Complete is a terminal state

This pattern keeps each sub-process (IT provisioning, HR paperwork) as its own independently testable workflow that can be reused across different parent workflows.

Lead Scoring Pipeline (Logic + Reducers)

A workflow that uses Logic states and reducers to build up a composite lead score from multiple data sources before routing to the right sales team.

States:

  1. Qualify Lead (Conversation) – Gather company name, size, industry, budget range, and use case. Required fields: company_name, company_size, industry, budget.
  2. Score Lead (Logic) – Compute a lead score using deterministic operations:
    • Operation 1: set_data – initialize lead_score to 0
    • Operation 2: conditional_branch – if company_size > 500, set lead_score to 30 via set_data with reducer increment; if > 100, increment by 20; otherwise increment by 10
  3. Enrich Data (Logic) – Look up the company in an external CRM:
    • Operation 1: http_request – GET company details from CRM API using {gathered_data.company_name}
    • Operation 2: set_data – store the CRM response data
  4. Route to Team (Logic) – Route based on final score:
    • Operation: conditional_branch – if lead_score >= 50, route to “Enterprise Team”; otherwise route to “SMB Team”
  5. Enterprise Team (Conversation) – High-touch follow-up with enterprise sales playbook.
  6. SMB Team (Conversation) – Automated follow-up with SMB sales playbook.

State schema (reducers):

{
  "lead_score": {
    "type": "number",
    "reducer": "increment"
  },
  "crm_data": {
    "type": "dict",
    "reducer": "merge_dict"
  }
}

Transitions:

  • Qualify Lead -> Score Lead: Guard all_required_answered
  • Score Lead -> Enrich Data: Guard always
  • Enrich Data -> Route to Team: Guard always
  • Route to Team -> Enterprise Team / SMB Team: Via conditional_branch
  • Enterprise Team and SMB Team are terminal states

Vacation Request

A workflow that handles vacation requests end-to-end using the new state primitives: Parse, Approval, Output, and named output ports. An employee emails their vacation request in natural language. The workflow extracts the dates, checks a calendar, gets manager approval (with back-and-forth), records the vacation, and notifies the requestor.

States:

  1. Parse Request (Parse) – Extract requestor_name, vacation_start (date), vacation_end (date), and reason (string, optional) from the user’s message.
  2. Ask for Details (Conversation) – If the parse was incomplete, ask the user for missing information: “I need your name and the dates you’d like off.”
  3. Check Calendar (Logic) – Call a calendar API via http_request to check availability. Use conditional_branch to route based on calendar_available.
  4. Notify Conflict (Output) – Email the requestor about scheduling conflicts. Target: conversation. Template: “Unfortunately your requested dates conflict with: {gathered_data.conflicting_events}.”
  5. Request Approval (Approval) – Email the manager for approval. Approvers: {gathered_data.manager_email}. Body: “{gathered_data.requestor_name} requests vacation from {gathered_data.vacation_start} to {gathered_data.vacation_end}.” Escalation: 48 hours to department head.
  6. Negotiate (Conversation) – The manager had questions or suggested alternatives. Facilitate discussion, then loop back to Request Approval.
  7. Record Vacation (Logic) – Call the HR system via http_request to record the approved vacation. Error handling: retry 3x, then route to error port.
  8. Confirm to Requestor (Output) – Send confirmation email. Target: conversation. Template: “Your vacation from {gathered_data.vacation_start} to {gathered_data.vacation_end} has been approved and recorded.”
  9. Notify Denied (Output) – Send denial notification. Target: conversation. Template: “Your vacation request was denied. Reason: {gathered_data.rejection_reason}.”

Transitions:

  • Parse Request complete → Check Calendar
  • Parse Request incomplete → Ask for Details
  • Ask for Details → Parse Request: Guard all_required_answered (keys: requestor_name, vacation_start, vacation_end)
  • Check Calendar → Request Approval: Via conditional_branch (calendar_available = true)
  • Check Calendar → Notify Conflict: Via conditional_branch (calendar_available = false)
  • Notify Conflict done → terminal
  • Request Approval approved → Record Vacation
  • Request Approval rejected → Notify Denied
  • Request Approval discussion → Negotiate
  • Request Approval timeout → terminal (auto-escalation handles reminders)
  • Negotiate → Request Approval: Guard user_confirmed
  • Record Vacation → Confirm to Requestor: Guard always
  • Record Vacation error → terminal (admin notified via error data)
  • Confirm to Requestor done → terminal
  • Notify Denied done → terminal

Flow diagram:

[Parse Request] --complete--> [Check Calendar] --available--> [Request Approval]
      ^                              |                           |  |  |  |
      |                         conflict                    appr rej disc timeout
      |                              |                       |    |   |
      |                     [Notify Conflict]          [Record] [Denied] [Negotiate]
      |                              |                    |                  |
      +------(new dates)------------+              [Confirm]         (resubmit)
      ^
      |
[Ask for Details] <--incomplete--

Key patterns demonstrated:

  • Parse + Conversation loop – Parse extracts fields, incomplete loops back through Conversation to gather missing info.
  • Email-native Approval with discussion – The manager replies to an email naturally. LLM classifies the reply and routes accordingly.
  • Output for notifications – Template-based emails without LLM cost.
  • Error boundaries – Record Vacation retries 3x on API failure, then routes to an error handler.
  • Named output ports – No guard configuration needed for standard branching.
Visual EditorTask Templates