Scheduled LangGraph Runs Keep Waking Up Blind: How to Make Agent Memory Survive Between Runs

Scheduled LangGraph runs keep waking up blind: how to make agent memory survive between runs

Picture the 2am run. Your LangGraph agent wakes up on schedule, pulls the day's data, and starts working. Somewhere around step three it hits the same API quirk it hit last week. The workaround exists. It is in yesterday's thread, in the run before that, in a dozen archived threads stretching back a month. The agent cannot see any of them. So it re-discovers the quirk, re-invents the workaround, and burns twenty minutes doing what it already knew.

You gave it a checkpointer. The tutorials said that was memory. It was not, or at least not the kind a scheduled automation needs.

What a checkpointer actually persists

LangGraph's checkpointer does one job well: it saves the full state of a graph after every step, namespaced by thread_id. Invoke the graph again with the same thread and it resumes mid-thought. Time travel, human-in-the-loop pauses, conversation continuity across separate calls — all of this is the checkpointer doing its job.

Now look at how a scheduled agent runs. The cron fires. A fresh process starts. It invokes the graph, usually with a brand-new thread ID, because nothing about this run is a continuation of the last one. The checkpointer dutifully saves everything under that new thread. Tomorrow's run will not ask for it. You end up with a museum of perfectly preserved runs that no future run ever visits.

The persistence worked. The memory did not.

Climbing out of RAM

If you have followed the usual tutorials, your agent is probably on the first rung: InMemorySaver. It keeps state in the process's own RAM. Kill the process and the memory is gone, which is exactly what a scheduler does between runs. InMemorySaver on a cron job is a checkpointer with the lifespan of a fruit fly.

The next rung is SqliteSaver, and it is a genuine improvement — state lands in a file on disk, so restarts stop erasing it. The catch is where that disk lives. Scheduled agents usually run in containers, serverless functions, or CI runners where the filesystem is disposable. Redeploy the container and the SQLite file goes with it. Move the job to another machine and the memory stays behind. A database that lives inside the disposable part of your infrastructure is not durable.

So you graduate to the Postgres checkpointer. This one is actually durable: restarts, redeploys, and machine changes all survive. But read the receipt. You are now operating a Postgres database — backups, monitoring, connection pooling, credentials rotation — just so your agent can remember things. And what it remembers is raw: full message lists, every tool call, every verbose API response, stored exactly as it happened. Nothing indexes it by meaning. A month of daily runs turns into a heavy archive of noise that the agent can only find if it already knows where to look.

Three rungs up the ladder, and the original problem is untouched: each run still starts as a stranger to the last.

The piece the tutorials skip

LangGraph ships a second persistence system, and it is the one built for this exact problem: the store. Where the checkpointer is scoped to one thread, the store lives across all of them. A node can save a fact with store.put() under a namespace, and any run on any thread can pull it back with store.get().

This matches how scheduled work really flows. The thread is the run: born, worked, archived. The store is the accumulated knowledge: the client's formatting preference, the endpoint that returns garbage on Tuesdays, the correction you typed last Thursday. Threads die. The store persists.

But the store is a key-value system, and key-value systems have a fixed shape of question they can answer. Your agent must know the namespace and the key up front. "What did we learn about the Acme invoices over the last month?" is not a key. It is a search. Nobody gave the store one. If you want semantic retrieval — ask in plain language, get back the relevant entries — you are building it yourself: embeddings, a vector index, a cleanup policy for stale facts. The tutorials end where the real work begins.

What this looks like when it is done

A scheduled LangGraph agent with real memory needs a small stack: something durable for thread state, something shared for cross-thread facts, semantic search over both, retention rules so the past does not pile up into sludge, and isolation so one tenant's facts never bleed into another's. Built by hand, that is two databases, a search layer, and a policy layer, all maintained by whoever owns the automation. The memory system quietly becomes a bigger job than the agent.

Or the memory lives outside the agent entirely. A cloud-hosted memory layer means there is no database to operate — no Postgres to back up, no SQLite file to lose in a redeploy. The agent connects over MCP, loads what it needs with get_context at the start of a run, and saves the run with save_turn at the end. Because it is hosted, the same memory follows the agent across the laptop, the container, and the scheduler, and across every other AI tool you connect. What gets stored is the full conversation history, not just compressed facts, so the actual exchange from a past run is retrievable. And when you want out, you export everything or wipe it instantly — your data, portable, on your terms. There is a free plan that covers real usage and a 7-day Pro trial that asks for no credit card.

Vilix AI is built for exactly this: one shared memory for agents that run on a schedule, with zero infrastructure for you to maintain. The LangGraph agent stops re-learning your business every morning because its memory outlives the process, the container, and the redeploy.

Before your next scheduled run

Run through these five questions honestly:

1. If the process is killed between runs, what survives? If the answer names RAM, you have no memory, only a demo.
2. If you redeploy tomorrow, does the agent still know what it knew today? Anything stored inside the disposable part of your stack fails this.
3. Can one run see what a previous run learned? New thread per run means checkpointers alone cannot do this. You need cross-thread storage.
4. Can the agent find knowledge by meaning, or only by key? If the answer is "only by key," you are one growth spurt away from building a search layer.
5. Who operates all of this? Count the databases, the backups, the on-call. Then decide whether that is the job you hired yourself to do.

LangGraph hands you good primitives — a checkpointer for the run, a store for the knowledge. The work is everything that makes those primitives survive the scheduler: durability outside the disposable parts, search that understands what it is looking for, and memory that belongs to the business, not the thread.