Task workflows

Assign a Project Task to a named agent to start a workflow selected for that agent and Project. Your Task description, comments and agent replies stay in the Task thread. The workflow determines what work to do, when to ask for input and how to record its result.

Connect an agent to a workflow

1. Create and publish a workflow that accepts Task execution context, then enable it.
2. Open the agent from Agents, go to its Workflows tab and find Task workflows.
3. Choose a Project and a published workflow you own. Select its Published Start node from the available entries in the current release.
4. If the workflow uses a client device, select its Execution device. A fixed device in the workflow may supply this selection.
5. Set Assignment trigger to Enabled and save. Assign a Task in that Project to the agent to enroll it.

The form shows the published release, workflow state, device connection and required device capabilities. Use Refresh checks after reconnecting a device or changing its settings. You can save while the device is offline; it must reconnect before client commands can execute. The checks cover direct nodes in the published workflow. Follow its subflow links to inspect nested steps, and verify any target chosen at runtime. Provider sign-in and local device consent still belong to the selected runtime.

For an existing Task, open its details and choose Assignee. Search by the agent's name and select its Agent option. The picker lists active agents you can see that have access to the Task's Project. You can also select Tasks in a list and use Assign. Bulk assignment checks each Task's Project access separately and reports Tasks it could not change.

You must manage the agent, have Project write access and be allowed to run the workflow. The agent needs its own access to the Project and any Documents, tools or device used by the workflow. A Task assignment does not grant those permissions.

One route applies to an agent and Project. You can configure additional Projects independently. Edit workflow behavior in the workflow editor and keep long reusable instructions in Documents.

Tune the workflow

Open Configure on the agent's Project route to adjust the workflow, entry, assignment trigger or device. The setup block links straight at the release the route actually runs. Open release vN exactly as published shows that graph read-only. Edit the Draft it was published from opens the main Draft or the branch Draft that release came from. That Draft may already contain unpublished changes; it is not a copy of the release.

Open the linked workflow to edit its behavior:

Test the changed path and publish the workflow when it is ready. Draft edits do not affect published work. A new publication applies to newly admitted executions; existing tasks retain their original release and saved state. Instructions already saved in a task's checkpoint also remain unchanged.

Continue in the Task thread

Reply to the Task when the workflow asks for input. Comments from people who can currently edit the Task are collected for the same execution; comments arriving while work is running remain available for its next turn. Agent replies do not trigger an endless conversation with themselves.

A comment can wake an execution waiting for input. It does not grant broader access, reopen completed work or clear a blocked execution. Mentioning an agent without assigning the Task does not enroll it. Reopening a Task, or assigning active work back to its agent, can resume completed work through the same conversation and saved state, subject to current permissions.

Each comment shows where it stands: Waiting for the role that has not read it yet, or Read by the role whose turn consumed it. The role is named by its agent, with the workflow it runs when you can open that workflow. A comment addressed to several agents shows one of these per role.

Reassigning the Task moves a comment no turn has read to whoever takes over, and the badge names the role now holding it. That holds each time the Task changes hands, including when it comes back to a role that was handed the comment before and passed it on unread. A comment a turn already answered stays with that turn as its evidence and is never handed to it again. When a turn stops without recording a result, the input it was given counts as unread again and follows the Task with the rest. Agent work counts those unread comments separately from the task updates queued beside them.

A comment that names an agent stays with that agent while it is being consulted on the Task, rather than following the assignment elsewhere. A comment naming the agent that currently holds the Task is that role's queued input like any other, so handing the Task on hands that comment on with it.

Approve what the workflow may do

Assignment admits the work; it does not widen what the agent may do. The agent acts with its own permissions on the Project, Documents, tools and device the workflow uses, and a comment in the Task thread is not an approval.

Put the decision where it is recorded:

• An owner decision inside the run belongs in a Ask a person step placed before the step that acts. The run records who answered and when, and an unanswered gate fails on the suspension timeout instead of proceeding.
• A command on a device is approved on that device. Client nodes require device approval by default; see Client Workflow Nodes for the approval and timeout settings. Approving one command approves that command only.
• Standing rules for a codebase belong to that repository's own guidance and to the Documents the workflow reads, not to the Task description. Workflow node text and Task comments are content the agent reads; they grant nothing on their own.

Inspect progress and recover blocked work

Open the Task's details and find Agent work. It shows the workflow's summary, execution status, pinned release, latest run and number of pending task updates. Open the latest run to inspect its node results. Use Refresh to renew the display; the last check time is shown. Private workflow details require access to that workflow as well as the Task.

