Anyone comparing an llm memory database quickly runs into Zep, and for good reason: it tackles a problem most competitors quietly skip, which is that facts change over time and most memory systems only ever hold the current version. This piece looks at what Zep actually does well, what changed with its self-hosting story, and where it sits against a tool built for a different job.
What makes Zep different
Zep's memory layer is built on Graphiti, an open source, MIT licensed temporal knowledge graph. The distinction that matters is temporal: rather than storing "the customer's plan is Enterprise" as a flat fact, Graphiti stores that fact with a timestamp, and keeps the earlier fact too, marked as no longer current. Ask an agent built on Zep what the customer's plan was three months ago and, unlike most memory tools, it can actually answer.
Graphiti has grown fast on its own merits. It passed 20,000 GitHub stars during 2026, with tens of thousands of weekly PyPI downloads, numbers that reflect genuine developer adoption rather than a marketing push. That is a healthy, active open source project underneath Zep's commercial offering.
Zep's self-hosting story has changed
Here is the part worth knowing before you commit: Zep deprecated its self-hosted Community Edition in April 2025. If your plan was to run "Zep" on your own servers the way you might have a year ago, that packaged option no longer exists. What remains is running Graphiti directly, against Neo4j, FalkorDB or Kuzu, and building your own service layer around it. That is a legitimate path for a team with graph database experience, but it is a materially different commitment to running Zep's own server used to be, and it is worth factoring into any zep self hosted alternative search.
Is Zep good for company knowledge?
For tracking how an individual agent's understanding of a user or a project changes over time, yes, convincingly so. For serving as the shared context layer behind a whole company's systems of record, with different askers entitled to see different things, that is a separate design question Zep's own documentation does not claim to answer. Temporal reasoning and entitlement-aware retrieval are both hard problems, and they are different problems.
"Granting LLMs unchecked autonomy to take action can lead to unintended consequences, jeopardizing reliability, privacy, and trust."
OWASP Top 10 for Large Language Model Applications, on excessive agency
A knowledge graph that faithfully tracks every version of every fact is genuinely useful. It says nothing, by itself, about whether the agent reading that graph is allowed to see a given fact for the person it is currently serving. That check has to live somewhere else in the system.
A worked example
Picture a subscription business tracking customer plan changes, support tickets, and billing history through an agent built on Zep. A support agent asks "when did this customer downgrade, and what did we tell them at the time?" Zep's temporal graph answers this cleanly: it holds the downgrade event, the timestamp, and the state of the account before and after. That is exactly the kind of question a flat, non-temporal memory store gets wrong or cannot answer at all.
Now widen the scope. The same company wants a support agent, a finance agent, and a customer-facing chatbot all drawing on the same underlying knowledge, but the finance agent should see revenue figures the chatbot never should. Zep's temporal graph does not natively decide that. Someone still has to build the entitlement layer on top, agent by agent, deciding for each node in the graph who is allowed to read it and under what conditions that answer might change later.
That extra layer is not a criticism of Zep specifically. Almost every memory tool built around a single agent's context has the same gap, because the problem they were built to solve never included a second asker with a narrower set of rights. It only becomes visible once a company tries to reuse the same memory across more than one role.
Zep pricing versus the field
| Dimension | Zep Cloud | Graphiti self-hosted | Contextely |
|---|---|---|---|
| Starting price | Free, your infrastructure | Free tier, 500 retrievals/mo | |
| Self-hosting | Discontinued as packaged product (April 2025) | Yes, DIY against Neo4j/FalkorDB/Kuzu | Yes, Docker, no feature gating |
| Core strength | Temporal reasoning: what changed and when | Same, at the library level | Entitlement-aware retrieval across systems |
| Compliance | SOC 2 Type II, HIPAA | Depends on your own deployment | Depends on your own deployment |
| Entitlement model | Not the core focus | Not the core focus | Enforced inside the retrieval scoring function |
Table 1: Zep, raw Graphiti, and Contextely solve genuinely different slices of the memory problem; pick by which slice you actually need.
Common pitfalls when evaluating a zep alternative
- Assuming "Zep" still means a packaged self-hosted server. Since April 2025, self-hosting means running Graphiti yourself, a bigger lift than deploying Zep's old Community Edition.
- Treating temporal reasoning and entitlement as the same feature. Knowing when a fact changed and knowing who is allowed to see it are separate checks. A tool can be excellent at one and silent on the other.
- Comparing Zep Cloud's price to a free self-hosted graph without counting engineering time. Running Graphiti yourself against a production graph database is not free once you count who maintains it.
- Picking a memory database before deciding who your askers are. If your real problem is many people or many agents needing different views of the same company knowledge, that changes which tool actually fits, regardless of how good its graph engine is.
Where this leaves you
Zep, and Graphiti underneath it, do something genuinely hard well: tracking facts as they change, not just their latest state. That is a real, differentiated strength, and if your agent needs to reason about history, it is worth serious consideration, self-hosted Graphiti included if your team can run a graph database.
If your actual problem is closer to "give many different people and agents a current, access-controlled view of our company's systems," that is the gap Contextely was built to close: self-hostable via Docker as a first-class path rather than a discontinued one, with entitlement enforced inside the retrieval scoring function, not bolted on afterwards, and memory objects that carry their own staleness handling rather than relying on you to re-index. See the direct Zep comparison page for a feature-by-feature breakdown, read our Letta review if you are also weighing a pure agent framework, or check pricing against Zep Cloud's $125 a month starting point.
Frequently asked people-also-ask questions
Does Contextely use a temporal knowledge graph like Zep?
No. Contextely condenses source systems into memory objects with a source-set TTL and re-fetches over MCP when they go stale, which solves currentness rather than full historical versioning. If you specifically need to query how a fact looked at any point in the past, Zep's temporal model is the more direct fit.
Can I combine Graphiti with a separate entitlement layer?
Yes, in principle. Graphiti is a library, not a closed platform, so nothing stops a team building an entitlement check around it. It is additional engineering work rather than a feature you configure, which is the trade-off worth weighing against a tool that ships that check already built in.