KITE: Retrieval as a Decision Procedure for Long-Term Conversational Memory: what it means for business leaders

KITE replaces embedding search in agent memory with compiled, checkable retrieval plans over a governed topic index, and reports top accuracy on two long-term memory benchmarks while sending about 1.6k tokens of context per question.

1. What the method is

KITE (Knowledge-Indexed Temporal Evidence) is a memory system for conversational agents that finds past information without embeddings. It turns each conversation session into structured memory entries. Each entry holds the stated fact, a pointer back to the utterances it came from, one to three topics from a governed vocabulary, and typed facets such as participants, entities, objects, places, events and dates. When a question arrives, a language model compiles it into a typed retrieval plan over that same index. The plan reads much like a small database query: which keys must match, which time range applies, whether a later step depends on an earlier result. The plan is validated, then run by fixed code that filters, ranks with a fixed additive score and fuses the result with a lexical keyword channel. The same index and plan always return the same evidence, and when nothing satisfies the plan the system says there is no match.

2. Why the method was developed

Most agent memory products, including Mem0 and the standard vector-store pattern, retrieve by nearest-neighbour search over embeddings. Similarity shows that a memory is about the same subject as the question, not that it answers it. A semantically close memory can outrank the one holding the answer, a fixed top-k always returns something even when nothing fits, and changing the embedding model means re-embedding the whole store. Structured alternatives such as knowledge graphs fail differently: as conversations grow, one concept picks up several labels and its evidence scatters across them. On top of that, questions are worded differently from how memories were filed. The authors' answer has two parts. First, build the store and interpret questions against one shared, governed vocabulary, so a question's terms resolve to the keys the memories were filed under. Second, make the selection step explicit enough that a wrong answer can be traced to the step that failed.

3. Who should care

Our ML and platform engineers who build assistants, copilots or agents that remember users across sessions get a concrete alternative to a vector database for the memory layer, and the code is public on GitHub. Product owners should note where the gains fall: questions about when something happened, and questions that join facts from different sessions, which are the memory failures customers notice most. Support, quality and audit staff who have to explain an agent's behaviour gain a readable plan and an explicit no-match. A retrieval failure becomes something to look up rather than something to guess at from embedding scores. Finance should know that the context passed to the answering model stays near 1.6k tokens per question, though that figure leaves out the extraction and compilation calls. Teams selling personalization should note the weak spot: on LongMemEval-S, KITE answered questions about stated preferences correctly 63.3% of the time, below several competing systems.

4. How the method works

Memory construction runs gpt-4.1-mini over each dated session, with the current topic tree and known entities as context. It produces atomic facts linked to source utterance IDs, resolves relative dates against the session date, and discards entries without provenance. The vocabulary starts from about twelve broad roots. A proposed child topic stays provisional until it appears in three sessions across at least two months, and redundant sibling topics are merged only when repeated consolidation reviews agree. Each key type has a posting list, a direct lookup from key to entries, and dates are stored in order. A compiled plan holds one to three subqueries, each saying what to return, what conditions must hold and what to do with the results. Alternative keys within one type may match, while conditions across types must all hold. If the exact plan finds nothing, predefined relaxations widen designated conditions step by step. Survivors are scored, merged with the lexical and date rankings, cut to a token budget and passed to the answering model.

5. How it was evaluated

The authors used two public benchmarks. LoCoMo has 1,540 questions over ten multi-session conversations: 841 single-hop, 282 multi-hop, 321 temporal and 96 open-domain. LongMemEval-S has 500 questions over much longer histories, in six categories including preferences, knowledge updates and temporal reasoning. gpt-4.1-mini served as extractor, plan compiler, answering model and judge, and accuracy is the share of answers the judge marked correct. Results for the memory systems Mem0, Zep, MemOS and EverMemOS were copied from EverMemOS's published comparison, not rerun. A naive vector baseline (LlamaIndex with text-embedding-3-small, whole sessions as units) and a full-history baseline were run by the authors. A controlled test froze the memory store and compared dense, BM25 and hybrid retrieval with KITE's plans at equal token budgets, also measuring evidence recall. The vocabulary-policy comparison and the ablations were run on LoCoMo only, with small benchmark-specific seed vocabularies.

6. How it performed

KITE scored 93.5% on LoCoMo against 93.1% for EverMemOS and 90.9% for the full history. On LongMemEval-S it scored 86.0% against 83.0% and 56.8%. The clearest gain is temporal reasoning on LongMemEval-S, at 85.7% against 77.4%. Context passed to the answering model averaged 1.5k and 1.6k tokens, against 2.3k and 2.8k for EverMemOS and 20.3k and 105.1k for the full history. Over a frozen store, the plans beat hybrid dense-plus-BM25 retrieval, 93.5% against 87.8% accuracy and 87.4% against 79.9% recall. Preference questions scored 63.3% against 96.7% for MemOS. Swapping in a neural cross-encoder ranker cost only 0.7 points, so the fixed ranker buys inspectability more than accuracy. The LoCoMo margin is within noise, the tables report no variance, the comparison numbers are borrowed, and the token figures exclude the cost of building the store. Our call: pilot it against our current vector memory on our own temporal and multi-session questions. (Source: arXiv 2610.41521, 2026)