The workflow editor

A workflow is a small, ordered spine of agents, each with its own steps. This page covers what you're actually authoring in the editor: agent slots, step kinds, inputs, integrations, and how one step refers to another's output.

Agents are the top-level rail

The editor's left rail lists agents, not a flat list of steps. Each agent is its own row with a slot name, a harness, and a model. Add up to 20 agents, and each keeps its own session for the whole run. Expand an agent to see and reorder its steps underneath it.

• Slot is the agent's address: lowercase, starting with a letter (triage, fix_agent). Other steps and refs point at an agent by its slot, so renaming one after you've referenced it will break those references.
• Harness and model pick which coding agent runs that slot's steps. Switching harness mid-workflow means adding a new agent, not changing an existing one. A single agent's session never changes harness. To swap the model partway through the same agent's steps, use a Switch model step instead (see below).

An agent doesn't have to run alone in the spine. Add one in parallel with another and the two run side by side instead of one after the other. See Parallel agents for how a group like that works, what its lanes can see of each other, and what happens if one of them fails.

Steps

Every step belongs to exactly one agent and runs in that agent's own session, in the order it appears. Each step also has an optional one-line label (the skim register shown on the rail) and an on-fail behavior: stop the run, retry, or continue to the next step.

The step kinds:

An Include step is validated when you save, but its child definition is not copied into the parent. Each run resolves the included workflow's current version when the run starts. Editing the child after you save the parent can therefore change the parent's next run.

Inputs

Inputs are the values a run is started with: named, typed, and either required or optional with a default. Types are text, number, choice (pick from a fixed list), and boolean. Reference an input from any step's templated fields with {{inputs.<name>}}.

References between steps

A Write output step's captured fields become available to every step that runs after it, anywhere in the workflow (later steps in the same agent, or steps in a later agent), not to steps before it and not to itself. Reference one with {{<name>.<field>}}, where <name> is the Write output step's own name, not the agent's slot.

• {{inputs.issue_id}} — the issue_id input.
• {{triage_result.severity}} — the severity field a Write output step named triage_result captured earlier in the run.

The editor's reference popover only suggests inputs and Write output steps that are actually in scope at the step you're editing. An output from a step later in the run, or from the step itself, won't show up, and won't resolve at runtime either.

inputs, steps, and fields are reserved. You can't name a Write output step any of those. fields is reserved for a Notify step's own agent-filled fields, below.

Notify's agent-filled fields

A Notify step's message is normally a straight template, but it can also have an agent fill in named fields right before the notification sends. Pick which agent slot fills them and declare a flat schema (string, number, or boolean, each with an optional description). The message then references any field in that schema as {{fields.<name>}}, the same way it would reference a Write output step's field. It is scoped to that one Notify step rather than visible workflow-wide.

Integrations

Integrations are explicit and workflow-wide today. A workflow does not inherit tools from the chat or workspace that launched it. Turning on Issues or Slack grants the run every tool in that provider's namespace; there is no per-tool picker. Integrations require a cloud run.

The agent panel also shows an Integrations row for recording a narrower subset on an individual slot. The definition records that selection, but all agents currently share one run-level gateway token. Because a tool call does not identify its agent slot, gateway enforcement uses the union of every slot's grants.

Where to go next