Workflow authoring

Workflows turn a repeatable process — for example, search the knowledge base, summarise the results, save a brief — into something anyone on your team can run in a single click.

This page explains how to build workflows well. It is written for operations, consulting and agency staff. If you are comfortable with spreadsheet formulas such as =IF(A1>0, "yes", "no"), you have all the background you need.

How a workflow is organised

Every workflow has three parts:

Inputs — the few things the person running the workflow needs to type in (for example, a question or a document title).
Steps — the actions that run in order.
Outputs — the information each step produces, which later steps can reuse.

You build all of this in the visual editor under Workflows → Create workflow. No code is required; the editor manages the structure for you.

Workflow inputs

Workflow inputs are the fields a teammate fills in when they trigger a run. Think of them as the top-of-sheet cells in a template: the shape stays the same each time; only the values change.

Typical inputs for a research workflow:

query — the question being asked
title — what to call the resulting document

Give each input a short description so the person running it knows what to type.

Workflow outputs

Workflow outputs are the named results you want callers to see after a successful run — without digging through every step in the execution history.

In the visual editor, open Outputs at the bottom of the workflow (after your steps). Each mapping has three parts:

Field	Meaning
Output name	Label shown on the execution record (for example `document_id`)
Step	Which step produced the value (for example `create_doc`)
Step output field	Which declared output on that step to copy (for example `document_id`)

The step must declare that output in its Outputs section. On a successful run, PocketRAG copies the value into the execution’s top-level outputs. In run history, document and workspace IDs appear as clickable links when the field name matches (for example document_id, workspace_id).

Example mapping for a summary workflow that creates a document:

workflow_outputs:
  - name: document_id
    step_id: create_doc
    field: document_id

You can expose several outputs (search hit count, summary text, created document ID, and so on). Order in the editor is the order shown in execution history.

Steps and step kinds

Each step performs one action. When you add a step, you choose its kind. The kind controls the configuration panel that appears and what the step does.

Step kind	What it does	When to use it
Agent	Sends instructions to an AI agent	Write, summarise, classify, extract
Tool	Runs a built-in tool (search or documents)	Search the knowledge base, create or edit a document
MCP tool	Calls an external service you have connected	Web search, third-party APIs, custom integrations
Condition	Chooses which step to run next based on a rule	Skip a step when there are no results, branch on the input
Human approval	Pauses for a person to approve or reject	Before anything irreversible (publishing, emailing)
Subworkflow	Runs another saved workflow as a step	Reuse a shared process; pass inputs in and read outputs back

You can start any step from the From Template catalogue (Search workspace, Agent – Summarizer, New document, and more). Templates fill in the hard parts; you adjust the details.

Formulas: reusing values between steps

Like in a spreadsheet, fields that accept a value also accept a formula. Formulas are wrapped in double curly braces:

{{ workflow_inputs.query }}

