In this analysis
Continuing a durable session is different from replaying an operation whose effects may already exist.
Saving a transcript preserves what was said. A durable agent session must also let an application understand what work exists and how it can continue. The Agents API beta made this difference visible by offering a managed session rather than only another text-generation request.
The sequence reached beyond conversation storage
The May 16, 2025 Codex launch introduced cloud task execution. The February 11, 2026 primitives connected execution and context management. The September 10, 2026 Agents API beta then described durable sessions. These dated steps support investigating continuity of work, without implying that every kind of application state is automatically durable.
Several records can survive independently
Consider a job that reads source files and creates a comparison table. A conversation item can survive while the table is unavailable to the application. The table can exist while its source revision is unclear. An application can retain a task identifier while failing to distinguish ongoing work from a completed result.
Durability must therefore be evaluated against named objects. The user request, service session, active turn, generated artifact and application acknowledgment are related but not interchangeable records. Persistence of one cannot prove persistence or correctness of all the others.
Continuation is not unconditional replay
When a client reconnects, continuing a session differs from rerunning its last action. A previously submitted operation may already have produced a side effect. Replaying it without inspecting current state can create another result rather than recover the original one.
The appropriate recovery policy depends on the documented operation and available state. Do not infer exactly-once behavior from the word durable. Instead, preserve enough identifiers and outcomes to determine what the application can actually establish after a failure.
Build a recovery-state fixture
Use an illustrative comparison job and interrupt the client at different boundaries: before an artifact exists, after creation and after the application records its receipt. Resume through the intended interface and inspect which object is visible.
The acceptance question is whether the application can reconstruct one coherent job without inventing a completion state. A missing artifact, a duplicate artifact and an unacknowledged existing artifact require different handling. Keep these outcomes separate rather than reducing recovery to a binary reconnect success.
The retrospective distinction
The beta made persistent managed work a product capability. Application durability still depends on the objects it stores and the decisions it makes when information is incomplete.
A useful session record connects source identity, service state and accepted deliverables. That is stronger than a saved conversation because it describes recoverable work, while remaining narrower than an unsupported promise that any interrupted operation can be safely replayed.