Workflows - Actionist Docs

VISUAL AUTOMATION

Build the procedure once. Run it forever.

Actionist workflows are visual graphs of typed nodes — actions, conditions, loops, tools — wired together into a procedure you design once in the editor and trigger from chat, a schedule, or the Run button.

The idea

Write the procedure once. Run it forever.

Every time you describe the same multi-step task from scratch, you pay twice — once to think it through and once to supervise it. A workflow locks the procedure in so you never repeat yourself.

An ad-hoc task

You type the steps, pick the tools, explain the context — every single time. The agent starts fresh. When something changes, you re-explain everything.

An Actionist workflow

You design the branching logic, variables, and tool calls once in the visual editor. Any run — from the Run button, a chat session, or a recurring schedule — reuses the exact same procedure.

Actionist stores workflows in a graph format (v2) with typed nodes and wired edges. An older linear format (v1) is preserved for backward compatibility. The visual editor always uses the graph format.

Under the hood

How a workflow moves.

A trigger starts the run. Execution walks the graph node by node, evaluating conditions and loops, until it reaches the end node.

▶

Start

✓

Action batch

✓

Action batch

◇

Condition

true

↻

Loop

⊕

Merge

■

End

Condition branches

trueevaluator passes → enters loop, iterates up to 50×, rejoins at merge

falseevaluator fails or errors → skips loop, jumps directly to merge (safe path)

00.0starttrigger received — variables bound
00.3action[0]navigate → app.example.com/dashboard
01.1action[1]extract → row_count=24 ✓
01.8conditionrow_count > 0 → true — routing to loop
02.4loop[1/24]processing row 1 of 24 — iteration cap: 50

Speed Mode on by default. Consecutive action and step nodes batch into a single CUA pass — up to 7 in graph mode. Add a condition or merge node to break a batch boundary.

Condition fails safely. Any evaluator error defaults to false. Design the false branch as the guard path — retry, exit, or escalate — not the destructive step.

Loop caps at 50 by default. For known-bounded tasks, set a tighter limit. If the evaluator is unreachable, loops exit immediately — fail-closed, not runaway.

Actionist — Workflow Editor

△ UNSAVEDSave

Variables

texttarget_url

numbermax_results

Basic Information

Preconditions

Success Criteria

Rules

▶ Start

◆ Action

◇ Condition

truefalse

⊕ Merge

■ End

The workspace

Two halves, one editor.

The workflow editor is split into a configuration panel on the left and a visual graph canvas on the right. Both must be complete before you save.

Left panelGraph canvas

The left panel holds seven collapsible sections. Drag the divider to give more room to the canvas or the config.

ℹ

Basic Information

Name (required) and description — shown on library cards and in the marketplace.

✓

Preconditions

Natural-language conditions that must be true before execution begins. Failure stops the run before the first node.

◎

Success Criteria

Natural-language statements that define a completed, successful run — used by the orchestration layer to evaluate true finish.

○

Domains

URL or domain patterns the workflow may operate on. Constrains which sites computer-use action nodes are permitted to touch.

{}

Variables

Typed inputs declared at design time, filled at run time. Supported types: text, number, boolean, date, select.

≡

Rules

Hard constraints in plain language applied across every node — injected into the orchestration context before the first node runs.

□

Ask Human

Prompts that pause execution and surface a question to the user — for approvals, clarifications, or edge-case handling.

ℹBasic Information

✓Preconditions

◎Success Criteria

○Domains

{}Variables

≡Rules

□Ask Human

The canvas is where you design the workflow’s logic. Nodes live on the canvas; edges wire them together.

Toolbar — live state△ UNSAVED

Control	Action
`Back (chevron)`	Returns to the workflow list — “Back to Workflows”
`Undo / Redo`	Stepped history of canvas changes
`Validation icon`	Shows error or warning count; click to surface issues per node. Shakes and blocks save on hard errors.
`UNSAVED badge`	Orange badge with alert icon — appears when there are unsaved changes. Disappears on save.
`Export (download)`	Downloads full workflow JSON including graph, nodes, edges, variables, and rules.
`Import (upload)`	Loads a workflow JSON file; fresh IDs are assigned so it never conflicts with existing workflows.
`Save`	Commits the workflow. Absent on subscribed marketplace workflows — they open view-only.