As soon as you type {{ in any field, the editor shows suggestions. Two groups appear:

Workflow inputs — values your teammate entered when triggering the run.
Step outputs — results produced by earlier steps.

The most common formulas are:

You want to use…	Formula
A value provided at trigger time	`{{ workflow_inputs.title }}`
A result from an earlier step	`{{ steps.summarize.outputs.summary }}`
The results of a search step	`{{ steps.search_workspace.outputs.results }}`

Most fields also let you mix normal text with a formula, exactly like combining text and a cell reference in a spreadsheet:

Please draft a short reply to: {{ workflow_inputs.query }}

Chaining: passing information from one step to the next

Chaining is the term for using an earlier step’s result in a later step. Three rules keep chaining reliable:

The earlier step must declare what it returns. Every step has an Outputs section where you list the results it produces (for example summary, results, document_id). Naming an output is what makes it visible to later steps.
The later step references it with a formula of the form {{ steps.<step_name>.outputs.<output_name> }}.
Earlier steps come first. A step may only reuse outputs from steps listed above it. The editor warns you if the order is wrong — drag the steps to reorder.

Wiring values into agent steps

Agent steps have one extra rule worth knowing: the agent’s prompt should not contain a direct reference to another step. Instead, add a step input (typically called content) and point that input at the earlier step. The prompt then refers to the input.

In the editor:

Open the agent step.
In Inputs, click Add Input:
- Name: content
- Type: string
- Value source: From expression
- Expression: {{ steps.search_workspace.outputs.results }}

In Prompt, write the instructions that use the input:

Summarise the following in three bullet points for the account lead.

{{ content }}

Every built-in agent template follows this pattern. You can copy it for your own workflows.

Using conditions to branch

A condition step is the workflow equivalent of a spreadsheet IF. You list one or more rules; the first rule that is true decides where the workflow jumps next.

Each rule has two parts:

A condition formula that returns true or false.
A next step — the name of the step to jump to when the rule is true.

Useful examples:

Rule	Formula
Continue only if the search returned something	`{{ len(steps.search.outputs.results) > 0 }}`
Run only when the user chose “deep research” mode	`{{ workflow_inputs.mode == "deep" }}`
Always true — a catch-all fallback	`{{ true }}`

If no rule matches, the Otherwise setting decides what happens:

Continue — move to the next step in the list.
Finish workflow — end the run with a status of Success, Cancelled, or Failed, plus an optional reason.

Conditions expect a genuine yes/no answer. If a value is a list (for example search results), wrap it in len(...) as shown above — a list on its own is not treated as true or false.

Human approval steps

See Human approval for the full guide.

Approvals put a person in the loop. When the workflow reaches an approval step, it pauses. The run only continues after someone opens it and approves (or rejects) the step.

Configure two fields:

Message — the short prompt shown to the approver.
Instructions — any guidance they should read first.

Use approvals before anything you cannot undo: publishing a document, sending a client email via MCP, updating an external system of record.

What downstream steps can read. Once a reviewer decides, the approval step exposes:

approved / rejected (true/false)
decision ("approved" or "rejected")
comment (on approve, if provided) or reason (on reject, if provided)
decided_at (timestamp)
message / instructions (echoes of what was shown)

Use them in formulas like {{ steps.publish_gate.outputs.approved }} in any step (including a Condition step) to act on the decision value.

Sub-workflow steps

See Sub-workflows for the full guide.

A Subworkflow step calls another workflow you have already saved. You pick the target in the editor, pass values into the child’s workflow inputs via step inputs and formulas, then declare step outputs and parent workflow outputs to read results back. The parent waits until the child finishes.

Use sub-workflows when the same block of steps appears in more than one automation, or when a parent workflow would become hard to read.

Loop steps

See Loop steps for the full guide.

A Loop step runs the same child workflow many times — once per array element (Foreach) or a fixed number of times (Times). You pick the target workflow, map per-iteration inputs with context.loop_item and context.loop_index, and read aggregated results when every child run finishes.

Use a loop when the list length varies or you would otherwise duplicate many sub-workflow steps for the same child.

If a step fails

Every step has an Error policy with three options:

Fail — stop the workflow. This is the safe default.
Skip — record the failure and move on. Only use this when later steps genuinely do not need this step’s result.
Default value — continue with an empty or default result. Pair with a condition that checks whether the real value is present.

Breaking a big process into steps

If a process feels too big for a single step, split it by responsibility, not by size. A reliable rule of thumb is five phases:

Gather — retrieve information (search the workspace, fetch a record, look something up).
Shape — one or more agent steps, each with a single clear job (summarise, classify, extract a field).
Decide — a condition step that routes based on what you just produced.
Confirm — a human approval step before anything public or irreversible.
Record — a tool step that writes the result back (create or update a document, call an external system via MCP).

Each step should produce one or two clearly named outputs that are actually reused. Small, well-named outputs are easier to chain, easier to debug, and easier to hand over to a colleague.

Worked example: research → summary → brief

This is the same three-step pipeline shown in the demo video.

#	Step name	Kind	Purpose
1	`search_workspace`	Tool (search)	Find relevant snippets for `{{ workflow_inputs.query }}`
2	`summarize`	Agent	Turn those snippets into a short brief
3	`create_doc`	Tool (document)	Save the brief as a document titled `{{ workflow_inputs.title }}`

Workflow inputs: query, title.

Workflow outputs: document_id ← from step create_doc, field document_id (so run history shows a direct link to the new document).

The wiring between steps (what you enter in the editor):

Step 2 input content → default {{ steps.search_workspace.outputs.results }}
Step 3 input content → default {{ steps.summarize.outputs.summary }}
Step 3 config title → {{ workflow_inputs.title }}

When a teammate triggers the workflow, they enter a query and a title and receive a polished document, without repeating the process by hand.

Tips before you save

Name things clearly. Step names and output names appear in formulas, suggestions and run history. summarize is better than step_2.
Write one-line descriptions. They appear next to the step in the run history and save you re-reading prompts later.
Start from a template. Built-in templates already declare the correct outputs and follow the recommended wiring pattern.
Run end-to-end once with realistic inputs before handing the workflow to the team.

Documentation