AI Workflow Patterns

When you move past simple automations - "if this, then that" - you need structured patterns to keep AI workflows maintainable, debuggable, and reliable. This guide covers the four foundational patterns you'll use to build production AI automation, with concrete examples from sales and operations contexts.

Why Patterns Matter for AI Workflows

AI introduces non-determinism into your pipelines. A traditional automation always produces the same output for the same input. An AI node might classify the same email differently depending on context, phrasing, or model updates. That means your workflow architecture needs to account for variability, retries, and branching logic from the start.

Without patterns, you end up with spaghetti: a tangle of one-off automations that break silently and can't be reasoned about. Patterns give you composable building blocks.

Pattern 1: Sequential Pipeline

The simplest pattern. Data flows through a series of nodes in order, each transforming or enriching the output before passing it downstream.

nodes:
  - id: source-email
    type: source
    config:
      provider: gmail
      trigger: new_email

  - id: classify
    type: ai
    config:
      prompt: "Classify this email as: lead, support, vendor, internal"
      input: "{{source-email.body}}"

  - id: enrich
    type: action
    config:
      provider: clearbit
      action: enrich_company
      input: "{{source-email.from_domain}}"

  - id: update-crm
    type: destination
    config:
      provider: salesforce
      object: Lead
      mapping:
        email: "{{source-email.from}}"
        category: "{{classify.output}}"
        company_data: "{{enrich.output}}"

When to use it: Linear processes where each step depends on the previous one. Email processing, data enrichment pipelines, sequential approval flows.

Watch out for: Long chains create latency. If step 5 of 8 fails, you need to decide whether to retry the whole chain or resume from the failure point.

Pattern 2: Fan-Out / Fan-In

A single input triggers multiple parallel operations, and the results are collected before proceeding. This is the pattern for when you need to do several things at once.

                    ┌── [Enrich Company] ──┐
[New Lead] ────────├── [Score Lead]       ├──── [Route to Rep]
                    └── [Check Duplicates] ──┘

The source node emits a new lead. Three nodes execute in parallel: company enrichment, lead scoring, and duplicate detection. Once all three complete, the routing node has full context to make its decision.

When to use it: When multiple independent operations need to happen before a decision point. Lead processing, multi-source data aggregation, parallel API calls.

Implementation detail: The execution engine uses topological sorting to determine which nodes can run concurrently. Nodes with no dependency between them are scheduled in parallel, and a convergence node waits for all upstream parents to complete before executing.

Pattern 3: Conditional Branching

AI decisions create branches. Based on the output of a classification or scoring node, the workflow takes different paths.

nodes:
  - id: triage
    type: ai
    config:
      prompt: "Classify this inbound message. Return one of: hot_lead, warm_lead, support_request, spam"

  - id: branch
    type: conditional
    config:
      conditions:
        - when: "{{triage.output}} == 'hot_lead'"
          goto: fast-track
        - when: "{{triage.output}} == 'support_request'"
          goto: route-support
        - default: standard-nurture

When to use it: Anywhere AI makes a decision that affects downstream behaviour. Email triage, lead scoring thresholds, approval routing, anomaly detection.

Key consideration: Always define a default branch. AI outputs can be unpredictable - a classification prompt might return a value you didn't anticipate. The default branch is your safety net.

Pattern 4: Event-Driven Reactive

Instead of a linear trigger, the workflow listens for events and reacts. Multiple entry points, potentially overlapping execution windows, and state that persists across events.

[GitHub Issue Created] ──► [Triage Agent] ──► [Route + Assign]
[GitHub PR Opened]     ──► [Review Agent] ──► [Comment + Label]
[Slack Message]        ──► [Parse Intent] ──► [Create Issue / Update PR]

Each event type triggers its own sub-workflow, but they share context through a common data store. An issue creation might trigger triage, which creates a branch, which triggers the PR review workflow when the PR is opened.

When to use it: Multi-channel automation where actions in one system cascade to others. Developer operations, customer support across channels, multi-tool sales processes.

Composing Patterns

Real workflows combine these patterns. A typical sales automation might look like:

1. Event-driven trigger - new email arrives
2. Sequential pipeline - extract sender, parse body, check history
3. Conditional branch - AI classifies intent
4. Fan-out - parallel enrichment (company data, contact history, deal stage)
5. Fan-in - merge enriched data
6. Conditional branch - route based on combined score
7. Sequential pipeline - execute the chosen action (create lead, update deal, draft reply)

This composition is what makes DAG-based workflow engines powerful. Each node is a discrete unit with defined inputs and outputs. The graph structure handles ordering, parallelism, and branching.

Modelling Real Processes as Graphs

When translating a business process into a workflow graph, follow this approach:

1. Identify the trigger. What event starts this process? An email, a webhook, a schedule, a CRM change?
2. Map the decisions. Where does a human (or AI) currently make a choice? Each decision becomes a conditional node.
3. Find the parallelism. Which steps are truly independent? These become fan-out branches.
4. Define the outputs. What actions need to happen at the end? CRM updates, email sends, Slack notifications, API calls?
5. Add the safety nets. Error handling, default branches, timeout policies, retry limits.

Example: Inbound Lead Processing

Here is a real-world example modelled as a workflow graph:

Steps 3 and 4 run in parallel (fan-out). Step 5 waits for both (fan-in) before branching.

What's Next

Now that you understand the core workflow patterns, the next guide dives into conditional logic - how to write branching rules, handle edge cases, and make AI-driven decisions reliable inside your workflows.