Your OpenAI Agent Remembers the Chat, Not the Job: Giving the Agents SDK Real Memory Between Scheduled Runs

There is a moment almost every automation operator hits with the OpenAI Agents SDK. The scheduled job runs at 6 AM, the agent works beautifully, the logs look perfect. Then it runs again at 6 AM the next day and behaves like it has never met you. It re-asks questions answered last week. It re-fetches data already fetched. It makes a slightly different decision than yesterday and cannot explain why.

This feels like a bug, but it is the documented behavior. The Agents SDK has a sessions system, and sessions do exactly what the docs say: they store conversation items so the next turn in the same session has context. What they do not do is give a scheduled agent a working memory of its job across days, machines, and restarts. That gap is where the pain lives.

What sessions actually are

Sessions in the Agents SDK are a conversation-history store with a clean interface. In Python, you pass a session object to Runner.run, and the SDK fetches previously stored conversation items and prepends them to the next turn, then persists the new input and output after the run completes. The TypeScript SDK ships with OpenAIConversationsSession (server-side storage through the Conversations API) and MemorySession, which is explicitly intended for local development. The Python side adds SQLiteSession, SQLAlchemySession, EncryptedSession, and community backends like RedisSession.

For a chat app, this is genuinely good. For a scheduled agent, three problems show up the moment the cron kicks in.

Problem 1: Sessions store transcripts, not working memory

A session replays the raw conversation: every user input, every assistant output, in order. That is context, not memory. A scheduled reporting agent does not need a verbatim replay of the last 40 runs. It needs the distilled state: which sources proved unreliable, what was flagged as wrong last Tuesday, the decision already made about the Q4 numbers, the API quirk that wasted two hours last month.

Full transcripts have two costs. First, tokens: prepending growing history to every run burns context and budget on low-value replay. The SDK ships an OpenAIResponsesCompactionSession to shrink history, which tells you the maintainers know raw replay does not scale. Second, signal: an agent drowning in 40 runs of transcript latches onto the wrong detail more often than an agent reading ten crisp working notes. Sessions remember the chat. Your job needs memory of the job.

Problem 2: The session that worked locally dies on the schedule

MemorySession is in-process: when the process exits, the memory is gone. Every scheduled run is a fresh process, so MemorySession gives a cron agent zero continuity.

SQLiteSession looks like the fix, until you look at where the schedule actually runs. A SQLite file persists only if the same disk survives between runs. On a laptop, fine. On GitHub Actions, a Lambda, or a container that rebuilds on deploy, the file lands in a filesystem that gets wiped before the next run. And even when the disk survives, it survives on one machine: move the job or run it from two places and each machine grows its own private history. That is not a memory system. That is a diary that burns itself every time you move house.

OpenAIConversationsSession avoids the disk problem by storing history server-side, but it stores the same raw transcript, and it ties your agent's memory to one provider's storage format. It also cannot be combined with conversation_id or previous_response_id in the same run, so you pick one continuation mechanism and live with its limits.

Problem 3: Nothing recalls the right memory at the right time

Sessions are keyed by a session ID you choose. To get memory of a past run, you have to know which session to open. But the scheduled agent's real question is usually the reverse: "what do I know about this situation?" Which session held the decision about the broken supplier feed? Which one recorded that the pricing API lies on weekends?

Scanning session transcripts by hand is not a strategy, and stuffing every transcript into every run is not one either. What the scheduled agent needs is searchable memory: store the working state once, retrieve the relevant slice at runtime, and keep the prompt lean. Sessions were built for turns, not for that.

The pattern that works for scheduled agents

Separate the two jobs. Sessions hold the transcript of the current run; a real memory layer holds everything that must survive between runs:

1. Write working notes, not transcripts. After each run, the agent writes down decisions, corrections, facts learned, and open items as small retrievable records. Not "here is everything that happened," but "here is what matters next time."
2. Store them somewhere the schedule cannot wipe. A hosted store with an API, not a file on an ephemeral disk. The memory must be reachable from the laptop, the CI runner, and the container with identical results.
3. Retrieve by relevance at runtime. When the 6 AM run starts, it searches memory for what is relevant to today's job instead of replaying yesterday's entire transcript.

This is where a shared memory layer earns its keep. With Vilix AI, your scheduled agent gets one cloud-hosted memory it reaches over MCP: zero infrastructure to run, the same memory visible from every tool and every machine, and full conversation history alongside the working notes, not just extracted facts. It runs on a free plan forever, the Pro trial is 7 days with no card required, and you can export or delete everything at any time.

Concretely, the setup looks like this: the cron job starts, the agent pulls the relevant memories for today's run (last run's outcome, known quirks, pending decisions), does its work with sessions handling the in-run transcript, and writes back the new working notes before it exits. Tomorrow's run, on whatever machine, picks up exactly where this one stopped. The session ID can even stay the same across runs, but now it is a handle on real memory, not just a replay buffer.

What to keep, what to drop

Keep sessions. They are the right tool for multi-turn continuity inside a run, and the SDK's session interface makes swapping backends painless. Drop the assumption that a session is a memory system. The moment your agent runs on a schedule, the memory that matters is the one that survives the process exit, the wiped disk, and the machine move, and that can be searched by meaning instead of scrolled like a chat log.

Your scheduled agent does not need a better transcript. It needs a memory of the job.

Running scheduled agents with the OpenAI Agents SDK? Vilix AI gives them one shared memory across every run, every machine, and every tool, over MCP. Free plan forever, 7-day Pro trial with no card.