Does the OpenAI Agents SDK Remember Between Runs? What Sessions Actually Persist

You built the agent with the OpenAI Agents SDK. It answers support tickets, triages leads, drafts the daily report. The demo ran beautifully in a REPL: every follow-up question landed with full context. Then you wired it to a cron job, and Monday's run had no idea what Friday's run decided.

Sessions are the SDK's answer to memory, and they are genuinely good at one job. The question is whether that job matches what your scheduled runs need. Here is what sessions actually persist, and where the gap opens for automation operators.

What a session is

The Agents SDK ships built-in session memory. Pass a session object to Runner.run() and successive calls share conversation history, with no manual .to_input_list() juggling between runs. Per the SDK docs, sessions exist so agents can "maintain context without requiring explicit manual memory management," particularly for chat applications and multi-turn conversations.

The standard recipe looks like this:

from agents import Agent, Runner, SQLiteSession

agent = Agent(name="Support assistant", instructions="Help the customer with their account.")
session = SQLiteSession("support_user_42")

first = await Runner.run(agent, "My order has not arrived.", session=session)
second = await Runner.run(agent, "It was supposed to arrive yesterday.", session=session)

The mechanics are simple. Before each run, the runner automatically fetches the session's conversation history and prepends it to the input. After each run, every new item from that run (user input, assistant responses, tool calls) is automatically saved back into the session. The second run sees the first. That part really works.

The SDK offers several session backends, each with a clear lane:

• InMemorySession: holds history only in memory. Fine for tests; lost on restart.
• SQLiteSession: stores conversation history in a local SQLite file, loaded automatically on each run. Good for single-process apps.
• AdvancedSQLiteSession: branching conversations plus per-thread usage tracking.
• RedisSession: for horizontally scaled servers where many processes share state.
• OpenAI Conversations API session: stores the history in the OpenAI cloud, so no separate database is needed.

So does the OpenAI Agents SDK remember between runs? For conversation turns, yes, within one process or one shared database. For scheduled automation, the honest answer is more layered. Four gaps matter.

Gap 1: sessions remember turns, not run state

A session stores the raw input and output items of each conversation, not a summary. Every call sends the entire history to the model again. For a long-running thread, that gets expensive fast: you pay for the whole transcript on every run, and eventually attention dilutes across an enormous prompt.

The SDK added a relief valve in version 0.2.6: session.compact(keep_last=20) summarizes older turns into a single system message. Useful, but it is lossy compression of a transcript. The alternative some operators reach for is the Responses API's server-side conversation feature via previous_response_id, which stores history on OpenAI's side and costs roughly 30% less than shipping the transcript yourself.

Either way, you are managing a conversation thread, not run state. A session knows what was said. It does not know what was decided, what was learned, or what changed in the world between runs. Your nightly lead-triage agent can recall that it answered a question about pricing; it cannot recall that it already disqualified the same 12 spam leads yesterday unless those facts appear somewhere in the transcript. Reconstructing business state from a chat log is the expensive, fragile way to give an agent continuity.

Gap 2: a session is only as durable as its database

SQLiteSession("conversation_123") writes to a file on the machine where the process runs. On your laptop, that is fine. On scheduled infrastructure, it is a trap.

Scheduled agents usually run on fresh environments: a new container, a new serverless invocation, a rotated VM. The sessions.db file does not survive the hop, because nobody carried it over. Monday's cron job boots, creates a brand-new SQLite file, and your agent wakes up with an empty history and no idea it ever ran before.

The fix is real but it is infrastructure work: stand up Redis or Postgres, point every scheduled invocation at it via RedisSession or a custom session backend, and make sure every scheduled run passes the same session ID so history accumulates instead of forking into a new session per run. None of that is automatic. The SDK gives you the session interface; the durability engineering is yours.

Gap 3: sessions do not checkpoint mid-run progress

A session persists completed turns. If your agent dies halfway through a five-tool sequence, the session resumes from the last persisted turn, not the last tool call. Exactly-where-it-crashed resumption is a checkpointer's job, and the SDK's sessions are not checkpointers.

For an interactive chat, this rarely matters. For a scheduled run that timed out after 40 minutes of expensive tool calls, it matters a lot: the next run starts the whole sequence over. Progress within a run is not part of what sessions promise.

Gap 4: sessions live inside the SDK

A session belongs to the Agents SDK process that created it. Your n8n workflow, your Claude Code session, your support dashboard, and the second agent you wrote in a different framework cannot see it. Each tool keeps its own transcript in its own store.

That is the shape of the real operator problem. Memory scattered across per-tool sessions means your lead data in the triage agent is invisible to the outreach agent, and the decisions made by last night's scheduled run are unreachable by tomorrow's ad-hoc investigation. Nothing compounds. Every run is still, in the ways that matter, run one.

What scheduled operators actually need

Sessions solve the chat problem: keep the conversation going across Runner.run() calls. Scheduled automation has a different problem: keep the state going across runs, across machines, and across tools.

The practical layer operators converge on looks like this:

1. Decisions and outcomes, stored as facts, not buried in transcripts. What was disqualified, what was learned, what changed.
2. Durability independent of the process. State that survives fresh containers, crashed runs, and rotated machines without extra infrastructure you have to babysit.
3. One memory every tool can read. The n8n run, the Agents SDK script, and the debugging session in Claude Code should all wake up with the same context.

That is the gap a shared memory layer fills. Vilix AI is cloud-hosted with zero infrastructure to manage, so there is nothing to stand up, no Redis to operate, no database file to carry between containers. The same memory follows you everywhere over MCP, so the Agents SDK run, the n8n workflow, and the coding agent all read and write the same context. It keeps full conversation history, not just extracted facts, and your data stays portable: export everything or delete it anytime. The free plan is free forever, and the 7-day Pro trial needs no credit card.

Sessions make the OpenAI Agents SDK remember the conversation. If you want your scheduled runs to remember the work, the decisions, and each other, give them one shared memory to wake up to.

To try the shared approach, start Vilix AI free at https://vilix.ai/?utm_source=vilix-blog&utm_medium=article&utm_campaign=openai-agents-sdk-memory-between-runs-sessions-explained. Free forever, no credit card, and you can leave with your data whenever you want.