Your LangGraph Agent Remembers Its Thread but Forgets Your Business: Checkpointers vs Long-Term Memory

Your LangGraph agent remembers its thread but forgets your business: checkpointers vs long-term memory

You wired up a LangGraph agent, gave it a checkpointer, and watched it recall things mid-conversation. Then you put it on a schedule. Every morning it wakes up, and the checkpointer might as well not exist. It greets the day like nothing ever happened.

This is the most common LangGraph memory mistake automation operators make. Checkpointers were designed for conversations, not for runs. A cron job is not a conversation. Once you see the difference between thread memory and run-to-run memory, the whole persistence story clicks.

Checkpointers remember threads, not businesses

A LangGraph checkpointer saves the graph's state after every super-step: messages, tool results, intermediate values. When you call graph.invoke() again with the same thread_id, it picks up where it left off. That is genuinely useful for a chat session that pauses and resumes.

The problem is what a scheduled run actually is. Your 2am data-sync agent does not resume yesterday's thread. It starts a new invocation, often with a fresh thread_id, sometimes with no thread at all. The checkpointer faithfully stores state for a thread nobody will ever open again. Everything your agent learned about your data, your clients, your edge cases, sits in a thread archive that no future run reads.

So the first question is not "how do I persist state." It is "which memory am I missing: the thread's, or the business's?"

The checkpointer ladder (and where each rung breaks)

Most operators climb the same ladder. Each step fixes one failure mode and reveals the next.

InMemorySaver. The default in tutorials. It stores state in RAM. The moment the process exits, everything is gone. A scheduled agent that runs as a fresh process every time is the worst possible fit: you get checkpointing semantics with zero durability. It is fine for a demo. It is a trap for anything on a timer.

SqliteSaver. Now state survives process restarts, written to a local .db file. Better, until your agent runs in a container or on a CI runner with ephemeral disk. Redeploy the image, and the database file vanishes with the old container. Move the job to a different machine, and it starts blank again. Local files are only durable where the filesystem is.

Postgres checkpointer. The production answer, and it is a real one. State now survives restarts, redeploys, and machine changes. But notice what you bought: infrastructure. You are now running, backing up, and monitoring a Postgres database for your agent's memory. And the checkpointer still stores raw thread state. Every checkpoint includes the full message history: the verbose tool outputs, the dead-end reasoning, the noise. It grows fast, and nothing in it is searchable by meaning. You have durability, not memory you can actually use.

And none of these fix the thread problem. Your Postgres checkpointer has perfect recall of forty threads your agent will never revisit.

The store: LangGraph's actual long-term memory

LangGraph has a second persistence system that most tutorials skip: the store. The checkpointer is short-term memory scoped to a thread. The store is long-term memory shared across threads. Inside a node, your agent can store.put() a fact under a namespace and a key, and any future run on any thread can store.get() it back.

This is the shape scheduled automation actually needs. Each run gets a fresh thread, but the store accumulates: the client's preferred format, the API quirk you discovered three runs ago, the rule the operator corrected last week. Your agent stops re-learning your business every morning.

The store has its own ceiling, though. It is a key-value system. Your agent has to know the key to get the value, and the namespace to put it in. There is no "find me the thing about the invoice format" — no semantic search over what is stored. You are building your own retrieval layer on top: your own embeddings, your own search, your own garbage collection for stale entries. That is a second project sitting next to the agent.

What operators actually end up with

Step back and look at the full stack a scheduled LangGraph agent needs for real memory: a durable checkpointer backend for thread continuity, a store backend for cross-thread facts, semantic search over both, retention rules so old entries die, and isolation so one client's facts never leak into another's runs. That is two databases, a search layer, and a policy layer, all maintained by hand, all invisible to every other tool you run.

Some teams build it. Most of them end up maintaining it more than the automation itself.

There is a shorter path, and it looks like this: one hosted memory layer your agent reads and writes over MCP. No Postgres to babysit, no SQLite file to lose in a redeploy. The memory lives in the cloud, so the same context follows the agent whether it runs on your laptop, in a container, or inside n8n. It stores full conversation history, not just distilled facts, so the actual exchange from last Tuesday's run is there when you need it. Retrieval is semantic, so the agent finds what it meant, not what it keyed. You can export everything or delete it anytime in a portable format. The free plan covers real usage, and the 7-day Pro trial needs no credit card.

That is what Vilix AI is: cloud-hosted memory for agents, zero infrastructure on your side. Your LangGraph agent calls get_context at the start of a run and save_turn at the end, over MCP, and run-to-run memory stops being a project. Same memory is available to every other AI tool you connect, so the context your agent builds is not trapped inside one framework.

The honest checklist

Before you ship a scheduled LangGraph agent, answer these:

1. What dies when the process dies? If the answer is "the checkpointer," you are on InMemorySaver and your memory is theater.
2. What dies on redeploy? SqliteSaver on ephemeral disk fails this. Your persistence must live outside the thing that runs the agent.
3. Does memory cross threads? If each run is a new thread_id, checkpointers alone give you nothing across runs. You need the store or an external layer.
4. Can the agent search what it knows? Key-value stores and raw checkpoints answer "give me key X." They do not answer "what did we learn about the client last month."
5. Who maintains the backends? Every database you add is a thing you page for. Count that cost before you build.

LangGraph gives you the primitives. Checkpointers for the thread, the store for the facts. The gap is everything around them: durability you do not babysit, search that understands meaning, and memory that survives the framework, the machine, and the redeploy. That is the difference between an agent that remembers a conversation and an agent that remembers your business.