Research & architecture

Korely's memory stack draws on published work. Many of the mechanisms in the product, how facts get extracted, how contradictions get resolved, how context gets ordered before it reaches the model, started from a specific paper. This page maps each mechanism to its source, so you can compare our design with the source instead of taking our word for it. A paper that informed a mechanism does not mean Korely reproduces that paper's results: where a paper is a benchmark or a survey, the row says so.

Terms

The Glossary defines the words used across the docs. This page uses memory, fact, valid_from, closed fact, contradiction, as_of, extraction, entity, context block, embedding and erasure as defined there.

Four terms are local to this page:

LoCoMo: a public benchmark of ten long conversations, each with questions about what was said.
LLM-as-a-Judge: a score where a language model grades the answers.
p95 latency: the time under which 95 of 100 requests finish.
Oracle corpus: a benchmark setting where only the sessions that hold the answer are loaded; the harder setting loads many unrelated sessions too (the haystack).

The framing we find most useful is the lens of forms, functions and dynamics from the survey Memory in the Age of AI Agents (Hu et al., 2025, arXiv 2512.13564). In that vocabulary, Korely's layers sit as follows. Layer 1 stores the memories, layer 2 groups them by session, and layer 3 holds the typed facts extracted from them:

Korely layer	Taxonomy position	What lives there
Layer 1, memory store	Factual memory kept as text (the survey's "token-level" form)	Memories in a managed store (Postgres + pgvector, EU-hosted on Cloud), with vector search
Layer 3, typed facts	Factual memory with temporal dynamics	a learned vocabulary of predicates, each in one of 10 families, bi-temporal validity, contradiction handling

Layer 2 is session scope, a run_id filter on Layer 1, so it adds no new memory type.

We didn't pick papers and build features around them. We hit problems while running Korely on our own work: stale facts winning over fresh ones, the model trusting its training data over retrieved sources, contradiction spam in the graph. Then we went looking for who had already solved them.

What we draw on

Each entry: what the paper contributes, what Korely does, and the concept page that documents the mechanism in API-level detail.

Paper	What it contributes	In Korely
Graphiti / Zep, Rasmussen et al. 2025 (arXiv 2501.13956)	A temporal knowledge graph for agent memory with a bi-temporal model (section 2.1): when something held in the world and when the system took it in are separate axes	Every fact carries `valid_from` and `invalid_at` (when it held), plus `created_at` and `closed_known_at` (when Korely learned it, and learned it was over), so point-in-time queries stay correct. See temporal facts
ConflictBank, Su et al. 2024 (arXiv 2408.12076, NeurIPS 2024 Datasets and Benchmarks)	A benchmark of knowledge conflicts from three causes: misinformation, temporal discrepancies and semantic divergences. It measures how models behave; it does not propose a detection method	Contradiction detection at write time in two stages, a cheap candidate filter first and a model-judged resolution second. The two-stage design is ours; ConflictBank is the reference for what a conflict between two statements can be. See temporal facts
Mem0, Chhikara et al. 2025 (arXiv 2504.19413)	Extracted, structured memories answer questions about long conversations at a fraction of the latency and token cost of replaying the whole history. On the LoCoMo benchmark the paper reports an LLM-as-a-Judge score of 66.9% for Mem0 against 72.9% for full context (Table 2), a 91% lower p95 latency and more than 90% lower token cost (abstract)	A dedicated facts surface (`GET /v1/facts`), separate from document search. See memory model
SELF-RAG, Asai et al. 2023 (arXiv 2310.11511)	Reflection tokens: the model decides when to retrieve and critiques whether the retrieved passages, and its own output, are supported	Korely does not train a model. The /v1/context block opens with a short reader note: the memories are the verbatim source, so the model grounds its answer in them and replies that it does not know only when the information is absent. See architecture
Lost in the Middle, Liu et al. 2024 (arXiv 2307.03172)	Models attend most to the beginning and end of the context window, and lose information buried in the middle	The context block keeps only what is likely to answer. Facts are ranked by relevance to the question, weighed by how recently they were confirmed, and capped at the ten best. Memories come most relevant first; in a block above 2,000 tokens, those after the first five are spread so near-duplicates do not crowd out the rest. See architecture
DPR, Karpukhin et al. 2020 (arXiv 2004.04906)	Dense retrieval with a dual encoder: questions and passages are encoded separately into one vector space	One embedding model, but queries and documents are embedded with different prefixes, because a three-word question and a thousand-word note are not the same kind of object. See architecture
FrugalGPT, Chen, Zaharia, Zou 2023 (arXiv 2305.05176)	An LLM cascade: ask a cheaper model first and call the stronger one only when the cheap answer is not good enough	The same idea inside one model. A simple yes/no question on the write path (is this the same relation? which family?) is asked with the least thinking the model allows, and asked again with thinking only when the answer cannot be read. Reads never invoke a generative model at all. See architecture

Bi-temporal facts, concretely

The Graphiti insight is that "when something became true" and "when we learned about it" are different timestamps, and conflating them corrupts point-in-time reasoning. An example: the fact "EU server costs 40" was superseded on 2026-06-07 by "EU server costs 50 euro per month". The old fact wasn't deleted. Its invalid_at was set, so an agent asking "what does hosting cost now?" gets the current answer, while the history stays queryable. The full mechanics are on the temporal facts page.

Why the facts endpoint is deterministic

GET /v1/facts is a filter and a sort, by subject, predicate family and validity window, not a semantic search: same inputs, same outputs. That is also why facts reads are fast: there is no embedding call and no reranker in the hot path, just a database query. Semantic retrieval exists too (POST /v1/memories/search), but it is a separate endpoint with separate semantics, and the agent knows which is which.

In one CLI call:

terminal example

# example output: a read changes only when the stored facts change
› korely facts --entity "EU server" --include-invalidated
  fct_4b9e2a7c1d0f4e8a9c3b5d7e1f2a6c80  EU server · costs · 50 euro per month [from 2026-06-07]
  fct_e2c71f5a9b3d4c6e8f0a1b2c3d4e5f67  EU server · costs · 40 [from 2026-05-21] (superseded 2026-06-07)

To run this call yourself you need the Korely CLI and a key: the quickstart gets you a free one, and the CLI reference lists the commands. The output above shows the bi-temporal chain (Graphiti): the 50 euro fact is live, and the 40 euro fact is kept as history. The read itself is a pure lookup. No generative model ever composes output on the read path; your agent's own model does the reasoning. Reads are cheap for Korely to serve, so every plan includes at least a hundred times more reads than writes. The facts read is available on every tier, including the free Hobby plan, within your monthly query quota and your plan's rate limits.

One stack. The mechanisms above sit behind every surface: the REST API, the Python and Node SDKs, the CLI and the MCP server. There is one fact engine, one graph model and one temporal model, not a pipeline per surface, and each project keeps its own store, so one customer's memories never mix with another's.

Related work we study

Two papers that don't map to a single mechanism but shape how we think about the stack:

Paper	Why it matters here
HippoRAG, Gutiérrez et al. 2024 (arXiv 2405.14831, NeurIPS 2024)	Build a knowledge graph from the text at indexing time and link entity names that mean the same thing (section 2.3), so retrieval does not depend on exact wording. Korely keeps aliases of one entity (an explicit rename, for example), so facts written under the old name and the new one read as one subject. See the graph
Sleep-time compute, Lin et al. 2025 (arXiv 2504.13171)	Let a model work on a context before the questions arrive, which lowers the compute needed once a question does. Korely follows the same principle: extraction and contradiction checking run at write time and in background work, never while an agent waits on a read; a read at most embeds the query. See architecture

Forgetting

Korely's temporal decay is scoring decay, never hard deletion. An older fact weighs less when facts are ranked (an exponential decay with a floor, slower for a fact that has been restated), but the rows stay in the graph. Erasure is a separate, explicit call. When you erase an end user with delete_all, their facts are actually gone, but the ranking algorithm never silently destroys data on its own.

For the design spectrum here: MemoryBank (Zhong et al. 2023, arXiv 2305.10250) updates agent memory with a mechanism inspired by the Ebbinghaus forgetting curve, and more recent work (FadeMem, arXiv 2601.18642; FSFM, arXiv 2604.20300) studies biologically inspired decay and selective forgetting policies. We sit at the conservative end of that spectrum on purpose: a stale fact that ranks too high is visible and correctable by the user, data that disappears silently is not.

Benchmarks

We evaluate on benchmarks that probe the properties this page describes, rather than generic retrieval leaderboards.

We publish results on LoCoMo (see the benchmark page) and on LongMemEval (Wu et al. 2024, ICLR 2025, arXiv 2410.10813): 500 questions over timestamped multi-session haystacks. Its temporal-reasoning subset probes event time: Korely stores each memory's event time (the write's timestamp, or the day it was stored when none is given) and prints every memory in the context block under that day.

