Quarq Agent: 98.2% on LongMemEval with an agent that remembers

Quarq Agent: 98.2% on LongMemEval with an agent that remembers
98.2%on LongMemEval-S (491 out of 500)
3specialized models instead of one
4different dates for every memory
~$2,500for a full benchmark run
Quarq Agent scores 98.2% on LongMemEval: how to build an agent that actually remembers
I also explain it in this video, about thirteen minutes long, on my Articulator EN channel.

The exam: LongMemEvallink

LongMemEval measures the long-term memory of chat assistants. Its S version has 500 questions, and before each one the system reads a haystack of about fifty conversation sessions; the answer is hidden in one of them. In total, around 57 million tokens, roughly 115,000 per question.

The haystack of one question: fifty conversation sessions in a grid: the answer is in one of them.
Every question hides its answer in about fifty sessions.

There are six types of questions. Three look at a single session: something the user said, something the assistant replied, and a preference mentioned in passing. The other three are harder: combining facts from several sessions, knowing the current version of something that changed, and reasoning about dates ("how long ago did that happen?").

So why not put the whole conversation in the context and be done? Because it does not work. In the article's table, GPT-4o with the full history in front of it gets only 60.2% right; given only the sessions that contain the answer (the "oracle"), 82.4%. Remembering is not reading everything: it is finding what matters.

Bars: full context with GPT-4o, 60.2%; oracle, only the sessions with the answer, 82.4%; Quarq Agent, 98.2%.
Giving the model everything does not give it memory.

The resultslink

Quarq Agent gets 491 of the 500 questions right: it misses only nine. That is 98.2%. And it does it with memory on your own machine: a local FAISS vector index and a layered memory architecture.

By type, the three single-session categories reach 100%. Knowledge updates reach 98.7%, with a single miss. And the two hardest, multi-session and temporal reasoning, land at 97%, with four misses each.

Accuracy by question type: 100% on the three single-session types, 98.7% on knowledge updates and 97.0% on multi-session and temporal reasoning.
Accuracy by type. Note: the scale starts at 90%.

In the leaderboard they publish, second place goes to Mastra (with GPT-5 mini), at 94.87%, followed by Hindsight (with Gemini 3 Pro), at 91.4%. Several systems using GPT-4o land between 81.6% and 86%. Quarq is 3.3 points ahead.

The article's leaderboard: Quarq Agent 98.20%, Mastra OM 94.87%, Mastra OM with Gemini 93.27%, Hindsight 91.40%, EmergenceMem 86%, Mastra OM with GPT-4o 84.23% and Supermemory 81.60%.
The article's leaderboard, 3.3 points ahead of second place.

The article highlights three things. First, its generator (GPT-4.1) is less capable than the newer models many rivals use. Also, temporal reasoning is the hardest category, and its protocol targets the most common failure: confusing when a fact was stored with when it happened. And finally, everything runs locally, while nearly every other system depends on cloud vector databases.

A grain of saltlink

The comparison is worth taking with a grain of salt. Each team builds its own evaluation, with its own judge and models: Quarq grades the answers with GPT-5. And in the article's own charts, some rivals' numbers do not quite match its table: Mastra shows up at 94.37% in one and 94.87% in the other, and Supermemory at 84.6% versus 81.6%.

Mastra's and Supermemory's numbers do not match between the article's charts and its table.
They themselves call the result provisional.

They themselves warn that the result is provisional: it may change as uncertain questions are rerun and fixes are added.

Memory in three layerslink

Inside, the memory has three layers:

  1. Semantic: facts and interaction history, what happened, when, and who was involved.
  2. Procedural: behavioral and operational rules.
  3. Episodic: conversational experiences, with their context.
Three bands: semantic, with dated facts; procedural, with rules; and episodic, with conversational experiences.
Three memory layers, each with its own kind of memory.

Three models instead of onelink

Most memory systems use a single language model for everything: retrieval, generation and memory management. It is like a one-man band, playing every instrument at once and none of them quite right. Quarq splits those jobs into three roles, each with its own model:

Planner (gpt-4o-mini)

A small, cheap model. Before every search it prepares a strategy: it rewrites the question in several related ways, extracts the keywords and picks a retrieval mode depending on how complex the question is.

Generator (gpt-4.1)

It receives the retrieved memories, the procedural rules and the conversation history, and focuses only on writing the answer.

Learner (gpt-4.1)

It does not dump raw text into memory: it makes targeted edits. It adds new facts, updates outdated ones and deletes contradictions, seeing what is in the other layers so nothing is duplicated.

Three cards: planner with gpt-4o-mini, generator with gpt-4.1 and learner with gpt-4.1.
Three roles, three models.
The learner edits memory: it adds Runs on Sundays, changes Lives in Madrid to Lives in Lisbon and deletes the contradiction Hates running.
Add, update, delete: targeted edits, not raw text.

