Task execution: work division, deadline, Stop, and Effects

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 Task view shows its title with the breadcrumb under it, then the Task’s facts: its status, priority class, start time, Duration and Cost. The Request and the Final answer follow side by side, then the Task’s Effects. The History on the Agent’s Tasks tab uses the same status words: Completed, Failed, Stopped, Running, or Outcome not recorded when the retained evidence does not establish an ending. A continuation links to its parent Task.

Narrative, Executors, Timeline and Graph share the selected work and its side panel. Repeated work folds into expandable sets. Executors lists each Executor with its Effects and Duration. The Graph follows delegation. The Timeline, Work over time, gives each Executor a row with its Duration and a bar of when it worked, with Effect and Not completed marks. An Executor that never returned reads No response.

The Executor view follows the same order: its title, with a breadcrumb back through the Executors above it to the Task; its status, Duration, Cost and models used; its Request and Response side by side; then its Effects. Its Technical tab shows its model rounds and Tool Calls, with the selected call’s input and Tool Result side by side. The Executor also shows the routing policy accepted for its work, not a model-choice confidence score.

Duration measures elapsed work, so parallel work is not added twice. Cost estimates recorded provider charges in US dollars; it is not the Task credit charge. A missing cost reads Not available. An Executor’s Duration, Cost, Effects, models used and tokens include the work it delegated. Final-answer writing and the analysis that prepares the view do not appear as execution work or contribute to its displayed cost.

Both pages start on Narrative. Content loads in bounded sections as you scroll or expand it. Dates, times and numbers use your locale. Keyboard focus reaches rows and nodes; Enter opens the focused item. Escape closes open detail before returning to the Task view. Shared links preserve the selected view and item, but grant no access.

Refresh starts at one minute while the Task runs, with 30 seconds, five minutes, Off and manual Refresh available. Automatic refresh stops when the Task ends. A final bounded refresh can collect late records; use manual Refresh to check again later.

Read Effects and their evidence

The Effects section of the Task and Executor views counts by type the Effects whose type Duale AI estimates with confidence: Deleted, Removed access and Paid or signed. It does not add unlike types into one total. Duale AI does not estimate other types with confidence, so a call of another type, such as a read, a creation, an update, a message sent, a run or an access grant, counts as an Effect that is not available, and so does a call whose outcome Duale AI cannot read. The section then says that some or all Effects are not available. A call that hands work to another Executor is not an Effect: the delegated work shows its own Effects. Built-in Tools, customer-provided Tools and internal Tool Calls use the same per-call estimates.

Duale AI estimates each Effect from the Tool definition and the arguments recorded for that call, and shows a value only when it is confident of it. It then reads the call’s Tool Result, and shows the Effect only when it is confident that the call did what it intended. An Effect states its type, and Irreversible when the Effect cannot be undone; its card adds Data sent when the call sent confidential information or credentials. A call without an estimated type shows none of these values, even when it sent credentials. A value Duale AI is not confident of is left out, so a missing value is not evidence that no Effect occurred or that no data was sent. The same Tool can get a different estimate on another call.

The Effects section does not mark a call as not completed. When a call was refused, for example by a Connection that is disabled or blocks calls, by missing access, or by a Duale AI safety rule or limit, or when it did not run, the Technical view keeps the call’s own status, such as Failed, Blocked or Denied, with its reason. When no Tool Result came back, or the result does not show whether the call acted, Duale AI cannot tell what the call did; inspect the destination before repeating an action. A later successful call does not prove that an earlier Effect was reversed, repaired or compensated.

The agent’s intent is its own account. An estimated classification does not authorize a Tool Call, certify its safety, or establish that the destination changed. A Tool Result is a report, not independent proof of an Effect.

The evidence and access rules explain which original messages, reasoning and Tool content you can open. Tool reliability explains the separate confirmed success rate shown for customer Tools.

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.