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 three layers decompose cleanly:

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

Toolformer's core finding is that models use tools well when the tool's behavior is predictable. So GET /v1/facts is a filter and a sort, by subject, predicate family, validity window. Not a semantic search. Same inputs, same outputs, every time. That is also why facts reads are fast, typically under 50 ms: there is no embedding lookup and no reranker in the hot path. Semantic retrieval exists too (POST /v1/memories/search), but it is a separate endpoint with separate semantics, and the agent knows which is which.

Both papers, in one CLI call:

# deterministic read: same inputs, same Markdown, every time
› korely facts --entity "EU server" --include-invalidated

## Financial (2 facts)

| Fact                                   | Valid from | Status                  |
|----------------------------------------|------------|-------------------------|
| EU server — costs — 50 euro per month  | 2026-06-07 | active                  |
| ~~EU server — costs — 40~~             | 2026-05-21 | invalidated 2026-06-07  |

The bi-temporal chain (Graphiti) is visible in the output, and the read itself is a pure lookup (Toolformer). No generative model ever composes output on the read path. Your agent's own model does the reasoning, which is why read quotas are an order of magnitude more generous than write quotas. The facts read is available on every tier, including the free Hobby plan, gated only by your monthly query quota.

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, user-initiated surface. When an end user deletes a fact from the Memory Panel, it is 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 first is LongMemEval (arXiv 2410.10813): 500 questions over timestamped multi-session haystacks. Its temporal-reasoning subset is exactly what Layer 3 is built for. Korely preserves event time (valid_from) rather than only ingestion time, which is the property those questions probe.

The second is MemoryAgentBench (arXiv 2507.05257), which scores selective forgetting: updating or invalidating a memory when new information contradicts it. That is what Korely's two-stage invalidation does on every write, so it measures the contradiction pipeline directly.

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

Every mechanism in the paper table above runs exactly once: when something is written. The read path never invokes a generative model. 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, using an open harness so you can reproduce the numbers independently.

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.

The harness is open: clone korely-benchmarks, supply a kor_live_ key and a Groq judge key, and run the same evaluation we did. Scores are self-reported from our own runs; the open procedure is what makes them inspectable.

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: the three layers, scoping (user_id / agent_id / run_id), and how reads compose
• The graph: typed entities, relationships, and how shared-entity traversal connects them
• Architecture: the read path versus the write path, and why reads are retrieval, not generation

See also

• Benchmark — LongMemEval per-axis scores, the open harness, and how to reproduce the evaluation
• 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 — GLiNER entity extraction, typed relationships, shared-entity traversal
• Memory model — three layers, scoping, how facts and memories compose in GET /context
• API reference — every endpoint with request and response shapes