Open-source graph memory that's not Mem0 or Zep - built it because neither fit my agentic workflow. 1 LLM call in, 0 out
What My Project Does
I've been building a personalized agentic workflow not a chatbot, but a system where
multiple agents interact with users to execute real tasks in the physical world. Think
scheduling, procurement, field operations things that need to remember who you are
across sessions.
That's where I hit a wall: memory.
I needed the system to know the user the way a human colleague would remember
preferences, relationships, past decisions but without the human limitation of
forgetting things over time.
The idea: What if we stored memories the way the human brain organizes information
as a network of connected concepts but did it better? That's where graph databases
entered the picture.
Target Audience: This is for the production based sdk for the agentic workflow .
Comparison : I looked at existing solutions:
- Mem0 : stores every entity as a flat node. After a few hundred interactions, you
end up with millions of nodes and relationships. Graph queries that used to take
milliseconds start taking seconds. It also runs vectors and graph as two independent
parallel systems that can drift out of sync. And there's no way to attach document
references to nodes, so when a user uploads a PDF and asks about it later, you're stuck.
- Zep (Graphiti) : more sophisticated with temporal metadata, but self-hosting
requires managing a full graph database directly. At scale, they've publicly documented
spiking graph search latencies and LLM token costs spiraling 3-5x during burst usage.
The operational complexity is significant for a team that just wants a memory layer.
Neither fit what I needed: a clean, async Python SDK that's easy to drop into any
project, keeps token costs predictable, and doesn't explode at scale.
So I built Engram Memory.
What makes it different:
- 1 LLM call to ingest, 0 to recall : extraction happens once at write time;
retrieval is pure vectors + graph traversal + scoring
- Slim context prompts : only node summaries and relationship types go to the LLM
(~735 tokens/ingest avg), not raw properties or embeddings
- Batched Neo4j writes : nodes grouped by label, relationships grouped by type,
written via UNWIND queries
- Single-query traversal : one variable-length Cypher query replaces N+1 BFS
round-trips
- Self-restructuring memory : while the user sleeps, background tasks decay stale
memories, rebuild cluster hierarchies, and archive forgotten facts. The graph literally
reorganizes itself, forming natural clusters and hierarchies like how your brain
consolidates memories during sleep
- Document references : `reference_id` on every node links back to your external
storage (S3, database, whatever), so you can always trace back to the source
- Token tracking : every IngestResult tells you exactly how many prompt/completion
tokens were used, so you can monitor costs in production
- 100+ LLM providers via LiteLLM : OpenAI, Anthropic, Azure, Ollama, local models
Quick start:
pip install engram-memory-sdk
from engram_memory import AsyncMemoryClient, Config
import asyncio
async def main():
async with AsyncMemoryClient(Config()) as client:
result = await client.ingest(
user_id="user-123",
text="I work at Google as a senior ML engineer.",
reference_id="msg-001",
)
print(f"{result.tokens_total} tokens, {len(result.nodes_created)} nodes")
context = await client.recall(
user_id="user-123",
query="What does this person do?",
)
for node in context.nodes:
print(f" [{node.score:.2f}] {node.summary}")
asyncio.run(main()
I know it's not perfect yet it's v0.1.0. But it works, it's tested (211 unit tests + live benchmarks), and it's ready for real usage and feedback.
I'd love feedback, issues, or PRs. What would you want from a memory SDK?
Posted Apr 2, 2026, 11:26 AM UTC