Tasks, workflows and collaboration

A task records a job and its ownership. A session records an agent’s execution. A worker claims and advances work. A workflow declares application coordination. These identities can relate to each other while retaining different lifecycle rules.

Choose the execution shape

Shape	Use it for	Next step
Direct run	A request that the caller will consume now	Execution model
Dispatcher	Continuing existing durable sessions	Workers
Fresh-task worker	A queued job that needs a new session	Task API
Foreground child	A parent waiting for a specialist result	Sessions
Background child	Independent work with durable result delivery	Collaboration API
Workflow	Explicit roles, evidence and completion rules	Workflow API

Keep the claim identity

A fresh-task worker uses the claim it received when attaching the session. Do not reconstruct a lease from just the task ID. When the supervised handler owns completion, use complete_managed_task or fail_managed_task with that original claim; the managed boundary coordinates heartbeat generations and terminal mutation.

A human-input or approval pause can leave a task attached to its interrupted session. That is not a fresh unowned task. Recovery and the pending action’s owner determine how execution continues.

Design collaboration around evidence

Give each role a narrow job and explicit result schema. Decide whether the parent must wait, what happens when a child fails, and which tool effects each role can request. A parent-visible delegated-action reference helps find the child that owns an approval; it cannot approve on the child’s behalf.

Test child interruption, delayed result delivery, stale ownership and parent cancellation. A multi-agent answer that looks plausible does not prove that all required roles ran or that their evidence was retained.