Before execution: define the result
Give the mission a deliverable, authorised sources and success criteria. The request becomes a self-contained Task instruction. The Dispatcher selects the supported execution mode; a Planner can turn steps into actual subtasks with dependencies.
During execution: understand the state
Inspect routing, execution, waiting, pause and completion in the task list. Open details to see the plan and its progress. A request for clarification needs an answer; waiting for a colleague is different from a failed attempt.
Delegate with a visible link
A specialist receives a child task linked to the parent. Its result feeds the parent’s synthesis. Follow responsibilities and waiting states rather than interpreting every tool call as a separate mission.
After execution: inspect the result
Read the output together with sources, tools, costs and events. Decide whether the deliverable meets the request, requires a correction or leaves a decision for a person. A completed model call alone does not prove that a file was delivered.
Recover according to the evidence
Durable state keeps a failed worker from erasing a task. The internal harness journals effects around tool calls. An uncertain external action can block automatic replay; recovery uses the evidence available instead of assuming it never happened.
Recover activity after closing the page
Task details and the chat panel recover the latest attempt, requested or effective pause, waiting state and next retry. New tasks retain the original request, provenance and a preview of progress messages. Late events do not replace terminal results.
The Working Set links inputs, produced files and deliverables. If a file exists but was not sent, delivery recovery can call the authorised transport directly without generating it again.
Bound the resources used
Optional limits cover tokens, cost and time across a task tree. Goal cycles can share consumption. The view distinguishes recorded usage, reservations and estimated remaining budget. Limits govern admission of new phases; a phase already running can exceed its reservation.
Amend, replace or verify before repeating
A clarification can amend work when the deliverable stays the same. A definition conflict does not create a second Task. An explicit replacement retains the link to the previous Task and waits for evidence of stopping; situations such as an active child or external wait prevent replacement.
A tool error returns to the agent with its outcome: rejected or unknown effect. It can correct the request or verify the effect. Recovery reuses recorded results and errors without making the call again; an uncertain operation does not automatically become safe to replay.
Your original request remains a reference
When a mission is created from a conversation, the server preserves the triggering messages and files. Supplementary context clarifies references and earlier constraints; it does not replace the original instruction with a summary.
Independent work leaves previous missions running or waiting. A rejected amendment does not silently replace a mission or stop unrelated work. Whether a mission can be changed depends on its state and the recovery capabilities of its engine.