Product

What is ENGRAM

ENGRAM is a cloud memory layer for AI agents. It gives an orchestrator and every sub-agent its own associative memory — built on a knowledge graph rather than flat text summaries — and lets them share what matters through explicit, revocable grants.

A graph, not a summary

Most memory tools store context as compressed text: a rolling summary, or a pile of extracted facts. ENGRAM stores a graph. Every conversation, document, and saved article is broken into entities — people, technologies, concepts, projects — each linked to the memories that mention it. Recall follows those links, so a question about one topic can surface something learned weeks earlier because the two share an entity, not because they share a keyword.

If you've used a tool like Obsidian, you already know the appeal of a linked graph of notes. The difference is what the graph is for: Obsidian's is one you wire by hand and mainly look at, while ENGRAM builds its graph automatically from your agents' activity and traverses it to retrieve the right memory on a query, rather than leaving it as a picture to browse.

Why not a shared markdown vault? A folder of notes gives agents files to read. ENGRAM gives them an entity graph to reason over: automatic linking, associative retrieval, and a memory each agent owns rather than a common pile everyone edits.

How recall works

When an agent asks something, ENGRAM extracts the entities from the query, resolves them to nodes in the graph, then runs Personalized PageRank seeded from those nodes — spreading activation across connected memories and passages to find what's most related. A second pass biases the ranking toward the agent's own most important memories, so recall leans toward what it actually works on. There is no model writing database queries in the loop; retrieval is graph traversal end to end.

For the mechanics — working memory, consolidation, and the retrieval pipeline in full — see How ENGRAM Remembers in the documentation.

What we measured

We tested associative recall against the compression baselines most assistants use today — recent messages, and LLM-written summaries. On short histories, compression wins: there isn't enough graph to traverse. As histories grow long and document-heavy, graph retrieval pulls ahead, and on the hardest cross-topic questions it won 87% of the time against a recent-messages baseline.

Honest about the numbers. Those results are from our April 2026 test on synthetic multi-session data, judged by an LLM, and measured against compression baselines — not a head-to-head with other memory vendors. There's also a cold start of roughly twenty conversations before the graph is dense enough to help. The write-up is on the blog.

How it's built

ENGRAM is a managed, multi-tenant cloud service, not a library you self-host. The knowledge graph lives in Neo4j; agents drive everything through a Model Context Protocol server, each authenticated by its own identity. Isolation and audit come as defaults rather than as something you assemble. The next page covers what that unlocks once you have more than one agent.

Saying what's true, and who may do what

Two things follow from letting agents write into a shared memory. The first is that recall finds what is relevant and has no opinion about what is true, so a project can declare its ground truth — the articles that are authoritative for one body of work — and agents working under that project answer from the brief rather than from whatever they happen to reach. The same set checks new writing before it lands.

The second is that an agent acting on your behalf is only as safe as the credential it holds. ENGRAM scopes authority per token, not per person: an account ladder decides who may hold what, the token carries the authority, and a credential may never mint one more powerful than itself.

Private beta — by invitation

If you're building an agent harness and want a memory layer your agents can own, tell us what you're building.

Get in touch → info@pvelua.net