Where the agent recorded them, the panel also names what the last turn recorded: the recorded provider session, its worktree and the model, plus the device the task route is bound to. The session and worktree are copyable, so an abandoned Claude Code or Codex conversation can be found by hand. They are a record of the last turn, not a promise about the next one. A turn that recorded none shows none — a checkpoint replaces the saved state, so an association that was not carried forward is genuinely gone rather than hidden. Nothing else from the checkpoint is shown.

Reassigning to another device still waits for the previous task turn and its Subflow/Loop work. A timeout or cancellation request does not prove the device stopped. Uncertain client or browser commands retain the claim until the owner checks their effects and records recovery evidence. That confirmation applies only to the inspected turn; later commands need their own settlement evidence.

If work needs attention, the accountable owner can choose Review recovery after the latest run has ended. Check that the previous command has stopped and account for any external changes. Record that evidence, confirm settlement, and select Resume agent work. Resuming keeps the saved checkpoint, with the recorded provider session in it, and the pending comments. It does not decide which session the next turn uses: the workflow decides whether its next provider turn continues the recorded session or starts a fresh one. On a registered device, a session can be continued only if that device started the conversation itself, in the same working directory. A conversation the device ran before its client began recording that, or one started by hand at a terminal, is refused as a resume even though the checkpoint still names it, and the workflow has to start a fresh turn. This does not mark the Task complete.

When there is nothing left to resume — the attempt is exhausted, or its route has been withdrawn — select End execution instead. It records that this attempt stopped, releases the device it still holds so queued work can start, and keeps the checkpoint, provider session, counters and pending comments. Ending an execution is not delivery: the Task's own status is unchanged, and the same settlement evidence is required.

When a separate recovery workflow you ran has produced a verified replacement checkpoint, select Apply recovery proposal and name that workflow run. The replacement is read from that run's own result and never from the browser, so the run has to be one you started for this execution, that finished successfully, that ran a published release of a workflow you can still open, and that returned a replacement checkpoint for the checkpoint version currently saved. The recovery workflow does not have to be the one the task is bound to. Applying replaces the saved checkpoint wholesale with what the run declared, keeps pending task comments and the release selected in the same form, and resumes the work. The same settlement evidence is required. The receipt records which run was applied and a digest of what it contained. Applying does not establish that the workflow's own checks passed; the resumed run still has to run them.

Before applying, select Check this run. It resolves the run you named and shows the workflow and release that produced it, when it finished, the summary it declared and which checkpoint fields the replacement would drop, change, add and keep. Field names only; saved checkpoint values are never shown. Checking applies nothing and needs none of the settlement evidence applying requires, so you can check the run before writing down what you checked. Name a different run and the check clears, because it no longer describes what would be applied. A run that cannot be applied cannot be checked either, and the check uses the same permissions the apply would use at that moment: if the Task has been unassigned, you or the agent have lost access to it, or you can no longer open the recovery workflow, the check is refused. When the task route has moved to another workflow, select that workflow's release in the same form before checking, as you would before applying.

If the saved checkpoint has moved since the proposal was produced, applying refuses and the recovery workflow has to run again against the new checkpoint. A check is what the run declares at the moment you ask, not a promise that applying will still be accepted.

If a submission is lost and you apply the same run again, Review recovery reports the result it already recorded rather than refusing or applying it a second time. That answer is checked against your permissions at the moment you ask: once the Task is unassigned, you or the agent lose access to it, or you can no longer open the recovery workflow, the repeated submission is refused and nothing is changed. End execution still works for a withdrawn route.

Recovery keeps the pinned release by default. If a newer published release is available, the owner may explicitly select it after checking that it can continue from the saved checkpoint. An outdated form or changed permissions will refuse recovery; refresh and inspect the new state before trying again. Posting a comment alone does not clear a blocked execution.

The first run selects a published workflow release. Later turns keep that release, so publishing an updated workflow does not change work already in progress. Current permissions and the Task's assignment are still checked.

Work with dependencies

A workflow can attach a governed Save to workspace tool fixed to Task creation and a Link Resource tool to an AI step to create smaller Tasks and their dependencies. The tool configuration fixes authority-sensitive fields such as project, status, and assignee while the model supplies the authored content.

When a workflow waits for children, it releases its selected device after its current run has ended. Other enrolled work can then use that device. A failed run with uncertain external effects stays blocked until its owner reconciles what happened; a timeout alone does not make the device safe to reuse.

Workflow nodes

These nodes require a valid Task execution where applicable. Merely typing a Task or agent ID into a manual run does not create that authority. Inspect run history for actual node results and failures.