Skip to content

Workflows ​

Workflows mode chains independent agents into a reusable, named pipeline that runs in the background — research → draft → review — where the workflow owns the sequencing, not the agents. Each step is just an existing agent (or one you create as you build), so agents stay reusable on their own while the workflow coordinates the hand-off, lifecycle, and schedule. Workflows ride on the Agents opt-in — there's no separate switch, so enabling agents is what turns them on.

A workflow board showing a five-step pipeline: two task steps, a gate, a human approval checkpoint and an inline publish step, above a completed run headerA workflow board showing a five-step pipeline: two task steps, a gate, a human approval checkpoint and an inline publish step, above a completed run header
A pipeline's detail board — the run header, then the step strip carrying all four step kinds.

Clicking Workflows in the section rail or tabs always opens Overview: the card gallery with schedules, progress and quick run/pause actions. A compact, searchable workflow list stays in the sidebar, showing each workflow's status and live progress. Select a row or card to open its detail board; Overview returns to the gallery.

Workflow cards beside a searchable sidebar with an Overview entryWorkflow cards beside a searchable sidebar with an Overview entry
Switch pipelines from the list, or monitor them together from Overview.

The sidebar shares the same resize, collapse and mobile-drawer behavior as the other sections. List rows and cards share their data, so progress stays current even while a workflow detail board is open. New workflow opens the builder; selecting Overview or another workflow exits it. Returning to the section does not reopen an old builder. Direct workflow/run links and browser Back/Forward still navigate to their specific targets.

Start here ​

GuideWhat it covers
Building a pipelineCreating a workflow, editing steps on the board, and the four step kinds.
Configuring a stepInstructions, placeholders, pipeline state, and narrowing what a step is fed and may use.
Running a pipelineTriggers, the run brief, the run trace, failures, cost, and notifications.
ReferenceThe /api/workflows surface and sharing a workflow as YAML.
Authoring specA precise, machine-oriented specification — hand it to a coding assistant that must generate a workflow.

What the workflow owns ​

An agent knows nothing about its neighbours and can't trigger another one. All the chaining lives on the workflow:

  • Reusable, not baked in. A workflow references agents by id. The same agent can appear in several workflows; the chaining lives on the workflow, so you reorder or reuse steps without touching the agents themselves.
  • One coordinator. The workflow drives the run — it starts the first step, waits for it to rest, feeds its output to the next, and advances down the line.
  • Implicit hand-off. Each step receives the immediately preceding step's full answer plus its artifacts as a kickoff preamble, mirroring a pipeline stage. You don't have to prompt a step to "use the previous result" — the coordinator forwards it. No dependency graph to reason about.
  • Shared blackboard. Beyond that immediate hand-off, a step also inherits the artifacts published by every earlier step in the run, labelled by step and oldest-first. A reviewer three stages down still sees the research inventory the first step produced — without the middle steps having to re-forward it. Steps that published nothing are skipped, and gates (which leave no deliverable) never appear on the board.

The four kinds of step ​

Every step is one of four kinds. The first two produce work; the last two judge it and are transparent to the data flow — they forward the last real producer's output rather than anything of their own.

KindRunsWhat it's for
Agenta reusable agent from the Agents sectionthe normal case — a stage you want to reuse across pipelines
Inlinea private, hidden vessel that dies with the stepone-off work that doesn't deserve a permanent agent
Gatean agent that votes PASS / FAILan automated quality check that can send the run back to an earlier step
Approvalnobody — the run parksa human checkpoint in front of anything irreversible

Steps run autonomously — they never stop to ask ​

A workflow runs unattended: once you start it, there is no human sitting in the loop to answer a mid-run question. So every task step is launched with a strict autonomy directive — it must carry out its objective directly on the input it was handed, and it is explicitly forbidden from asking for clarification, presenting a menu of options, or emitting NEED_INPUT. If a detail is under-specified, the step picks the most reasonable interpretation and produces the deliverable anyway.

This keeps bare chains flowing without careful prompting. A step like note this joke from 0 to 10 just scores the joke it received, rather than stopping to ask "what did you mean by note?" — which would otherwise park the step Blocked and pause the entire run.

Gates are exempt: they follow their own PASS/FAIL contract. And an approval checkpoint is the deliberate exception — the one place a pipeline is designed to wait for a person.

Released under the MIT License.