Research & architecture

Korely's memory stack is paper-grounded. Every non-trivial mechanism in the product, how facts get extracted, how contradictions get resolved, how context gets ordered before it reaches the model, traces back to a specific published result. This page maps each mechanism to its source, so you can audit our design decisions instead of taking our word for them.

The framing we find most useful is the Forms, Functions, Dynamics taxonomy from Memory in the Age of AI Agents (arXiv 2512.13564). In that vocabulary, Korely's layers map onto this taxonomy as follows:

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 implement

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

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. A real example from our own store: 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:

# deterministic read: same inputs, same lines, every time
› 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)

The bi-temporal chain (Graphiti) is visible in the output, and 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, which is why 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.

Related work we study

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

Forgetting

Korely's temporal decay is scoring decay, never hard deletion. Older facts lose retrieval weight on a half-life schedule, 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 (arXiv 2305.10250) introduced Ebbinghaus-inspired forgetting curves for agent memory, and more recent variants (FadeMem, FSFM) explore learned 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.

The one we publish results on is LongMemEval (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 (arXiv 2507.05257) scores 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 implements:

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.

Scores are self-reported from our own runs. Every question, an excerpt of the memory it was tested on, the answer and the judge verdicts are published on the benchmark page so you can inspect them.

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

See also

• Benchmark, LongMemEval per-axis scores, the method, and every question with its answer and verdict
• Temporal facts, bi-temporal model, valid_from / invalid_at, the as_of parameter, contradiction pipeline in full
• Architecture, the write pipeline vs the read path, why reads carry no model cost
• The graph, entities from the typed facts, typed relationships, facts by entity
• Memory model, memories and facts, scoping, how facts and memories compose in GET /v1/context
• API reference, every endpoint with request and response shapes