Managed AI Agents: Who Saves Each Part of Your Task?

A managed AI agent can remember a conversation while losing the computer that held its files. It can also resume a task whose external action already succeeded. Before relying on session recovery, identify each kind of state, the system that owns it and the check that establishes whether it survived.

This reference provides a proposed responsibility inventory. It is not a vendor retention comparison or a claim that every managed service implements the same recovery behavior. OpenAI’s current documentation supplies concrete examples of why session, environment and application state need separate treatment.

Conversation state contains the messages and context an agent uses to understand its work. Execution state contains the computer, files and running operations that let it do the work. Business state contains the outcome the user cares about, such as an accepted document or an updated reservation.

One layer can survive while another fails. A message can say a report exists after its temporary file disappears. An external record can be updated even when a network failure prevents the result from reaching the conversation. Recovery should examine these layers independently.

The Agents API architecture guide assigns harness operation to OpenAI while leaving self-hosted environment lifecycle and file preservation to the application. That is one documented architecture, not a universal service contract. Use it to ask precise questions of the service you plan to adopt.

The following rows are a proposed inventory for architecture review. The final column states the responsibility to assign, not a default guarantee from a particular vendor. Add the actual owner, storage location and recovery check to your own copy.

For every provider-managed item, locate the retrieval interface and applicable lifecycle terms. For every application-managed item, name a component or team that can restore it. Shared responsibility is useful only when the handoff between the owners is explicit.

The self-hosted sandbox lifecycle guide says an agent session can outlive its environment. Reusing an environment ID does not restore files on replacement compute; preservation requires provider storage or snapshots. A saved session identifier therefore cannot stand in for a backup of the workspace.

Choose which outputs are disposable and which must remain available. A temporary build cache may be reconstructable. An accepted artifact may need durable storage with a recorded version. A process that was halfway through producing a file needs an outcome check before the file is presented as complete.

Also separate deletion from shutdown. The documented self-hosted lifecycle treats deleting a session and stopping provider compute as distinct actions. A cleanup routine should verify both outcomes and coordinate with incoming work so a late startup request does not leave unwanted compute running.

An external side effect is a change outside the agent conversation: a created booking, sent message or published file. The external system is the evidence source for that result. Store a durable operation reference where your application can find it even if the voice or agent session is replaced.

The GPT-Live session guide makes the same distinction for restored voice conversations: conversation restoration does not confirm pending backend completion. On recovery, query uncertain actions and suppress results that belong to an older task revision.

Use a stable application operation ID to connect attempts, results and read-back. A provider session ID groups conversation; it is not necessarily an idempotency key for a downstream action. Whether a repeated request is safe depends on the downstream operation and its supported duplicate-prevention mechanism.

The OpenAI Agents API decision guide covers adoption. This inventory is the deeper recovery check: which records will let your application distinguish finished, pending, cancelled and unknown work after the agent returns?

Retention asks how long data is stored and under what terms. Recovery asks whether the application can use the necessary state after a particular failure. A provider may retain logs without exposing the files or process state needed to continue a task. Conversely, a short-lived workspace may be reconstructable from durable inputs.

Our zero-data-retention feature reference owns the eligibility question. Do not infer privacy terms from this responsibility table, and do not infer working recovery from a retention period. Check each against its own documentation and configuration.

The AI-built app ownership reference helps with the larger handover. For a managed agent, the useful next step is smaller: demonstrate that the selected task can resume with the latest requirements, required artifacts and known external outcomes intact.

Use the blank responsibility worksheet to record owner, location, reconstruction method and evidence. Pick a controlled failure: a closed connection, an unavailable tool handler or replaced compute. Test one boundary at a time and retain the observed result.

Include a case in which the external action succeeds but its acknowledgment is lost. The application should check the authoritative record before retrying. Include another case where an output file never reached durable storage. The agent should report the gap rather than claiming the artifact is ready.

These are proposed checks; no managed service was fault-tested for this article. Before a production rollout, assign the unresolved rows to people who can exercise them. Our AI transformation service uses bounded workflows to make that review concrete.