Workflow Overview
Workflows are the execution engine behind every AI Employee. A workflow is a directed acyclic graph (DAG) of actions, where each action performs a specific task and passes its outputs to downstream actions through input bindings.
Core Concepts
Workflow
A workflow defines the logic an AI Employee follows when triggered. It consists of:
- Actions -- Individual processing steps (LLM calls, searches, API calls, etc.)
- Input Bindings -- Connections that route data from one action's outputs to another's inputs
- Workflow Inputs -- External data provided when the workflow is triggered
- Results / Named Results -- The final outputs produced by the workflow
Actions
An action is a single step in a workflow. Each action:
- Has a registered action type (e.g.,
search/v2,call_llm,external_action_caller) - Declares typed inputs and outputs
- Can be synchronous or asynchronous
- May support human-in-the-loop (HITL) interaction
Actions are organized into categories:
| Category | Description |
|---|---|
CORE | Built-in actions (LLM calls, search, routing) |
INTEGRATION | External system connectors |
TRANSFORMATION | Data processing and formatting |
CONTROL_FLOW | Branching, looping, and orchestration |
Input Bindings
Input bindings define how data flows between actions. Each binding specifies:
- Source -- Where the data comes from (another action's output, workflow input, or a static value)
- Target -- Which input of which action receives the data
- Type -- The data type being transferred
Binding types include:
| Binding Type | Description |
|---|---|
ACTION_OUTPUT | Output from a previous action |
WORKFLOW_INPUT | Input provided when the workflow starts |
STATIC_VALUE | A constant value defined in the workflow |
CONDITION | A conditional binding based on runtime evaluation |
Execution Flow
- The workflow is triggered (via chat message, dashboard row, or document request).
- Actions execute in topological order based on the DAG structure.
- Each action receives inputs from its bindings, processes them, and produces outputs.
- Outputs are routed to downstream actions through their input bindings.
- The final action(s) produce the workflow's results.
[Trigger] → [Action A] → [Action B] → [Action C] → [Result]
↓
[Action D] ──────────────→ [Action E]Workflow Outputs
Workflows support two output protocols:
results(legacy) -- A map of result definitions. Used by existing workflows.namedResults(preferred) -- A map of named output definitions with richer metadata. Recommended for all new workflows.
The namedResultsEnabled flag determines which protocol is active. The two protocols are mutually exclusive.
Tools and External Actions
Workflows can call external systems through:
- Tools -- Predefined integrations (e.g., Salesforce, Jira, Slack)
- External Actions -- Custom actions registered by builders through third-party providers (Paragon, Composio, Workato)
External actions support:
| Provider | Description |
|---|---|
ACTION_PROVIDER_PARAGON | Paragon integration platform |
ACTION_PROVIDER_COMPOSIO_MCP | Composio MCP connector |
ACTION_PROVIDER_COMPOSIO_TOOL | Composio tool connector |
ACTION_PROVIDER_EMA_EXTERNAL_TOOL | Ema native external tool |
ACTION_PROVIDER_WORKATO | Workato integration platform |
ACTION_PROVIDER_EMU | Ema universal connector |
Conditions
Actions can have conditions that determine whether they execute. Conditions evaluate based on runtime values and support comparisons like equality, containment, and boolean logic.
Related
- Workflow Data Model -- Full data structures
- Action Data Model -- Action type definitions
- Workflow API -- API endpoints
- AI Employee Overview -- How AI Employees use workflows