The Save button is absent when viewing a subscribed marketplace workflow. Marketplace workflows open in view-only mode — see the Subscribed workflows section below.

Node vocabulary

Eleven building blocks.

Every workflow is composed from these node types. Select a type below to see its fields, when to use it, and why it exists.

◆

Action node

Execution

What it does

Drives computer-use automation. Each action node has a subtype that maps to a specific CUA operation. The orchestrator executes it against the live screen.

Subtypes

navigateCUAload a URL

clickCUAclick an element

typeCUAenter text into a field

waitCUApause for condition or duration

screenshotCUAcapture screen for inspection

scrollCUAscroll to position or element

selectCUAchoose a dropdown option

hover / keyCUAmove cursor; send keyboard shortcut

extractCUApull structured data from current page

Key fields

subtyperequiredwhich CUA operation to run

completionCriteriaoptionalsuccessIndicators[] and failureIndicators[] so the orchestrator knows when done

timeoutMsdefault 120000per-node timeout in ms

maxAttemptsdefault 3retries before the node is marked failed

evidenceHints.urlPatternsoptionaleliminates false-positive completions on navigate nodes

When to use: any step that requires touching a UI — clicking buttons, filling forms, extracting table data, navigating between pages. If a direct MCP tool covers the operation, prefer a Custom tool node instead — it is faster and more reliable.

▶

Step node

Execution

What it does

A higher-level natural-language instruction. OrchAgent interprets the step and decides which tool calls or CUA operations to use. Less precise than an action node; useful for exploratory or variable steps.

Key fields

instructionrequiredplain-language description of what to do

completionCriteriaoptionalsuccess and failure indicators for the orchestrator

timeoutMsdefault 120000per-node timeout in ms

When to use: steps where the exact UI interactions vary (e.g. “summarise the top three results”), or early in workflow design when you want OrchAgent to figure out the mechanics before you pin down specific action subtypes.

◇

Condition node

Control flow

What it does

Evaluates a check and routes execution down the true or false edge. On any evaluator failure, defaults to false — so design the false branch as the safe path.

Check types

element_visibleUIelement is present on screen

element_not_visibleUIelement is absent

element_countUIhow many of a given element exist

text_containscontentstring appears in page text

url_containscontentstring appears in current URL

number_comparisonnumericcompare value against threshold

counterloopcompare loop iteration count

customNLnatural-language check for edge cases

Key fields

checkTyperequiredwhich of the 8 check types to run

parametersvariesselector, value, operator — depends on check type

trueEdgerequiredtarget node ID for the true branch

falseEdgerequiredtarget node ID for the false (safe) branch

When to use: whenever the workflow must branch based on what the agent sees — results count, URL reached, value threshold, element presence. Wire the false edge to the guard path — retry, exit, or escalate.

↻

Loop node

Control flow

What it does

Repeats a subgraph until a condition is met or maxIterations is reached. Default cap is 50. On any evaluator error during a loop, the loop exits immediately — fail-closed, not runaway.

Key fields

maxIterationsdefault 50hard cap — set tighter for known-bounded lists

exitConditionoptionalcondition that ends the loop early

bodyEdgerequirededge into the loop body subgraph

When to use: iterating over a list of rows, pages, or items where the count is not known at design time. Pair with a file-operation node inside the loop body to accumulate results without blowing up the context window.

⊕

Custom tool node

Execution

What it does

Invokes an MCP-backed or built-in tool directly by ID, bypassing computer use entirely. Faster, cheaper, and more reliable than screen automation when a direct integration exists.

Key fields

toolIdrequiredMCP tool ID or built-in name

parametersvariestool-specific input arguments — supports variable references

outputBindingoptionalvariable name to receive the tool’s output

When to use: any step where a direct MCP integration covers the operation — Slack messages, Notion updates, Linear issues, database queries. If the required MCP server is disconnected, the run is blocked at initialization with an error naming the missing server.

■

File operation node

