# A durable agent session is more than a saved chat

Durable Agents API sessions preserve a work context, but applications must distinguish task records, turn state, artifacts and acknowledgments during recovery.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-10
Original announcement: https://openai.com/index/introducing-the-agents-api/
Canonical URL: https://retrivium.ai/retrospectives/agents-api-durable-session-meaning/

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](https://openai.com/index/introducing-codex/) introduced cloud task execution. The [February 11, 2026 primitives](https://developers.openai.com/blog/skills-shell-tips) connected execution and context management. The [September 10, 2026 Agents API beta](https://openai.com/index/introducing-the-agents-api/) 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.

## Related reading

- [Identifying work across recovery](/journal/provider-request-id-trace-context/)
- [Documenting operation semantics](/journal/provider-api-contract-deprecation-migration/)