xmemory turns messy agent interactions into structured, validated, observable memory, taking care of the reliability work that usually gets scattered across prompts, tools, cleanup jobs, and application code.
Without structure, ambiguity is not an edge case — it is the default.
With structure, facts become addressable, updatable, queryable, and auditable.
Stores notes, summaries, and recalled context.
Stores facts, normalised and clean for complex requests
Thematic recall — "What did we discuss?"
Every read is another act of interpretation
State is reconstructed from prose each time
No deduplication — facts accumulate and conflict
No provenance — changes are untraceable
Ambiguity is the default, not the edge case
Exact lookup — "What timeout did we set?"
Latest state — "What is the current status?"
Relational queries — "Which users affected after release X?"
Explicit unknowns — "What facts are missing?"
Aggregation — "How many incidents since Monday?"
Constraints reject ambiguity instead of guessing
Markdown files are excellent for prototyping,
but they make long-term memory depend on prose, prompts, and luck.
The model creates file structure in the moment. It can follow today’s prompt, but it is not a durable contract across runs, agents, or versions.
A simple question can require reading current notes, old summaries, related files, and compacted history before the agent can answer.
Changing one fact means finding the right sentence, preserving context, avoiding duplication, and hoping nearby meaning stays intact.
The same account, person, incident, or task can appear across many files. Unless the agent reads everything, connections disappear.
Graphs are powerful for connecting knowledge,
but agent memory also needs reliable writes, current state, and explicit semantics.
A graph can connect related entities, but the workflow still needs to know which fact is current, validated, and safe to use.
Memory writes need required fields, allowed values, uniqueness rules, and conflict handling, not only extracted nodes and relations.
“Amy is no longer Kevin’s manager” should update current state, preserve history, and avoid leaving stale edges as live facts.
Real workflows need deletion, provenance, permissions, schema evolution, and observability around every memory operation.
MCP is a great way to expose tools and data,
but it does not turn messy agent memory into reliable state by itself.
MCP can expose database operations, but the agent still has to decide what the user meant and which state should change.
Tables define storage. They do not extract facts from language, map them safely, or explain missing and ambiguous fields.
Real memory writes need validation, deduplication, conflict handling, provenance, retries, and observable decisions.
Without a memory layer, reliability work spreads across prompts, wrappers, app code, cleanup jobs, and eval scripts.
Structure improves memory quality.
xmemory extracts structured data better than one-shot structured output.
We evaluate whether systems can store, update, deduplicate, and retrieve facts and relationships reliably, not just whether they can recall similar text.*
Main markers show extraction quality for single-object schemas. Range spans complex relational schemas to single-field F1 — and xmemory stays ahead of one-shot frontier model APIs.*
* Read more about measurement methodology and open benchmarks in our white paper.
Lower token use than text-based memory by optimising reads.
2x+ fewer tokens
Assuming 10 reads per write,
10 write tokens per 5 read tokens for xmemory,
and 5 write tokens per 12 read tokens for typical text-based storage architecture.
© 2026 xmemory Inc. All rights reserved.
We use essential cookies to run the website and, with your consent, Google Analytics cookies. See our Privacy Policy andT&C.