Utility

What it does

Reads, writes, or updates files in the workflow’s isolated file workspace. Tag each operation with a purpose so the orchestrator and downstream steps know how to use the data.

Purpose tags

memorytagcross-step state — kept between nodes, not returned to user

contexttaginjected into subsequent steps as read context

artifacttagoutput returned to the user at the end of the run

Key fields

operationrequiredread / write / append / delete

pathrequiredfile path within the isolated workspace

purposerequiredmemory / context / artifact

contentwrite onlysupports variable references via ${varName}

When to use: loop bodies producing large intermediate outputs; multi-step scrapes where results accumulate across iterations; any step that generates an artifact to hand back to the user. Keeps the context window clean — do not store large outputs in variables.

Every workflow begins at exactly one Start node (receives trigger payload and variable values) and exits at one or more End nodes. Multiple end nodes are allowed for different exit paths.

Joins two or more incoming edges back into a single execution path. Use it to reunite branches after a condition split so the rest of the graph sees one stream.

Goto jumps execution to another node by reference — use sparingly. Subroutine embeds another workflow by ID and runs it inline; the parent waits for it to complete. Subroutines compose — they can themselves contain subroutines.

Node palette

▶ start

■ end

◆ action

◇ condition

↻ loop

⊕ merge

→ goto

⊞ subroutine

▷ step

⊕ custom-tool

▣ file-op

Variables

One workflow, any input.

Variables are typed inputs you declare once at design time and fill in at run time. The same “extract data from site X” workflow works for any URL you supply — just change the variable.

Declare the variable in the left panel

Open the Variables section of the left panel. Add a variable with a name (use snake_case — it becomes the form label in the run modal), a type, and an optional default value.Supported types: text, number, boolean, date, select.

Reference it in a node parameter

In any node’s detail panel, use the variable name inside a placeholder expression. Both syntaxes work:

${target_url}
{{target_url}}

The orchestration layer substitutes the real value before the node executes.

Fill in values at run time

When you click Run workflow, a modal titled “Run Workflow” opens and lists every declared variable with its type and description. Fill them in and click Run.When scheduling a workflow via the Calendar, the same variables appear under “Workflow variables” — set the defaults there and they apply to every scheduled run.

Use descriptive snake_case names for variables — report_date, target_url, max_results. The run modal displays them verbatim as form labels, so the person filling them in needs no additional documentation.

Run Workflow✕

text target_url

https://app.example.com/reports

number max_results

25

select output_format

CSV ▾

Cancel▶ Run

Build one

Your first workflow, step by step.

Open the workflow library

In the sidebar, click Workflows. The library opens at /workflows, sorted by last updated. You will see three tabs at the top: All, Mine, and Subscribed.

Create a new workflow

Click + New workflow in the hero band. The graph canvas opens at /workflows/editor with a blank canvas and an empty left panel.

Fill in Basic Information

In the left panel, open Basic Information. Give the workflow a name and a short description. This is what teammates see on the workflow card.

Declare your variables

Open the Variables section. Add any inputs the workflow needs at run time — URLs, date ranges, IDs. Give each a descriptive snake_case name and a type.

Build the graph

Drag node types from the palette onto the canvas. Start with a start node, add action or step nodes for each operation, connect them with edges, and add condition or loop nodes for branching. End with an end node.Click any node to open its detail panel and configure parameters. Reference your variables with ${var_name} syntax.

Add Rules and completion hints

Open the Rules section in the left panel. Add any cross-workflow constraints in plain language. For action nodes, set completionCriteria in the node detail panel — success and failure indicators help the orchestration layer know when a step has genuinely finished.

Validate and save

The validation icon in the toolbar shows the error and warning count. Resolve any blocking errors (the icon shakes when save is blocked). Then click Save — the orange UNSAVED badge disappears.

Execution

Running a workflow.

Workflow execution is currently rolling out. You can still create, edit, import, and export workflows fully today. When execution is enabled in your build, the Run button activates — until then you will see: “Workflow execution is temporarily disabled. You can still create, edit, import, and export workflows.”

When execution is available, here is how a run works:

Find the workflow card

