Agent Resumability, Explained: Sessions, Turns, Pauses, and Reconnects in TrueForge

Resuming an agent is not one operation. Production systems must distinguish reconnecting a stream, continuing a paused workflow, and recovering an uncertain external side effect.

“Resume” hides three different recovery problems

Long-running agents fail in more places than a conventional request-response API. A browser can disconnect while the server keeps working. A workflow can intentionally stop because a person, a client-side tool, or an OAuth flow must provide input. A downstream API can time out after committing a mutation. All three situations may be described as “resume,” but they require different state, evidence, and safety rules.

The first is transport recovery: reconnect to a still-running stream without duplicating events. The second is workflow continuation: create a new unit of work that answers a recorded pause. The third is effect recovery: establish whether an external operation committed before deciding whether to retry, compensate, or stop. Treating these as one mechanism creates the most dangerous kind of reliability bug—one that appears successful while repeating or skipping a real-world action.

The three branches deliberately end in different actions. A stream sequence repairs observation, a required-action reference continues the workflow, and an operation ID supports reconciliation; substituting one identifier for another creates duplicates or false completion.

Start with the TrueForge hierarchy

TrueForge documents a hierarchy of Agent → Session → Turn → Event → Delta. An agent is a reusable definition. A session represents one issue or conversation and persists across turns. A turn is one request-and-execution cycle that runs until it finishes or pauses. Events describe what happened during that turn. Some message events produce deltas while streaming; persisted event listings return the merged event rather than each live fragment.

This hierarchy matters because each layer answers a different recovery question. The agent definition establishes the configured model, instructions, tools, and limits. The session supplies durable conversational continuity. The turn provides an execution boundary with a terminal state. Events expose the ordered evidence needed to rebuild a client view. Deltas optimize the live experience but are not separate durable business facts.

TrueForge allows only one turn to run in a session at a time. Turns chain automatically, so the application does not resend the complete history on every request. Creating a new turn while another is still running cancels the active turn. That behavior is useful, but it means a UI must not translate every impatient click into a new turn without an explicit product decision.

Transport reconnection is not workflow continuation

A live turn uses a Server-Sent Events stream. Each streamed item carries a sequence identifier that the client can retain. If the connection drops, the client can subscribe again after the last processed sequence number. The server can then replay later events from the same running turn. A correct client stores events by event ID and merges deltas into their base message event, so retransmission does not duplicate visible output.

That is transport reconnection. The original turn has not paused for a business decision; only the network connection was interrupted. The server may continue executing while the client is absent. A reconnecting UI therefore asks, “Which events from this existing turn have I not rendered?” It should not create another turn or reissue the original user instruction.

Once a turn has finished, its persisted events can be read again to reconstruct the settled history. That is replay of evidence, not re-execution of the model and tools. The distinction is important for incident analysis: the same stored sequence should produce the same reconstructed view, but an attempt to run the task again may encounter different models, tools, credentials, and external state.

The figure separates durable hierarchy from delivery mechanics. Deltas belong to the live stream and are merged into base events, while sessions, chained turns, terminal states, and persisted events provide the settled record used after reconnect or restart.

Pauses are explicit runtime states

A turn can end with required actions rather than a final answer. TrueForge documents three important cases: a gated tool needs approval, a client-side tool needs a response, or an MCP server needs authorization. The terminal turn state identifies the pending items. The application satisfies them by creating a new turn containing the matching approval, tool response, or authentication continuation.

This is workflow continuation, not stream reconnection. The paused turn is already settled. The next turn preserves causal continuity by referring to the pending action and by chaining onto the session’s history. A single turn can surface more than one pending item, including pauses from parallel subagent threads, so clients should collect the complete required-actions set instead of assuming there is exactly one.

For approval and response pauses, the source event links the pending item to the model message that proposed the tool call. That link lets the application show the reviewer the tool name and arguments that created the checkpoint. It is also the basis for verifying that the continuation answers the intended call rather than a visually similar one.

Build a resumability contract

‍