Prinevo Memory: A Domain-Pluggable Context Graph for Long-Term Agent Memory

Most AI agents don’t actually remember you, they search over a pile of old chat logs and guess. Prinevo Memory takes a different approach: it builds a context graph, a structured, typed, time-aware map of entities and relationships, so an agent can reason over what it knows instead of pattern-matching over text.

We built Prinevo Memory to fix that, a long-term memory engine that lets agents actually build a model of you (or your codebase, or your customer) over time, instead of re-reading a pile of chat logs and guessing.

The core idea

Most “memory” products today are really just a search index over saved text. You dump conversation snippets in, you get the most similar-sounding snippet back out. That works for simple recall. It breaks the moment you ask anything that requires reasoning, “where has this person traveled?”, “what changed since February?”, “which of these two things happened first?”

Prinevo takes a different approach:

• It extracts structured facts, not summaries. Every conversation turns into typed (subject–relation–object) claims, not prose. That’s what makes list-style and multi-hop questions answerable at all.
• It tracks time on two axes. When something was said, and when it was true. So the system can answer both “what do we know now” and “what did we believe back then.”
• It grows its own vocabulary. New entities and relationship types are minted automatically as they show up in real usage, no one hand-writes a taxonomy up front.
• One engine, swappable domain layer. The same capture-and-retrieval machinery powers personal memory today and an early engineering/codebase-memory profile, only the vocabulary of “what counts as an entity” changes.

Why the ontology layer is the actual unlock

Here’s the part most memory products skip: before you can retrieve a fact well, you have to have decided what counts as a fact in the first place. That decision, what’s an entity, what’s a relationship, what’s worth writing down at all, is the ontology layer. Get it wrong, and no amount of clever search fixes it downstream.

A flat text store can’t answer “list every place Melanie mentioned visiting” without re-reading the entire conversation history, because it never decided “place visited” was a thing worth tracking as a distinct, structured fact. Prinevo does that decision-making at capture time, not query time, so multi-hop reasoning, “what changed since X,” and list/count questions become structural operations on a graph, not hopeful pattern-matching over chunks of text.

The reason this generalizes is that the ontology isn’t hardcoded. It ships with a starter vocabulary per domain, but new entity types and relationship types get minted automatically the moment real usage needs them, no engineer has to anticipate every possible fact type in advance. That’s what makes the same engine work for personal conversation memory today and engineering/codebase memory tomorrow: only the seed vocabulary changes, not the machinery.

This is also why we think it’s the right foundation for the next phase of agents. Tool-calling and code generation are commodity now, every serious lab ships them. What’s actually defensible is an agent that understands your specific context well enough to reason over it correctly, and that understanding has to be structured to be reasoned over at all. An ontology-first memory layer is what makes that possible, rather than aspirational.

The numbers

We tested it on two independent, third-party benchmarks, not internal ones we designed ourselves:

Benchmark Headline Score Headline Judge Our Own Strict Judge LoCoMo (n=1,986) 83.89% mem0’s published ACCURACY_PROMPT 77.84% LongMemEval (n=500) 82.60% LongMemEval’s own published judge 88.80%

Both benchmarks use claude-haiku-4–5 for capture and answering, and claude-sonnet-5 for judging. The headline judge is chosen per-benchmark for external comparability, mem0’s rubric for LoCoMo since it’s the field’s most commonly cited third-party standard, and LongMemEval’s own rubric for LongMemEval since it’s the benchmark creators’ official standard, but we never optimize development against either. We develop against our own stricter judge only, shown in the last column, so the headline number is never the one we’re chasing.

We also ran a second, deliberately stricter judge alongside the standard published one for both benchmarks, and published both numbers side by side rather than cherry-picking the flattering one. Full methodology, judge prompts, and per-question results are public, because in this field, a bare percentage without its judge disclosed is close to meaningless (we found competitors publishing 3–4 different self-reported numbers for the same benchmark).

The most interesting finding wasn’t the headline score, it was where the remaining errors live. When we broke down every wrong answer, only 2% were true capture misses, the fact was never written down at all. Extraction is already roughly 94% saturated. Meanwhile 79% of wrong answers happened even though the correct fact was sitting right there in the retrieved evidence, the system just picked or assembled it wrong. So the hard problem left isn’t recall, it’s judgment over evidence you already have, which is exactly where typed structure and multi-hop reasoning pay off.

Why this matters more than it sounds

Building software has become commodity. Any team can spin up an agent that calls tools and writes code, that’s no longer the moat. What’s scarce, and what actually compounds, is context: the accumulated, structured understanding of how a specific person, team, or organization actually works, updated continuously and reasoned over correctly. That’s a data and workflow problem, not a model problem, and it’s where we’re focused.

What we’re building toward

Personal memory is the proving ground, not the destination. The same engine already runs a second profile against engineering and repository context, only the entity/relation vocabulary changes, not the machinery. In early internal testing on real engineering Q&A, that profile showed a roughly 54-percentage-point uplift with memory versus without. That number is early and not yet a disclosed, published benchmark the way LoCoMo and LongMemEval are, so treat it as a strong internal signal, not a claim, for now. A full methodology and benchmark for this domain is next. The direction: agents that don’t just execute tasks, but accumulate real organizational context over time, what changed, why, and what’s currently true, the same way a great employee does.

**Prinevo.ai is building the software factory where agents work directly on top of your organization’s context**, not a flat chat log, but a living, structured memory of how your team, your codebase, and your business actually operate.

Full benchmark methodology, judge prompts, and raw results: github.com/keshrisohit/prinevo-memory-benchmarks

Full paper: Prinevo Memory, technical paper