MemoryAgentBench (Hu et al. 2025, arXiv 2507.05257) scores four competencies, one of them selective forgetting: updating or invalidating a memory when new information contradicts it, the property Korely's two-stage invalidation targets. We have not published a run on it yet.

Our publishing principle: numbers ship with methodology, including the question categories where the system loses, so you can judge the result instead of a headline score.

How the write path works

Fact extraction and contradiction checking run when something is written. The read path never invokes a generative model: a search or context read embeds the query, and a facts read is a database query. Here is the full write pipeline, annotated by the paper it draws on:

Stage	What happens	Paper grounding
Embed	Content is embedded with asymmetric prefix routing: queries and documents carry different prefixes because a three-word question and a thousand-word note are not the same kind of object	DPR, Karpukhin et al. 2020
Store	The memory is stored and the call returns. The next two steps run afterwards in a background worker, off the read path	Sleep-time compute, Lin et al. 2025
Extract facts	(subject, predicate, object) triples are typed against a learned vocabulary of predicates in 10 families and stamped with `valid_from`	Graphiti / Zep, arXiv 2501.13956
Contradiction check	Candidate conflict filter first; model-judged resolution second. Opposing fact gets `invalid_at` set, never deleted	ConflictBank, Su et al. 2024

Every subsequent read is a pure data retrieval. The intelligence ran once, at write time. For a detailed diagram of the two paths, see Architecture: reads without an LLM.