On the workflow library page, locate the workflow you want to run. Each card shows the workflow name, description, and last-updated time.

Click Run workflow

Click Run workflow on the card. If the workflow has declared variables, a modal titled Run Workflow opens and lists each variable with its type.

Fill in variable values and run

Enter the values for this specific run and click Run. A new chat session opens titled “Workflow: {{title}}”. Execution streams live — each step shows its tool calls, inputs, and outputs.

Watch for errors

If a required MCP server is disconnected, the run is blocked at initialization and an error names the missing server. Connect it in Settings → Apps/MCPs and try again.

Execution runs on the desktop app only. The visual editor loads in all runtimes, but run calls from web or headless environments are not supported.

Share and reuse

Portable and composable.

Export a workflow for safekeeping or to share with a teammate. Install one from the marketplace and customise it for your own context.

Import and export
Subscribed workflows

The toolbar’s Export button (download icon) serialises the full workflow — graph, nodes, edges, variables, rules, left-panel config — to a single JSON file. Importing restores the workflow with freshly-assigned IDs so it does not conflict with existing workflows.

Before a major restructure — snapshot first, experiment freely.
To share a workflow with a teammate who does not have access to your workspace.
To version-control your workflows alongside the rest of your project.

To import: click the Import button (upload icon) in any workflow editor’s toolbar and select the JSON file. The imported workflow appears in your library as a new workflow.

Limits and defaults

What the system defaults to.

These values apply when you do not configure them explicitly. Most can be overridden at the node level.

50default loop maxIterations

120 000 msdefault per-node timeout (2 min)

3default per-node max retry attempts

7Speed Mode batch — graph workflows

10Speed Mode batch — linear workflows

falsecondition evaluator failure default

breakloop failure default — exits immediately

21library page size, sorted by last updated

Speed Mode batches consecutive action and step nodes into a single computer-use pass. This is faster but can cause ordering issues in complex graphs. If steps appear to be skipped or run out of order, add a condition or merge node to break the batch boundary.

Best practices

Build workflows that hold up.

Add completion criteria to action nodes

Action nodes can carry completionCriteria with successIndicators[] and failureIndicators[], plus a per-node timeoutMs and maxAttempts. Without these, the orchestrator guesses from raw CUA output. Add evidenceHints.urlPatterns[] on navigation steps to eliminate false-positive completions.

Cap loop maxIterations explicitly

The default is 50, which is appropriate for open-ended scrapes. For known-bounded loops — iterating over a fixed-length table, processing a list with a known count — set a tighter limit. If the evaluator is unreachable, loops exit immediately (fail-closed, not runaway) — safe but still better to bound them correctly.

Use file-operation nodes for cross-step state

Variables hold scalar values (strings, numbers). For large intermediate outputs — scraped tables, extracted JSON, multi-page results — use file-operation nodes tagged purpose: ‘memory’ or ‘artifact’. This keeps the context window clean across many steps and prevents variable bloat.

Check MCP connections before running

Custom-tool nodes reference tools by ID. If a required MCP server is disconnected, the run is blocked at initialization with an error naming the missing server IDs. Connect or reconnect them in Settings → Apps/MCPs before attempting to run.

Design the condition false branch as the safe path

Condition nodes default to false on any evaluator failure. Wire the false edge to the safer action — retry, exit, or escalate — not to the destructive or irreversible step. The true branch should be the happy path; the false branch should be the guard.

Export before editing complex workflows

The toolbar Export button serialises the full workflow JSON. Import restores it with new IDs. Snapshot a working workflow before major restructuring — if something breaks mid-edit, you can reimport the last good state without losing the whole workflow.

Subscribed marketplace workflows are read-only — duplicate to edit

The editor opens subscribed workflows in view-only mode (no Save button, no node editing). To customise: use the kebab menu on the card and select Duplicate. The duplicate becomes a fully editable workflow in your library.

Use descriptive snake_case variable names

Both ${varName} and {{varName}} syntax work. The run modal displays variable names verbatim as form labels — target_url is self-documenting; v1 is not. Descriptive names mean anyone filling in the modal needs no additional explanation.