Searching well: HyDE and hybrid retrievallink

The planner uses HyDE (Hypothetical Document Embeddings): instead of searching with the question as it is, it imagines what a document answering it would look like, and searches with that. It is like a police sketch: you do not have a photo of the suspect, but a rough drawing helps you find them in a crowd.

The question as it is finds few memories in the vector space; the imagined document finds more.
Searching with the imagined answer finds more than searching with the question.

Each retrieval pass combines four pieces: vector similarity, keyword search, metadata filters and temporal validation. Being similar in meaning is not enough: the memory also has to contain what matters and fit in time.

Two memories go through the four pieces: a similar one without the keywords and from another time is left out; the one that fits everything gets in.
Being similar is not enough.

And there are two modes. The precise mode uses a similarity threshold of 0.38, for specific facts. The deep mode lowers it to 0.28, for broader recall. It is the difference between fishing with a rod and casting a net.

Two vector spaces: the precise mode, threshold 0.38, with a small circle and few memories; the deep mode, threshold 0.28, with a large circle and many more.
A lower threshold lets more memories in.

Self-correcting retrievallink

What if what it finds is not enough? When the first search does not give enough evidence to answer confidently, the generator can ask for another. The system then runs new searches with the deep threshold, merges the new memories with what it already had, and rewrites the answer under stricter rules against hallucination.

The generator sees that the evidence is not enough, asks for another search with the deep threshold, merges the new memories and rewrites the answer with anti-hallucination rules.
Two passes: the model asks for better evidence instead of making things up.

The idea behind it is simple: the model can ask for better evidence instead of making up what is missing.

The Temporal Truth Protocollink

