Task execution: work division, deadline, and Stop

A Task turns one application request into one outcome. This page explains how a Task divides its work, how its deadline bounds that work and its answer, what Stop does, and how to read the Dashboard Task view. The Agent harness defines the terms it uses.

How a Task divides its work

A Task can delegate focused parts of its work, such as document research, Web research, a lookup in earlier Tasks, data analysis, or a review of a draft answer. The model decides when to delegate. Your application cannot choose, start, or address delegated work.

How one Task divides its workYour application submits one Task. The Task's main work can hand focused parts of the work, such as document research, Web research or a review, to delegated work inside the same Task. The results of the delegated work return to the Task's main work, which produces the answer or failure. Your application receives one outcome.

You can rely on these rules for all delegated work:

• It runs under the Task’s Agent Identity, with that identity’s access.
• It ends within the Task’s deadline.
• A Stop on the Task also stops it.
• Its results return to the Task, not to your application, which still receives one Task Outcome.
• Its model requests use the model pool of your Tenant, like the rest of the Task.

Use one deadline for each Task

Set the Task’s deadline from the time available for the whole request. The deadline is an absolute date and time; waiting or pausing does not move it. The SDK reference gives the default. Delegated work and Tool Calls in the Task share that deadline. A continuation has its own deadline, independent of the deadline of its parent.

The deadline is the only bound that you set for one Task. It is not a budget for tokens, cost, or provider requests, so split complex work into focused Tasks and enforce spend and concurrency limits in your application.

What happens near the deadline

Work can stop shortly before the deadline to leave time for the answer. Final-answer writing can then continue for up to five minutes after the deadline. It uses only what the Task already collected, and it starts no new research, no delegated work, and no SDK or MCP Tool Call. If the answer is not written within that window, the Task fails with TASK_DEADLINE_EXCEEDED.

A Task's deadline, final-answer writing, and StopYou submit a Task with an absolute deadline. The Task researches and uses Tools. When the work is done, or shortly before the deadline, it starts writing the answer. Final-answer writing can continue for up to five minutes after the deadline. The Task then completes, or fails with TASK_DEADLINE_EXCEEDED when the answer is not written in time. A Stop that takes effect during research or writing ends the Task as stopped.

The deadline does not prove that every operation has stopped. An operation that the Task already sent to another system can still finish and produce an Effect after the deadline.

Stop the Task you intend to stop

Use response.stop() or stop_task() for the Task you intend to end. The Stop reference defines permissions, acceptance, and the returned result.

• Stop is asynchronous. Acceptance is immediate, but it does not confirm that the Task exists or has stopped. Observe the Task Outcome.
• A Stop that takes effect ends the Task and its delegated work. It prevents new work in that Task.
• Stop does not recall work already sent out. A request already sent to a model provider, an SDK Tool Host, or an MCP server can still reach its recipient, finish, and produce an Effect. Stop does not undo an Effect.
• Each Task is stopped by its own ID. Stopping a parent does not stop its continuations. Stop each branch you intend to end.
• A Stop sent before the Task starts is not guaranteed. Duale AI applies it when the Task starts, within a limited retry period. The Task can begin some work first, and a Task that starts after that period runs.
• Revoking a provider key does not cancel accepted work. Requests already in progress can finish.
• On a very large Task, an accepted Stop can fail to take effect, and no error reports it. Confirm the Task Outcome, and block new Effects in your application.

Do not rely on Stop as the only control over External Effects. Secure integration covers the controls your application applies before an external change.

Read the Dashboard as an observed trace

The Dashboard Task view shows the work of a Task as Executors. Each Executor is one part of the Task’s work, with its model activity and its Tool Calls, and each Tool Call shows its outcome. A continuation links to its parent Task. Final-answer writing is not shown, and displayed Task usage excludes it.

The trace is evidence of reported activity. Use the Task Outcome to decide whether the request completed. Activity in the Dashboard alone does not prove completion or an external change.

Context continuity explains which earlier work a continuation uses and how independent branches behave.