Manage OpenAI Sessions and Resumable State

OpenAI agent conversations can continue through application-managed history, SDK sessions, server-managed conversation/response identifiers, or serialized run state for interrupted work. Pick one conversation strategy per flow. Approval state is different from a new chat turn: resume the paused run so tools, budgets, and decisions remain connected.

What will you be able to do?

You will choose a continuation model, persist a simple SDK session, and explain how approval checkpoints differ from conversation memory.

Which strategy should you choose?

Strategy	State owner	Good for
result.to_input_list()	application	explicit replay and custom storage
SDK session	your storage through SDK	convenient persistent history
conversation ID	OpenAI service	server-managed state across workers
previous response ID	OpenAI service	lightweight response continuation
serialized run state	application/provider SDK	paused approval or interruption

Mixing replayed input with server-managed continuation can duplicate context. Document the selected strategy in the conversation record.

How do you use a local session?

session_demo.py:

python

import asyncio

from agents import Agent, Runner, SQLiteSession


agent = Agent(
    name="Support explainer",
    instructions="Answer only from facts supplied in this conversation.",
)
session = SQLiteSession("demo_conversation_1")


async def main() -> None:
    first = await Runner.run(
        agent,
        "Ticket T-100 concerns a duplicate charge.",
        session=session,
    )
    print(first.final_output)

    second = await Runner.run(
        agent,
        "Which ticket did I mention?",
        session=session,
    )
    print(second.final_output)


if __name__ == "__main__":
    asyncio.run(main())

SQLite is useful for learning and local workloads. Production needs the session backend, concurrency, encryption, retention, and tenancy appropriate to its environment.

How do approvals resume?

When a tool needs approval, the result contains interruptions and resumable state. Store that state securely with business proposal, policy version, budget consumption, expiry, and approver scope. After approval or rejection, resume from the same state—not from a new prompt that says “the user approved.”

How do you prove resume correctness?

Continue a session across process restart.
Attempt concurrent writes and verify your chosen serialization behavior.
Expire an approval before resume.
Change business state while waiting and force revalidation.
Verify retention/deletion removes both local state and provider references where supported.

Failure injection: Reuse one session across two tenants. Your harness must reject the request before SDK execution. A session identifier is not an authorization boundary.

What mistakes should you avoid?

Equating session history with business truth.
Using guessable IDs without tenant scoping.
Letting old approvals authorize changed proposals.
Resetting budgets on resume.
Keeping conversations indefinitely without a retention purpose.

Check your understanding

Why should one flow use one continuation strategy?
Why is approval resume not a new user turn?
Which controls surround a production session store?

Expert extension

Implement a session repository interface with optimistic concurrency, tenant-scoped keys, retention metadata, and a test that prevents cross-tenant reuse.

Official references

Manage OpenAI Sessions and Resumable State

Which strategy should you choose?

Strategy	State owner	Good for
result.to_input_list()	application	explicit replay and custom storage
SDK session	your storage through SDK	convenient persistent history
conversation ID	OpenAI service	server-managed state across workers
previous response ID	OpenAI service	lightweight response continuation
serialized run state	application/provider SDK	paused approval or interruption

Mixing replayed input with server-managed continuation can duplicate context. Document the selected strategy in the conversation record.

How do you use a local session?

session_demo.py:

python

import asyncio

from agents import Agent, Runner, SQLiteSession


agent = Agent(
    name="Support explainer",
    instructions="Answer only from facts supplied in this conversation.",
)
session = SQLiteSession("demo_conversation_1")


async def main() -> None:
    first = await Runner.run(
        agent,
        "Ticket T-100 concerns a duplicate charge.",
        session=session,
    )
    print(first.final_output)

    second = await Runner.run(
        agent,
        "Which ticket did I mention?",
        session=session,
    )
    print(second.final_output)


if __name__ == "__main__":
    asyncio.run(main())

SQLite is useful for learning and local workloads. Production needs the session backend, concurrency, encryption, retention, and tenancy appropriate to its environment.

How do approvals resume?

How do you prove resume correctness?

Continue a session across process restart.

Attempt concurrent writes and verify your chosen serialization behavior.

Expire an approval before resume.

Change business state while waiting and force revalidation.

Verify retention/deletion removes both local state and provider references where supported.

Failure injection: Reuse one session across two tenants. Your harness must reject the request before SDK execution. A session identifier is not an authorization boundary.