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

The side-effect boundary remains outside the stream

Ordered runtime events can show that the agent proposed a tool call, that the harness attempted it, and that a response arrived. They cannot create exactly-once semantics in an arbitrary payment, ticketing, deployment, or identity system. A timeout can occur before commit, after commit, or while the downstream system is still resolving the operation.

Consequential tools should therefore accept an operation ID generated before the first attempt. If the downstream system supports idempotency keys, reuse that key for semantically identical retries. If it does not, add an application service that records the operation and reconciles against the authoritative system. When the result remains ambiguous, reduce authority and route to a human rather than allowing the model to infer success from narrative context.

This is the line between resumability and replay safety. TrueForge supplies durable orchestration state and evidence. The business application owns mutation semantics, state version checks, idempotency, reconciliation, and compensation.

The retry gate sits after—not inside—the runtime trace. TrueForge can show the attempted path, but the application must query the authoritative system before deciding whether another external mutation is safe.

Cancellation is a separate transition

TrueForge documents cancellation as stopping the running turn: it aborts the in-flight model request, waits for running MCP calls to finish, and force-stops a sandbox provisioned by that turn. The event stream closes with a terminal turn event. A later turn can continue the session and therefore sees the cancelled turn in its history.

“Cancelled” does not mean every external effect was rolled back. A running MCP call may have finished, and an external system may already have committed. Cancellation handlers should inventory outstanding operations, reconcile their status, and tell the next turn what is known, unknown, or irreversible. A kill switch that only closes the UI stream is not a system-level containment control.

A worked example: deployment approval

An operations agent prepares to restart a production service. Turn 1 gathers health data and proposes the action. The turn ends with an approval requirement linked to the exact tool call. The reviewer sees the service, cluster, proposed change, current health, and risk context. Their decision becomes input to Turn 2.

If the reviewer’s browser disconnects during Turn 1, the UI reconnects to that turn after its last sequence number. It does not submit another restart request. If approval arrives after the deployment state has changed, the application revalidates the target and policy before execution. It binds the downstream request to an operation ID. If the deployment controller times out, the agent queries the controller for that operation rather than calling restart again.

The session can survive all three interruptions because the design preserves three different anchors: stream sequence for presentation recovery, required-action identity for workflow continuation, and operation identity for effect recovery.

Test the failure boundaries

• Disconnect before and after every event type; verify the reconstructed stream contains no missing or duplicated logical events.
• Reconnect two clients with the same sequence checkpoint; verify both observe the same turn without creating more work.
• Return multiple pending approvals from parallel threads; verify the UI preserves every source-event relationship.
• Create a new user turn while another turn runs; verify cancellation is intentional and visible.
• Approve an action, then change the target’s material state; verify authorization runs again before execution.
• Inject a timeout after downstream commit; verify reconciliation prevents a duplicate mutation.
• Cancel during an MCP call and during sandbox execution; verify external and local effects are inventoried separately.

Version changes make continuation a policy decision

A durable session can outlive the agent definition that created it. Models are updated, instructions change, tools are removed, and policies tighten while a user is away. Automatic turn chaining preserves conversational history, but it does not answer whether a new runtime version should continue old work under old assumptions.

Record the effective agent specification or release identifier on every turn. When a session resumes after a material change, compare the pending work with the current capability envelope. A harmless support conversation may continue under the new version. A paused transfer proposed under an older policy may need to be cancelled and reconstructed. The decision should depend on the action and state, not merely elapsed time.

Compaction adds another reason to preserve explicit records. The model’s working context may contain a structured summary rather than every earlier message, while the complete event history remains persisted. Security-critical facts—approved amount, target resource, operation ID, stop condition—should live in typed application state and policy inputs instead of relying on a lossy conversational summary.

Recovery drills should therefore cross version boundaries. Pause a session, rotate the agent configuration, revoke a tool, change a model route, and then attempt continuation. Verify that the new turn can explain which state it inherited, which rules were re-evaluated, and why a pending operation was resumed, rejected, or rebuilt.

The operational rule

Resumability is not “run the same prompt again.” It is the disciplined continuation of a known state under a specific recovery contract. Transport recovery resumes observation. Workflow recovery supplies a missing decision or result. Effect recovery asks an authoritative system what happened.

TrueForge provides strong primitives for the first two and the evidence needed to implement the third. The reliable design keeps them separate, gives every transition a stable identifier, and never lets a fluent agent summary substitute for committed state.

References

1. TrueForge — SDK Concepts.
2. TrueForge — Use an Agent.
3. TrueForge — Create and Execute a Turn.
4. TrueForge — Subscribe to a Running Turn.

Editorial disclosure. This article reflects TrueFoundry’s engineering interpretation of the cited public materials as of September 14, 2026. Product capabilities are scoped to linked documentation. Examples and operating defaults are illustrative; they are not legal advice, an audit opinion, an independent benchmark, or a guarantee of security, safety, or compliance.

‍