Why people look for a Zep alternative
Zep is one of the more technically ambitious approaches to agent memory. Its knowledge graph extraction, built on top of Neo4j-style relationships, goes significantly beyond simple vector search. If you're building a long-running agent that needs to understand complex entity relationships — "Alice is the manager of Bob who works on Project X which is owned by Client Y" — Zep's graph approach is genuinely powerful.
So why would you look for an alternative? Three reasons come up consistently:
- EU data residency. Zep Cloud is hosted in the US. For regulated EU companies, this is a compliance issue that doesn't go away with good intentions.
- Operational complexity. Zep's knowledge graph is powerful, but it introduces non-determinism and debugging complexity that many production teams find hard to manage.
- Pricing predictability. Zep Cloud's usage-based pricing can be hard to forecast at scale.
This article addresses all three.
What Zep does well
Before the alternatives section, it's worth being honest about where Zep is genuinely strong.
Knowledge graph memory. Zep doesn't just store text chunks — it extracts entities and relationships, building a graph that an agent can traverse. This is architecturally superior for complex multi-entity use cases. If you're building a CRM agent that needs to reason about relationships between people, companies, and deals, Zep's approach has real advantages.
Open-source core. The zep-python and zep-js packages are open-source. You can self-host the community edition on your own infrastructure, including EU-based servers.
LangChain and LangGraph integration. Zep has official integrations with both LangChain and LangGraph. The ZepChatMessageHistory class is a drop-in for LangChain memory.
Dialog classification. Zep classifies conversation dialogs (question, instruction, statement, etc.) which enables more nuanced memory retrieval strategies.
Where Zep creates problems for EU teams
1. Zep Cloud is US-hosted
Zep's managed cloud product runs on US infrastructure. There is no announced EU region as of April 2026. This creates the same compliance challenge as Mem0: GDPR Art. 28 requires a Data Processing Agreement before a processor can handle personal data, and standard contractual clauses for US→EU data transfers have been legally contested since Schrems II (C-311/18).
Self-hosting the community edition solves this, but you then own the infrastructure, the upgrades, the monitoring, and the backup strategy.
Schrems II context: The EU Court of Justice invalidated the Privacy Shield framework in 2020 (C-311/18), making US data transfers to services without a valid DPA legally precarious under GDPR. Self-hosting on EU infrastructure or using an EU-hosted managed service are the two safe paths.
2. Non-deterministic knowledge graph extraction
Zep's graph extraction uses an LLM to identify entities and relationships from text. The same input can produce different graph structures on different runs depending on model version, temperature, and extraction prompt. For use cases where you need to explain why the agent said something — financial advice, medical information, legal assistance — non-deterministic memory is an audit liability.
3. Multi-tenant isolation is not default behavior
Zep's community edition stores memories in sessions, and the isolation model between users requires explicit implementation. In a multi-tenant SaaS context, getting this wrong means user A can potentially retrieve memories that belong to user B. This has been reported as a footgun in production deployments. It's solvable, but it requires careful implementation rather than being the default.
4. Knowledge graph complexity as a debugging surface
When a Zep-powered agent recalls unexpected information or misses something it should know, debugging requires inspecting the graph — understanding what entities were extracted, what relationships were inferred, and why a particular graph traversal returned what it did. This is significantly harder to reason about than vector similarity scores.
Kronvex as an alternative
Kronvex takes a different architectural stance: simpler, deterministic, and explicitly GDPR-native.
| Feature | Zep Cloud | Zep Community (self-hosted) | Kronvex |
|---|---|---|---|
| EU data residency | ✗ No (US-hosted) | ✓ Yes (your infra) | ✓ Yes (Supabase Frankfurt) |
| Public DPA | ✗ Not published | N/A (self-hosted) | ✓ Available on request |
| GDPR Art. 17 erasure | ✗ Not documented | Manual | ✓ Built-in endpoint |
| GDPR Art. 20 portability | ✗ Not documented | Manual | ✓ Built-in endpoint |
| Memory approach | Knowledge graph (LLM extraction) | Knowledge graph (LLM extraction) | Vector similarity (explicit storage) |
| Deterministic | ✗ No | ✗ No | ✓ Yes |
| Operational overhead | Low (managed) | High (self-hosted) | Low (managed) |
| Multi-user isolation | Requires explicit implementation | Requires explicit implementation | user_id parameter, default scoped |
| LangChain integration | Official | Official | Community (documented) |
| Pricing model | Usage-based | Infrastructure costs | Flat monthly (€19–€599/mo) |
| Max agents (entry plan) | Usage-based | Unlimited | 3 (Dev plan) |
Key tradeoff: Zep's knowledge graph is more powerful for complex entity-relationship use cases. Kronvex is more predictable, auditable, and operationally simpler for the majority of production agent use cases (conversation continuity, user preferences, decision history).
When to use Zep (self-hosted) vs Kronvex
Use Zep community self-hosted if:
- You need entity-relationship graph traversal (CRM agents, knowledge management)
- You have infrastructure capacity to run and maintain it
- You're comfortable with LLM-based extraction non-determinism
- EU hosting is required and you can absorb the ops overhead
Use Kronvex if:
- You need EU-hosted managed infrastructure without ops overhead
- You want deterministic, auditable memory behavior
- Your use case is conversation continuity, preferences, and decision history rather than complex entity graphs
- You need predictable flat-rate pricing
- GDPR erasure and portability endpoints need to be available out of the box
Technical migration guide: from Zep to Kronvex
Before (Zep):
from zep_python import ZepClient, Memory, Message
zep = ZepClient(api_url="https://your-zep.example.com")
# Zep stores via session + message history
session_id = "session-abc"
zep.memory.add(
session_id=session_id,
memory=Memory(
messages=[
Message(role="user", content="I prefer async Python and work in healthcare IT.")
]
),
)
# Recall — Zep searches its knowledge graph
memories = zep.memory.search(session_id=session_id, query="tech preferences")
for m in memories:
print(m.message.content, m.dist)
After (Kronvex):
from kronvex import KronvexClient
kv = KronvexClient(api_key="kv-your-key", base_url="https://api.kronvex.io")
AGENT_ID = "your-agent"
# Explicit storage — you decide what's worth keeping
kv.remember(
agent_id=AGENT_ID,
content="User prefers async Python and works in healthcare IT.",
user_id="user-123",
session_id="session-abc",
)
# Recall — pgvector cosine similarity + confidence scoring
memories = kv.recall(
agent_id=AGENT_ID,
query="tech preferences",
user_id="user-123",
top_k=5,
)
for m in memories:
print(f"{m['content']} (confidence: {m['confidence']:.2f})")
Replacing ZepChatMessageHistory in LangChain
# Before (Zep)
from langchain_community.memory import ZepChatMessageHistory
from langchain.memory import ConversationBufferMemory
history = ZepChatMessageHistory(session_id="session-abc", url="https://your-zep.example.com")
memory = ConversationBufferMemory(chat_memory=history)
# After (Kronvex) — see langchain-integration.md for the full KronvexMemory class
from kronvex import KronvexClient
kv = KronvexClient(api_key="kv-your-key", base_url="https://api.kronvex.io")
# Use KronvexMemory from the integration guide
memory = KronvexMemory(kv_client=kv, agent_id="your-agent", user_id="user-123")
Multi-user isolation (Kronvex default behavior)
# With Kronvex, user_id scoping is built into every call
# User A and User B's memories are never mixed
kv.remember(agent_id=AGENT_ID, content="Prefers dark mode.", user_id="user-alice")
kv.remember(agent_id=AGENT_ID, content="Prefers light mode.", user_id="user-bob")
# This only returns alice's memories — bob's are not accessible
alice_memories = kv.recall(agent_id=AGENT_ID, query="UI preferences", user_id="user-alice")
GDPR erasure (Art. 17 right to be forgotten)
import httpx
# Delete all memories for a user — Art. 17 right to erasure
response = httpx.delete(
"https://api.kronvex.io/api/v1/gdpr/erasure",
headers={"X-API-Key": "kv-your-key"},
json={"user_id": "user-alice"},
)
print(response.json())
# {"deleted_memories": 37, "user_id": "user-alice", "status": "erased"}
FAQ
Is Zep GDPR compliant?
Zep Cloud runs on US infrastructure without a published DPA, which creates the same compliance challenge as other US-hosted AI services. The open-source community edition can be self-hosted on EU infrastructure, which gives you full control over data residency — but you take on the operational overhead.
Does Zep have EU servers?
No EU region has been announced for Zep Cloud as of April 2026.
Is Zep open-source?
The Zep community edition is open-source under an Apache 2.0 license. Zep Cloud is a managed service on top of a proprietary extended version.
What's the main technical difference between Zep and Kronvex?
Zep builds a knowledge graph from conversations using LLM extraction. Kronvex stores explicit memories you provide via remember() and retrieves them using vector similarity. Zep is more powerful for entity-relationship reasoning; Kronvex is more predictable and auditable for conversation continuity use cases.
Quick start: Get a demo API key in 30 seconds — no credit card required.
curl -X POST https://api.kronvex.io/auth/demo
# Returns: {"api_key": "kv-demo-..."}
Demo includes 3 agents and 500 memories. Full documentation: kronvex.io/docs. Pricing: kronvex.io/#pricing