Prefer custom-tool nodes over action nodes when a direct tool exists

custom-tool nodes invoke MCP-backed tools directly, bypassing computer use entirely. They are faster, cheaper, and more reliable than screen automation for apps that expose a proper integration. Use action nodes only when no tool covers the step.

Use subroutines to stay DRY

If the same sequence of steps appears in multiple workflows, extract it into its own workflow and embed it as a subroutine. The parent workflow waits for the subroutine to complete before continuing. Subroutines compose — a subroutine can itself contain subroutines.

In practice

From a four-hour checklist to one run.

The monthly close involves the same sequence of steps every time. Below is what it looks like before and after encoding it as a workflow with built-in approval gates.

Before — manual close

09:00Pull AR ageing report from accounting app, paste into spreadsheet

09:30Cross-check 23 expense line items against receipts folder manually

10:15Draft variance commentary, email Felix a briefing to review

11:00Wait for Felix to review — reminder sent if no reply by noon

12:30Apply Felix’s edits, re-export PDF, upload to shared drive

13:00Post summary to Slack #finance channel, mark task complete

Entire process re-briefed from scratch next month

After — one workflow run

09:00Workflow triggered — variables: report_month, expense_threshold

09:02Action node navigates to accounting app, extract node pulls AR ageing data

09:07Loop node iterates over 23 expense rows, file-operation node writes reconciliation file

09:11Step node drafts variance commentary from extracted data

09:12Ask Human gate — Felix approves or edits commentary before the workflow continues

09:14Custom-tool node exports PDF artifact, uploads to drive, posts to Slack

Same procedure runs identically next month — no re-briefing needed

You brief the process once. After that, the workflow holds the knowledge — approvals, sequencing, edge cases and all. Next month you just hit Run.

Felix · Finance and Ops — illustrative scenario based on the features documented on this page

One build. Any trigger.

Encode your first automation today.

Open the Dashboard, click New workflow, and start with the task you repeat most.

Open the Dashboard Email the team

Design once. Run on any trigger, any schedule, any surface.
Visual graph editor · Typed variables · MCP + CUA in one graph.

Keep going

Next steps.

Schedules

Put a workflow on a recurring schedule — daily digests, weekly reports, hourly monitors.

Computer use

Understand the CUA engine that powers action nodes — vision, clicking, and screen extraction.

MCP integrations

Connect the MCP servers your custom-tool nodes depend on — Slack, Notion, Linear, and more.

Marketplace

Browse and install community-built workflows. Publish your own for others to reuse.

​Build the procedure once. Run it forever.

​Write the procedure once. Run it forever.

An ad-hoc task

An Actionist workflow

​How a workflow moves.

​Two halves, one editor.

​Eleven building blocks.

​Action node

​What it does

​Subtypes

​Key fields

​Step node

​What it does

​Key fields

​Condition node

​What it does

​Check types

​Key fields

​Loop node

​What it does

​Key fields

​Custom tool node

​What it does

​Key fields

​File operation node

​What it does

​Purpose tags

​Key fields

​One workflow, any input.

​Your first workflow, step by step.

Open the workflow library

Create a new workflow

Fill in Basic Information

Declare your variables

Build the graph

Add Rules and completion hints

Validate and save

​Running a workflow.

​Portable and composable.

​What the system defaults to.

​Build workflows that hold up.

​From a four-hour checklist to one run.

​Encode your first automation today.

​Next steps.

Schedules

Computer use

MCP integrations

Marketplace

Build the procedure once. Run it forever.

Write the procedure once. Run it forever.

How a workflow moves.

Two halves, one editor.

Eleven building blocks.

Action node

What it does

Subtypes

Key fields

Step node

What it does

Key fields

Condition node

What it does

Check types

Key fields

Loop node

What it does

Key fields

Custom tool node

What it does

Key fields

File operation node

What it does

Purpose tags

Key fields

One workflow, any input.

Your first workflow, step by step.

Running a workflow.

Portable and composable.

What the system defaults to.

Build workflows that hold up.

From a four-hour checklist to one run.

Encode your first automation today.

Next steps.