Workflows

Use a Workflow for a repeatable process with explicit steps, decisions, and outputs. Adapt an installed Playbook, or build a process once you know how the work should flow. You do not need to build a Workflow before delegating your first Task.

Step types

Add steps in the builder

Loop is offered only after a step that returns a List. Connector choices depend on your access, and Classify shows an unavailable state when the workspace's AI settings cannot support it.

A verifier is an optional check configured on a step, not another step type. Approval steps and verifier checks have different purposes: one asks for a decision, while the other evaluates the output against requirements.

Design the workflow

Arrange and configure steps

A workflow is a definition: a named graph of steps connected by edges, owned by a workspace and usually scoped to a project. You open the builder from the Workflows page, which lists the definitions in your workspace and links each one to its graph, or by searching for the workflow in the command center.

The builder renders the graph top to bottom. Each root becomes its own vertical chain, branch steps anchor in that chain before fanning out into horizontal route columns, and each route continues downward in its own local chain.

You create and edit steps in the shared step modal, insert new steps from the connector menus between cards, and reorder linear runs vertically. If a branch fans out wide enough to need more space, only the graph canvas scrolls horizontally.

The builder also gives you a quick read on the current draft before you scan the full graph. A compact overview shows the workflow's effective lifecycle and step count. Step cards are an overview: each shows its type, output, name, description, and one short line such as its Agent, approver, Connector tools, or number of questions. A card warns when required configuration is missing. Open a step to see and change its full configuration.

Prose fields still read as prose, branch routes stay as ordered route descriptions, and document outputs stay as structured file lists. Members who can read workflows but cannot manage them open the same Builder and Settings pages with the saved configuration locked in place. They can open a step to read its Agent, instructions, Connector, HTTP request, approver, Classify questions, and loop settings, while the add, save, reorder, delete, and publish controls stay hidden. Changing the draft still needs workflow management access, and the Budget tab keeps its own budget permission.

The saved definition records the steps, their connections, and configuration rather than their screen positions.

You assign the agent, optional autonomy ceilings for the work and verification, and an optional verifier as you configure a step, so the graph carries the choices that are specific to this process rather than leaving them to be decided later.

Choose the output the next step needs

An Agent, Document, Connector call, or HTTP request step can return Text, a Number, or a List of text and numbers. Text is the default, including for existing Workflows. Choose List when the next step should process several items separately. Objects and nested lists are not supported.

Task Machine checks every submitted result against the step's selected type. A mismatch goes back to the agent with the expected form so it can correct and resubmit while it is still working. Rejected results cannot start verification or later steps.

Later Agent steps receive the complete saved values, with short previews in their instructions. Publishing keeps each step's output type with that version, so changing a draft does not reinterpret earlier results.

Classify answers your questions in one step

Use Classify when you need a consistent set of questions answered about each request, such as its department, impact, and need for follow-up. Add one to ten named questions and optional shared context. Each question has instructions and one answer type:

• Choice selects from two to twenty named options.
• Score selects from two to ten levels ordered from lowest to highest.
• Yes/No answers a yes-or-no question.

All questions share one AI evaluation. The output is Text containing the question and answer pairs in your configured order. Classify needs no Agent assignment and leaves the Task's assignee unchanged.

To route by an answer, select one Choice or Score question, choose a destination for every answer, and set Minimum confidence (%). Score routing uses the most probable level rather than a rounded average. Below your minimum, When uncertain follows its selected step or stops the Run. Confidence is a routing condition, not proof that an answer is correct.

Classify uses workspace usage and current AI processing restrictions. If its complete input is too large, it stops before making an AI call rather than silently shortening the input. Provider failures require an explicit Retry. An accepted response can still incur usage when its answers are invalid or the Run is cancelled.

Loop processes a list in order

Add Loop after a List-producing step, then add the steps that run for each item from the Loop card. Edit loop steps in the step menu opens the full canvas for branches and reordering. Select one Text- or Number-returning body step as the result. Every body path must reach it. The body can include ordinary steps, branches, and human decisions, but cannot contain another Loop.

