Workflows
No anonymous prompts buried in a graph.
A Workflow is a durable, multi-step run that composes your agents by reference. Every reasoning step is a named, versioned Agent — not an inline prompt nobody owns. Give it typed inputs, and it runs.
Every reasoning step is a real agent
A Workflow step that thinks has to reference an Agent — inline reasoning steps are rejected at deploy. That's deliberate: an inline prompt bypasses the escalation policy, memory scope, and relevance config the agent carries. Tool and code steps stay inline, because the rule is about reasoning, not plumbing.
Agent references pin like a lockfile
While you're drafting, a reference floats to the agent's latest published revision so you're always testing against current behavior. Publishing the Workflow freezes every reference to a concrete revision number. Improving an agent can't silently change a workflow that was already shipped.
Runs that survive waiting
Workflows are durable. A run can park on a human approval or a long-running operation and resume where it left off instead of timing out. Every run keeps its own history, with each referenced agent's execution nested underneath, carrying its own cost and latency.
How it fits together
Agents reason. Workflows orchestrate.
The split is the point. An agent stays single-turn, so it can answer on a channel and be reasoned about on its own. A Workflow is a first-class resource owned by an Application, and it's where multi-step orchestration lives — branching, parallel steps, and delegation across a roster of agents you can name.
Steps that reference an earlier output run in order; independent steps run in parallel
Approval gates and escalations pause the run with a full audit trail
Both agents and workflows expose the same typed input/output contract, so pipelines map over either
The rest of the build surface
Every capability is included on every plan — see pricing