Task Runtime

A disconnected client does not end the turn or Task

A user can add requirements, answer questions, and continue the same Task. Each input starts an execution turn that can contain several model steps and tool operations. A client connection only observes the execution in progress. It can disappear while the turn continues, and the Task can accept new input after that turn ends.

The diagram follows two inputs to one Task. The connection drops during the first turn, but execution continues in the background. Reconnecting restores observation. After the first result is stored, the Task remains and starts turn 2 when the next input arrives.

Object	Responsibility	Meaning of ending
Task	Goal, messages, workspace, state, and delivery records	The current outcome is recorded; later input can continue the task
Turn	Model steps, tool operations, and cancellation for one input	Execution stops advancing and enters finalization
Connection	Live text and tool-event delivery	An observation channel closes; background execution has not necessarily ended

Chat has its own conversation records and turn entry point. Team also maintains members and dependencies. These surfaces reuse agent capabilities without all becoming the same Task database record.

The shared turn acquires a task lock, reads existing state, prepares the workspace, assembles model input and tools, runs the agent loop, and finalizes the outcome. Web and Desktop supply storage, locking, abort registration, and transport implementations.

This boundary keeps decisions such as settling unfinished tool parts, saving assistant messages, and preserving tasks waiting for user input in one shared implementation.

The host still performs identity and quota preflight, establishes ownership, and saves user input before execution. MCP connection can run alongside agent setup and is awaited when tool assembly needs it, reducing serial startup work.

A task lock controls concurrent execution

Duplicate requests and queue redelivery may both attempt to start the same task. The runtime enters the loop only after acquiring its lock and registers cancellation control for the active run.

Web uses distributed coordination when configured; Desktop coordinates within its process. Locks control concurrent advancement. They do not remove effects already committed to external systems or guarantee exactly-once tool execution.

Reconnection restores observation; continuation starts another turn

A disconnected client does not require background work to stop while its execution host remains alive. Reopening the task first establishes whether a run is active, then reconnects to available events or reads stored results.

Web resumable buffers distinguish active streams, completed streams, and missing buffers. Starting a new turn clears the previous buffer so old events cannot enter the new run. The buffer restores observation progress; task records preserve confirmed work.

The Desktop Renderer and main process have different lifetimes. After a Renderer reload, navigation, or panel close, the in-memory StreamBuffer can replay prior events and continue delivering live events while the main process and turn remain alive. When the main process exits, the buffer disappears and recovery falls back to persisted messages, state, and files. This does not promise continuation of a tool at an arbitrary interrupted instruction, and replaying events does not execute tools again.

Stop enters the shared finalization path

Stopping propagates cancellation to the model and tools and settles unfinished message parts. Whether a request or script stops immediately depends on its implementation. Cancellation does not automatically undo file changes or external actions.

For cross-instance stopping, Web records cancellation state and notifies the owning worker. A check after subscription covers the window in which Stop arrived before the subscription existed. Desktop uses local cancellation but enters the same finalization logic.

The cause remains relevant: user cancellation, deployment interruption, and execution failure imply different recovery actions. Waiting for user input can end a turn while leaving the task waiting for an answer.

Persist the result before announcing turn completion

Shared finalization makes running messages usable as durable records:

Mark tool parts left pending after cancellation as interrupted.
Save the assistant message, accumulate usage, and update task metadata and the ending reason.
Where configured, save the usage anchor for later compaction and step and subagent execution records.
Enqueue background memory extraction when eligible.
Return the outcome to the surrounding runtime, which emits the turn-end notification and cleans up resources.

The ordering requirement is to save task results before announcing that the turn ended. Usage anchors and background memory extraction are auxiliary paths, not mandatory success conditions for task completion. File persistence belongs to the delivery service; assigning a terminal state does not copy every workspace file into delivery storage.

Recovery depends on confirmed facts

Continuation rebuilds input from saved messages, state, and the workspace. Intermediate output that was never persisted can be lost, and an external effect may occur before its local result is stored.

Reasoning can continue from available facts. File writes and external sends require checking their actual effects before retrying. Locks, stream buffers, and task records solve different problems and together support recovery; they do not supply automatic transaction rollback for every tool.

Capability	Web	Desktop
Concurrent execution	Cross-instance locks and registration, depending on deployment	In-process locks and registration
Active stream recovery	Reconnect through a configured replay buffer across API instances	In-memory `StreamBuffer` replays and continues live delivery while the main process remains alive
Evidence after process exit	Stored task messages, state, and files	Local SQLite, task messages, and files
Cancellation	Cross-instance notification and local signals	Local signals
External effects	Tool-specific verification or idempotency	Tool-specific verification or idempotency

Context engineering — rebuilding model input for continued work.
Product and platforms — deliverable persistence and execution boundaries.
Task orchestration — shared turns and host orchestration.
Cancellation and timeouts — signal propagation and timeout implementation.