Items run sequentially inside the same Run and Task. The body receives its current item and position, and Loop collects one result per item in the original order. Duplicate values remain separate items. An empty list finishes without running the body.

For example, an Agent can produce a list of customer requests, and the Loop body can use Classify to answer the same questions for each request. The result is a list of question-and-answer text entries, one per request. Downstream steps wait until the full list is complete.

You cannot connect Loop to Text or Number, or change a connected producer away from List. If an item fails, the Loop keeps going: that item's result becomes its error text, such as Error in Classify the request: …, in its original position, and the Run continues with the full list. The Loop then shows Succeeded with failed items with the number of failed items. Cancellation stops further work without undoing actions already performed.

Branch conditions route by meaning, not by code

A branch step chooses its path by reading conditions written in plain language. Each route out of a branch carries a condition, a sentence describing when that route should be taken, and the conditions are ordered by a sort value.

When the branch is reached, an evaluator agent reads the conditions in that order and the first one that passes selects the route. The ordering is fixed, while the evaluator's judgment remains model-based. You write the conditions and order them. You do not write rules or expressions.

Choose the review boundary before publishing

Put a human approval before the consequential action it controls, such as publishing a document. A sign-off after publication cannot prevent that publication. For agent and document steps, write outcome requirements and choose a verifier when an automated check would help. Human decisions and verifier checks determine what passes, retries, pauses, or fails.

Standard retries bound transient failures

The builder does not expose general per-step attempt and backoff controls. Worker failures and timeouts allow three retries with exponential delays beginning at five seconds. Missing required documents get one rework attempt before the run fails.

An ordinary verifier FAIL sends the work back with feedback, allowing two rework attempts by default before pausing for human review. UNCERTAIN pauses for review immediately, and a flagged constitution violation fails the run immediately. A malformed verdict is rejected during submission so the verifier can correct its format in the same agent Run. Only an accepted FAIL verdict follows the rework path.

Step configuration supports a max_verifier_retries override, but that is separate from general retry-policy authoring. Budgets and retries explains these boundaries.

Validation checks the graph before you rely on it

Validate the draft before relying on its connections. The builder checks these rules:

• Exactly one start step in the main graph and each Loop body.
• Connections stay inside the same Workflow and body.
• Outgoing routes have distinct ordering.
• Ordinary steps have at most one outgoing route.
• Branch conditions have real connections to their destinations. Naming a destination alone does not connect it.
• Classify routes cover every answer in the selected routing question.
• Loop follows exactly one List-producing step and has a reachable Text or Number result on every body path.
• Human approval steps can have an approved route and an optional rejected route.
• Terminal steps need no outgoing connection.
• No cycles, loop-back connections, or nested Loop bodies.

Validation reports the problems and their affected steps or connections without changing the graph. Keep the definition as a draft while you correct them.

Publish the process

Publishing freezes a draft into an immutable active version

When a draft is ready, you use Publish version, and that is what turns a graph you are editing into one a run can follow.

Publishing first validates the source graph, then copies the whole definition, including its steps, edges, and branch conditions, into a new active version with its own identity and a published timestamp.

The current workflow stays editable as the draft you were already working in, and that draft records a link to the version it produced so the next publish chains to the one before it. Publishing makes a version runnable. It does not itself start a Run or add a schedule.

Use Version in the page header to switch between the Current draft and immutable published versions, listed newest first. Choosing a version does not publish it or change the draft.

Open one of those published entries and the builder switches into a read-only historical view with Viewing version N at the top and Back to current to return to the editable draft.

This copy-on-save design is what makes a published version immutable: a run always executes against the exact version it started from, and editing the draft afterward never reaches back and changes a graph a run already followed. Changes always happen in the draft you publish next.

You keep refining that draft and publish again when the next version is ready. Each published version is a frozen snapshot, and the link chain is the history of how the process changed.

