Skip to main content
A task records the business outcome to achieve. An execution records one attempt to achieve it. A task can retain multiple implementations, retries and independent reviews. This page describes dispatch and acceptance for ordinary platform project tasks. Plugin-managed tasks use their owning app’s business actions and acceptance rules; see Business tasks and execution sync.

Dispatch and background execution

Create the task and its requirements, then ask the responsible Assistant to dispatch it. Targets can be configured and authorized external executors or Assistant members explicitly selected into a group project. Successful dispatch creates a conversation card and an attempt. The Assistant can finish its current reply while execution continues in the background. External executors admit work serially within a project to protect shared working files. Different group members can run in parallel; each member accepts one formal task at a time, and attempts for the same task remain serial. Task management does not supply an execution environment. Available Coding executors depend on deployment configuration; the current Computer executor is provided by Pro.

Task states

Successful execution, completed steps and 100% progress do not replace acceptance. Cancelling one run does not automatically cancel the business task.

Where results return

Saved results return to the responsible Assistant’s original conversation. When automatic continuation is allowed, the Assistant can check results or arrange follow-up work; open conversations display those replies. Reconnecting reads saved results and replies. Card updates and full replies can appear at different times. If execution has ended but no reply is visible, inspect result-delivery status in execution history.

Accept a task

The responsible Assistant can inspect results and decide. Users with project editing rights and access to the corresponding execution and results can also:
  1. Open Execution history and confirm the latest implementation succeeded.
  2. Compare actual outputs with the current requirements, opening or downloading deliverables as needed.
  3. Enter checks and a rationale, then choose Accept task.
  4. Confirm the task is Done and retain the associated execution and result record.
Acceptance is bound to current requirements, implementation and result versions. Changed requirements, a new implementation or replaced evidence invalidate earlier approval for the new work. Application-managed tasks follow their application’s decision flow.

Independent review

The responsible Assistant can delegate independent review and receive Pass, Changes required or Indeterminate. Review and implementation have separate records; a review report does not mark the task Done. Current independent review requires the Computer OpenCode executor supplied by Pro. It inspects fixed evidence without rerunning implementation tests or proving file authenticity. The responsible Assistant can separately use authorized tools to inspect actual files or rerun tests. Read the report’s limitations alongside its verdict. Once independent review has been requested, acceptance must reference the latest valid passing review. It cannot omit the review or reuse an older report.

Rework, cancellation and recovery

  • Request rework: record the problem and rationale. The task returns to To do; explicitly arrange another attempt. Earlier attempts remain available.
  • Cancel this attempt: cancel the selected run in execution history. This is separate from cancelling the business task.
  • Retry result delivery: resend a saved result that did not reach its destination. This does not rerun task tools.
  • Failed or unknown execution: inspect the attempt and existing files to establish what actually started before arranging another run. A missing reply alone is not a reason to dispatch again.
See Troubleshooting for specific recovery steps.