Does Zep Remember Between Sessions? The Honest Breakdown for Scheduled Agents

Zep is one of the more serious memory products an agent builder can pick up. It is a long-term memory service built on Graphiti, a temporally aware knowledge graph that tracks facts along with when they were true, so an agent can answer "what changed" instead of only "what is true now." Agents built with Mastra, Strands, AG2, and LangGraph can all plug it in. So when you wire it into an automation that runs on a schedule, the natural question is: does Zep remember between sessions?

The short answer is yes, but only if your automation does three things right. Zep remembers the thread you point it at. It does not decide which thread that is, it does not flush itself at shutdown, and it does not make facts available the instant they are written. Those three details are exactly where scheduled agents go wrong.

What Zep actually persists

Zep's core idea is conversation memory with a temporal knowledge graph on top. You send it messages, it stores the chat history, generates summaries, embeds messages and summaries for search, and builds a graph of facts with validity windows. A fact like "the customer prefers the annual plan" carries the information that it superseded an earlier preference, so retrieval is time-aware. Retrieval combines semantic search, full-text search, and graph traversal, and a thread-level context block can be assembled from the whole user graph and injected into the next prompt.

None of that disappears between sessions. Open a thread, add messages, close the session, and open the same thread tomorrow: the history, the summaries, and the graph are all still there. In that sense Zep absolutely remembers between sessions. The catch is that "the same thread" is doing a lot of work in that sentence.

Gap 1: Zep does not choose the thread. Your automation does.

In Zep's current API, every user, thread, and graph is addressed by a server-generated UUID. The setup pattern in Zep's own integration docs is explicit: create the user and thread out of band, before the first turn, and store the returned UUIDs in your own database. Zep generates the identifiers; you keep them.

That is fine for a product with a real onboarding flow. It is a trap for scheduled automations. A nightly lead-research agent on n8n or a Monday-morning reporting cron does not have an onboarding flow. If each run generates a fresh thread, or if the run forgets to look up the stored UUID before calling Zep, the agent gets a blank thread every execution and Zep faithfully remembers nothing useful. The memory layer works perfectly; the wiring around it is what fails. Most "Zep does not remember between runs" complaints trace back to this: the agent was not actually reopening the same thread.

Gap 2: unflushed turns never make it to memory

Zep buffers messages and persists them asynchronously. Its docs flag a practice that matters enormously for automations: flush at session boundaries. After your agent finishes its invoke or stream call, you are expected to flush so buffered turns reach Zep before shutdown.

A scheduled run that finishes its work and exits without flushing can silently drop its last turns. The agent will read a healthy-looking memory next run and never realize the final decisions of the previous run were never stored. For a chat product with a long-lived process this is a minor detail. For a cron job that lives for ninety seconds, it is the difference between compounding knowledge and a permanent hole in the record.

Gap 3: facts are not instantly retrievable

Zep extracts knowledge from messages asynchronously, and the docs note that facts from a turn are not instantly retrievable. With the default cadence, some recent messages may not even have been sent to the pipeline yet. A run that writes something at the end of execution N and reads it back at the start of execution N+1 an hour later will generally be fine. A tight loop, where a run writes a result and then reads it back moments later, or where two scheduled runs execute close together, can miss what was just stored. If your automation's reliability depends on the memory being current the moment the run ends, you need to account for this lag in your design.

What it costs, honestly

The hosted platform, Zep Cloud, is a commercial service. Pricing as of recent months: a free tier with 10,000 credits per month, then Flex at $125 per month for 50,000 credits, and Flex Plus at $375 per month for 200,000 credits. One credit covers an ingested episode up to 350 bytes, and retrieval is not metered. That is workable for evaluation and real workloads, but it is developer-priced for developer-shaped usage. Note the direction of travel: the self-hostable Community Edition was discontinued, and the full platform is now cloud-only. The underlying Graphiti engine remains open source under Apache 2.0, which means you can self-host the graph layer, but then you are building the managed parts, user and thread management, context assembly, yourself.

Zep is a strong choice when you are building agents and want temporal reasoning about what changed and when. It is a developer-operated memory layer: you provision the identities, you manage the flushes, you account for the indexing lag, and you pay per ingested byte. For automation operators who would rather run automations than operate infrastructure, that is the real question to weigh.

The alternative for scheduled agents

If you run scheduled agents across n8n, Make, Zapier, or your own scripts, the memory problem is not "store my chat history in a graph." It is "every run should wake up already knowing everything." Vilix AI approaches it from that angle: a cloud-hosted memory layer with zero infrastructure to run, where the same memory follows you across every AI tool over MCP. There is no UUID plumbing to maintain, no provisioning step per run, no flush to remember at shutdown. The agent reads one memory, the same memory, from the phone app, the laptop, and every automation platform.

It keeps full conversation history, not just extracted facts, so the why behind a decision survives alongside the decision itself. It is free forever on the free plan, with a 7-day Pro trial that asks for no credit card. And the data is yours: export everything or delete it anytime, no questions.

Zep remembers the thread you give it, and it remembers it well. The honest breakdown is that the thread, the flush, and the timing are all on you. For builders who want temporal graph reasoning and are happy to operate it, Zep is a legitimate pick. For operators whose agents should simply wake up knowing, a hosted memory layer that removes the plumbing entirely is the shorter path.