Scheduling stays on the same workflow identity, so future schedule firings keep resolving the latest published version even as you keep editing the draft. Only an active published version can be started. See workflow execution for how a run of one proceeds.

Workspace workflow playbooks use the same graph shape but sit outside the normal runnable list. When one appears in the command center, duplicating it creates a fresh draft with the playbook's steps, edges, and branch conditions copied in, so you can adapt the graph before publishing it.

An agent can propose a workflow

An agent authors workflows as well as runs them, but its profile can gate workflow creation behind your approval.

When it is gated, the agent proposes the definition instead of saving an ordinary draft: the graph is created in a held state with the agent's rationale attached, and it waits in your inbox and on the Proposed tab of the Workflows page, beside the active and archived definitions.

From there you open the proposal to preview the graph it drew: its steps and the order they run in. You can then approve it into the workspace or reject it with a reason. When the effective creation gate permits direct application, the proposal publishes a runnable version without waiting for human review.

Agents can also propose a complete revision to an existing workflow. While review is pending, its current draft and runnable version remain unchanged. Approval rechecks the submitted base and references before publishing the candidate version. The separate workflow-update approval gate can also permit direct publication.

From here, workflow execution describes how a run of a published workflow advances and what it records.

Execution and recovery

Once a workflow is authored in the builder and published, running it is what makes the process repeatable: a run is one execution of a published workflow version, the place where a designed graph turns into actual work with a result for every step.

This page describes how a run starts, how it advances step by step, and what it records, so the shape you drew becomes a loop you can actually start.

Every run belongs to a task

A run is always anchored to a task, so there is one visible record of what happened even when work runs itself. The task is the papertrail (see Tasks): its timeline is where a run's progress, questions, approvals, and final summary belong.

You start a run against an existing task, or start it from the Workflows page, where a manual start creates a backing task in the definition's project and runs beneath it. A task can have only one queued, running, or paused Workflow run. Another start is refused rather than queued behind it. Earlier finished runs remain in history.

A cancelled or archived task cannot start another workflow run. Cancelling or archiving the task also stops an active workflow and closes its waiting questions and approvals. Earlier results and decisions remain in its history, and stopping one scheduled task leaves the workflow and its schedule available for future work.

A scheduled workflow has one stable root task in Tasks. Each scheduled firing creates a backing task linked under that root. The root stays on the Tasks list and board, while its Schedule runs tab opens the generated task details without adding repetitive cards to the board.

A generated scheduled task still keeps its own complete Activity, Runs, questions, approvals, artifacts, and execution history. Starting a workflow against a task that already exists does not change that task's origin. Either way a run is never orphaned from a place you can look.

A run also records its workspace, its project, the exact published workflow version it came from, who started it, and its status.

A run is queued, running, paused, succeeded, failed, cancelled, or timed out. Its current step shows where it is in the graph.

A generated task follows the run's result: success completes it, failure or timeout blocks it with the recorded reason, and cancellation cancels it.

A task you supplied keeps its own status. Your later task status decisions remain in force rather than being replaced by an earlier run's result.

As the run advances it writes events onto the task timeline: the run starting, each step starting and finishing, a step waiting on agent work or a human, and the run reaching its result.

The command center can find workflow runs by name, status, ids, and failure details. Opening a run from search takes you to the backing task's Activity tab for current execution and steering context. Open Runs for the complete execution history.

If a run is not terminal and your role can run workflows, search also offers a cancel action that stops the run and any workflow-owned worker work.

Start from service events

Open a published Workflow's Triggers tab and choose Add trigger, then Event. Select an installed Events Connector, or set one up in the same dialog, and choose the service's events and actions.

Matching events can progress concurrently, including events for the same Workflow. They enter in arrival order across your workspace and share its separate Event runs capacity. A Workflow waiting for a person or access holds no Event Run capacity. Answering the question or allowing access keeps the same attempt, which continues once capacity and its other requirements allow it.