Reasoning about time is one of the hardest problems in long-term memory. Quarq separates four dates: the storage date (when the memory was saved), the event date (when it actually happened), the narrative date (the benchmark's simulated timeline) and relative dates, like "last week", which are resolved at retrieval time.

A timeline with the event on February 3, storage on April 24, the benchmark's narrative timeline and last week resolved from today.
Four different dates for the same memory.

Think of an old photo you put in a new box today: the box says 2026, but the photo is from your childhood. If someone asks how long ago that summer was, the answer cannot come from the label on the box. That is why the rules are hard-coded: bracketed timestamps are not event dates; a date is never inferred from neighboring memories; two unrelated memories are never assumed to be about the same thing; and "how long ago" is always computed from the actual event.

The four rules of the temporal protocol in a file: three never and one always.
Hard-coded rules, no exceptions.

Quantitative fidelitylink

Numbers are a similar story: memory benchmarks punish sloppy arithmetic. For totals, durations, prices, quantities and counts, Quarq identifies four things: who acts, which action is measured, on what event or object, and how exact it needs to be. And it throws out numbers that are merely nearby or on the same topic: it only adds up the values that meet every condition.

An example of mine: if you ask how much you spent on books, what your brother spent does not count, and neither does the bookshelf.

How much did I spend on books? The novel, the cookbook and the travel guide are added up ($57); your brother's comic and the bookshelf are left out.
It only adds what fits.

Learning without making you waitlink

So you do not notice any delay, the agent learns in the background, after every response, with three safeguards: at most four learning tasks at once, persistent retries that wait longer and longer between attempts, and synchronization barriers during evaluation.

The conversation goes on with no waiting while learning runs in the background, with its three safeguards: at most four at once, retries of 1, 2, 4 and 8 seconds and synchronization barriers.
Learning runs behind the scenes.

And this is how it is evaluated: all memories are wiped; the haystack sessions are fed in chunks of eight messages, with learning enabled; pending learning is allowed to finish; the question is asked with learning disabled, and GPT-5 decides whether the answer is right or wrong.

The five evaluation steps: wipe all memories, the haystack in chunks of 8, wait for pending work, the question without learning and the judge.
Five steps per question.

Every piece came from a failurelink

The first version of Quarq used flat text files, loaded whole into the context on every request. It worked poorly, but it taught them something: a single model cannot optimize retrieval quality, answer quality and cost all at once. That led to four versions: 0.1, with flat files and a single model; 0.2, with vector retrieval and a better memory structure; 0.3, with the three models, the memory editor and the temporal protocol; and 0.4, with self-correcting retrieval, released as open source and ready for production.

Four versions on a timeline: v0.1.0, v0.2.0, v0.3.0 and v0.4.0, the one released as open source under Apache 2.0.
From flat files to self-correcting retrieval.

And every piece came from a specific failure. HyDE, from seeing that single-vector search missed relevant memories. The temporal protocol, from hallucinations like answering "three weeks ago" when the answer was "yesterday". And the second pass, from models confidently making up answers instead of admitting they lacked context.

Three rows, failure to piece: a single vector misses memories to HyDE; three weeks ago when it was yesterday to the temporal protocol; confidently making things up to the second pass.
Every piece came from a failure.

Try it yourselflink

Along with the agent, they released the program they used to run the benchmark, quarqlabs/benchmarks. It is kept separate: it talks to the agent over HTTP, like any other client, instead of importing its code, which makes the evaluation easier to reproduce and inspect on your own. It includes the cleaned dataset, evaluation runs that resume where they left off, a log of the retrieved context, isolated memory for each question, parallel evaluation and cost guidance. The goal: reproducible results instead of opaque leaderboard claims.

To try it, these are the commands from the article:

git clone https://github.com/quarqlabs/agent-oss
cd agent-oss
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# .env: OPENAI_API_KEY=sk-...  USER_ID=local_user  AGENT_ID=my_agent
python agent.py                      # the agent in the terminal
uvicorn main:app --reload            # or as a server
curl -X POST http://127.0.0.1:8000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"prompt": "What do you remember about me?"}'
python run_dataset_evals.py          # the full evaluation
EVAL_WORKERS=4 python run_dataset_evals_parallel.py   # in parallel
A terminal with the commands to clone the repository, launch the agent and the server, ask it what it remembers and rerun the evaluation.
The commands from the article.

A heads-up if you go looking for it: the repository is now called quarqlabs/argus ("Argus Agent"). Its documentation warns that a full LongMemEval-S run has cost about $2,500, roughly five per question, so better start with just a few. Everything is released under the Apache 2.0 license.

Wrap-uplink

Quarq Agent reaches 98.2% on LongMemEval with a deliberately simple architecture: three specialized models, local hybrid retrieval, strict rules for dates and numbers, and a second search when evidence is missing.

In one sentence

Remembering is not reading everything: it is finding what matters, knowing when it happened, and asking for more evidence before making anything up.

What would you want your agent to remember?

Sourceslink

Continue reading

Last posts -->

Have you seen these projects?

Gymnasia

Gymnasia Gymnasia
Expo
React Native
TypeScript
OpenAI
Anthropic

Fitness app with two agents that run entirely on the device, with no backend, so the user's data never leaves the phone. A BYOK conversational coach with local tools and a remote system prompt with offline fallback, plus a food estimator that pulls macronutrients out of a photo of the plate, with barcode scanning against OpenFoodFacts.

LangGraph Deep Researcher

LangGraph Deep Researcher LangGraph Deep Researcher
Python
LangGraph
FastAPI
React
TypeScript
Docker

Multi-agent research system built with LangGraph. A supervisor breaks your question down into topics and launches search sub-agents in parallel; each one compresses its findings before handing them to a writer agent that produces the final sourced markdown report. Live streaming over WebSockets, a configurable model per role and bring-your-own API keys that are never persisted server-side.

Tau

Tau Tau
Python
LangChain

Multi-agent tutoring system for secondary school students, with one agent per subject and course material written and validated by a team of teachers. It was used with real students at a private school in Spain and at a secondary school in Colombia.

View all projects -->
>_ Available for projects

Do you have an AI project?

Let's talk.

maximofn@gmail.com

Machine Learning and AI specialist. I develop solutions with generative AI, intelligent agents and custom models.

Do you want to watch any talk?

Last talks -->

Do you want to improve with these tips?

Last tips -->

Use this locally

Hugging Face spaces allow us to run models with very simple demos, but what if the demo breaks? Or if the user deletes it? That's why I've created docker containers with some interesting spaces, to be able to use them locally, whatever happens. In fact, if you click on any project view button, it may take you to a space that doesn't work.

Flow edit

Flow edit Flow edit

FLUX.1-RealismLora

FLUX.1-RealismLora FLUX.1-RealismLora
View all containers -->
>_ Available for projects

Do you have an AI project?

Let's talk.

maximofn@gmail.com

Machine Learning and AI specialist. I develop solutions with generative AI, intelligent agents and custom models.

Do you want to train your model with these datasets?

short-jokes-dataset

HuggingFace

Dataset with jokes in English

Use: Fine-tuning text generation models for humor

231K rows 2 columns 45 MB
View on HuggingFace →

opus100

HuggingFace

Dataset with translations from English to Spanish

Use: Training English-Spanish translation models

1M rows 2 columns 210 MB
View on HuggingFace →

netflix_titles

HuggingFace

Dataset with Netflix movies and series

Use: Netflix catalog analysis and recommendation systems

8.8K rows 12 columns 3.5 MB
View on HuggingFace →
View more datasets -->