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
- Create and publish a workflow that accepts Task execution context, then enable it.
- Open the agent in Resources → Agents and find Task workflows.
- Choose a Project and a published workflow you own. Set its Workflow entry node to the ID of its Start node.
- If the workflow uses a client device, select its Execution device. A fixed device in the workflow may supply this selection.
- Set Assignment trigger to Enabled and save. Assign a Task in that Project to the agent to enroll it.
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.
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.
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 use Decompose Task to create smaller child Tasks and their dependencies. The original Task's description stays intact. Its children become dependencies of the parent, and the workflow can wait for them before continuing. Repeating an accepted child plan returns the same Tasks.
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
| Node | Purpose |
|---|---|
| Task Agent Context | Load the admitted Task, pending human input, conversation history, relationships and saved workflow state. |
| Task Agent Comment | Post an agent reply once using a stable reply key. |
| Decompose Task | Create an accepted child plan and dependencies once. |
| Task Agent Checkpoint | Save the current result and choose whether to continue, wait, block or complete. |
| Read Document | Read full instructions with content and version evidence for downstream 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.