The Triggers tab shows Event runs reserved by each Trigger and Waiting events separately. Choose View event activity in the Trigger's menu to inspect recent events, their received times and states, alongside the workspace's occupied and total Event capacity. Earlier events load as you scroll, and the view updates as work progresses. Received event contents and connection secrets stay out of this history.

A run advances step by step through the graph

Workflows use an acyclic graph with one start step. When a step finishes, the Run follows its outgoing connection or the route selected by Branch, Classify, or human approval. Conditional routes can rejoin. Loop repeats its own body without adding a loop-back connection to the graph. A step becomes ready when its selected incoming dependencies have succeeded. When nothing remains to schedule, the Run succeeds.

If a step fails after its retry or decision path is exhausted, the run fails there and records why. Loop-back edges are not supported.

When a step hands work to a worker or pauses for a person, the run stops at that step and waits. When that work completes, Task Machine resumes the run from where it left off and carries it to the next wait or to the end.

Resuming is safe to repeat: a run that is already finished is left untouched, and a step still waiting on agent work or approval is left waiting.

Agent steps run in Cloud or on Local Workers

An agent step runs an agent against the prompt and context the step carries, using the same Cloud or Local execution path as a directly assigned task (see Tasks).

The run assigns the step's agent to the backing task, passes the step's explicit context references into the compiled prompt, starts the work when compatible execution capacity is available, and waits. Readable document references are injected into the job's knowledge context.

File, task, and memory references travel with the job as context hints for the agent. When the work succeeds the step captures its output and the documents the agent produced.

When it fails or times out, Task Machine retries that worker work with a bounded exponential backoff before failing the run, and when it is cancelled the run cancels at that step with the worker's reason. Branch and document steps run the same way, each with a prompt shaped to its job.

A branch asks its agent to evaluate the conditions. A document step asks its agent to create the configured Library documents and checks that every required document exists before moving on.

Branch steps route by evaluating their conditions

A branch step chooses its path at run time by checking its conditions in order. Each condition can name its own evaluator agent. When it does not, the branch step's agent evaluates it. The first condition that returns PASS selects its route and the later conditions are not run.

If every condition returns FAIL, or no conditions were configured, the branch succeeds without opening an outgoing route. Its step overview shows No path matched and explains which case occurred. The step result retains any conditions checked and their verdicts. Evaluation order is fixed, but each condition is a model judgment and can produce a different verdict on another run.

Human decisions and verifiers control progression

For an Agent or Document step with a verifier, the verifier checks the output against the outcome requirements in the same Task working folder.

Choose a different Agent as the verifier. The producing Agent already checks its own work inside its Run, so a verifier that is the same Agent is self-review, not independent review.

Each rework attempt keeps the verifier's recorded feedback, including when Task Machine resumes after an interruption. Escalation opens a verifier review in Inbox and pauses for a permitted person's decision. A reported constitution violation fails the Run without corrective retries.

A human approval step pauses the run, opens an approval request routed to whoever the step's scope authorizes, such as a member, role, project editor, or required-permission holder. It holds until a permitted person decides.

Approval resumes the run down its approved route, and a rejection takes a separate rejected route when the step was wired with one, or fails the run when it was not.

An ask-human step pauses the same way to ask a plain question rather than a yes-or-no decision: it opens a question on the backing task, routes it to a chosen member or, by default, to whoever started the run, and resumes carrying the person's answer once they respond.

Both human pauses land in your Inbox and on the Task timeline and also notify by email.

If a linked approval is cancelled or superseded, or its question is withdrawn, the next advance fails the step with the reason instead of waiting for a decision that can no longer arrive. Task Machine keeps the original request and never substitutes a replacement approval or automatically creates another request for the failed attempt. Inside Loop, that item's result becomes the error text and later items continue.

A run records each step's result

Beneath a run, each step attempt is a step result: a record of which step ran, the attempt number, its status, the structured input and output, the decision a branch reached, and timing. When a step reaches outside itself, the step result links to the agent work, approval or question, and working folder involved.

