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

10
Loading comments…