How we evaluate: connecting claims to results

The paper table maps mechanisms to sources. The benchmark page maps those mechanisms to measurable outcomes on public datasets.

Our evaluation principle: numbers ship with their method, including the axes where the system is weak, so you can judge a result rather than a headline score.

What we claim	How it is tested	Where to read
Answers from memory beat answers from the whole history	LoCoMo, Mem0's protocol (`gpt-4o-mini` as reader and judge, categories 1 to 4): 86.9% (1,338 of 1,540) with Korely's memory against 79.9% when the reader gets the whole conversation, with about a fifth of the tokens.	Benchmark
Temporal reasoning over when things happened	The LoCoMo temporal questions account for almost all of that gap: 253 correct against 167 of 321. On LongMemEval (oracle split) temporal-reasoning is 116 of 133 and knowledge-update 65 of 78.	Benchmark
Overall quality on a second benchmark	LongMemEval, oracle split, the benchmark's own reader and judge prompts (`gpt-4o-2024-08-06`): 87.2% (436 of 500). The paper reports 87.0% for GPT-4o given the evidence sessions directly, so here the memory matches that.	Benchmark

Scores are self-reported from our own runs, one run each, made in October 2026 on version 0.1.36. No later release has been run in full, so they are not a measure of the version in production today. The judge alone moves a LoCoMo score by about 7 points, so every number comes with its reader and judge. This is a directional signal, not a leaderboard entry. The benchmark page gives the method, the categories, and the limits.

Going deeper

The concept pages walk through each mechanism with API-level detail:

Temporal facts: the bi-temporal model, contradiction resolution, and point-in-time queries
Memory model: memories and facts, scoping (user_id / agent_id / run_id, where run_id labels memories and facts with one run or session and memory search and the memory listing can filter on it), and how reads compose
The graph: the entities named by the typed facts, their relations, and how an entity read returns every fact where an entity is subject or object
Architecture: the read path versus the write path, and why reads are retrieval, not generation

Read a paper we should know about? We mean it. If there is published work on agent memory, temporal knowledge graphs, or forgetting policies that you think beats what's described here, email [email protected].