Agent-step output also carries the agent-run reference, the knowledge context that was injected, and any documents linked back to that job, so the run can show what the agent produced without duplicating document state inside workflow logs.

A verifier check on a step records its own outcome against that step result, holding the PASS, FAIL, or UNCERTAIN verdict, the reasoning behind it, and the issues it found.

Read together, the step results are the spine the task timeline, the audit trail, command-center workflow search, and worker transcripts use to explain how a run reached its result.

Run usage includes all Worker attempts and direct Classify charges, including earlier retries and Loop items. Pending or unavailable amounts remain explicit. Opening a different page of results does not change the total, and refreshing usage does not repeat execution.

Watch a run from its task

The backing task's Activity tab shows current execution alongside steering history. Its Runs tab keeps the complete execution history. Opening a workflow run brings up the run view, where you can inspect its steps, decisions, and transcripts.

Read the Run view from its overview into the step that needs attention:

• Top summary: status, progress, and usage across the complete Run.
• Left stepper: steps in order, their statuses, and the current step. Select a step to inspect it. More steps load as you scroll.
• Right panel: the selected step's attempts, output, timing, working folder, verifier verdict, routing decision, documents, and transcript.

Selecting a Loop shows its items directly, including completed and remaining work. Open a specific item to inspect its steps and results in a separate modal, even when the Loop has only one item. Closing that modal returns you to the same step and scroll position in the Run.

List outputs, decisions, and audit records also load more rows as you scroll. A shortened preview leaves the saved value intact.

It uses the same expandable tool calls, reasoning, and output as Chat. The selected step's newest events load automatically, and earlier events load as you scroll up, without loading every step's complete history.

Questions and approvals the step is waiting on surface here too, and when a request is routed to you, you can approve or reject it inline without leaving the task. Everything updates live as the run advances, so a run you are watching moves on its own.

Retry after correcting a failed attempt

Open a failed Workflow's details to inspect its failed step and earlier attempts. When your role permits it, Workspace access is operational, and the backing task is neither cancelled nor archived, Retry can return a failed or timed-out Workflow to running with fresh attempts for steps whose latest attempts failed. Earlier attempts remain in the history.

Correct the cause first, such as missing access or unclear instructions. Retry is refused while another Workflow run is queued, running, or paused on the same task. Retry returns an automatically blocked generated task to In progress only while that exact run still owns its blocker. A blocker you recorded yourself stays in place.

Retry does not undo external actions, erase earlier charges, or replace the published version the Run was following. This action is not a way to retry a succeeded or cancelled Run.

Stopping its schedule is a separate choice that prevents future occurrences while preserving Runs already created.

What execution does and does not cover today

Workflow Runs support Agent, Branch, Classify, Loop, Document, Connector call, HTTP request, Ask human, and Human approval steps, with verifier checks on configured steps. Loop runs one item at a time and cannot be nested. Conditional routes can rejoin, but loop-back connections remain unsupported. Worker failures and timeouts use bounded automatic retries. Missing required documents receive one rework attempt. Verifier corrective retries default to two.

Authored definitions can configure that limit, but the builder does not offer a separate retry-policy control. See budgets and retries for how these bounds fit the larger control story.

Resolve waiting questions and approvals in Inbox. For ready-made setups you install rather than draw, see Playbooks.

Repeat a proven process

Capture a handoff after it has produced useful work. State each step's inputs, output, and review boundary before adding another branch. Give each cycle room to finish within a deliberate budget. Use Schedules for timing and review a few real cycles before increasing volume.

Follow a Workflow on its Task

The Runs tab of a Task that runs a Workflow leads with one card titled by the Workflow, with the state of the run and every step in order. Branched paths remain grouped through labels and indentation, and the step the run is at carries a badge. Task Machine renders at most the first 25 steps in one view and says when more exist, which keeps large workflows readable without implying the workflow itself was shortened.

Choose Run details on the card to open the run and read each step's output. A Task that has not run a Workflow has no such card. See where a Task stands describes the card.