How Cogni compares
Every number we publish, what it was measured on, and the places Cogni ties or comes second. If you only read one thing: there is exactly one category of question where the difference is categorical rather than incremental, and it is the reason the product exists.
Cross-vocabulary multi-hop: asked once, a vector search scores zero
Some questions can only be answered by joining facts that live in different places and share no words with the question or with each other — a part number leads to a batch, the batch leads to a supplier, the supplier leads to a name. A similarity search matches the first link and then has nothing to take it to the second, so returning more rows does not help. Asked once, it scores 0.00 — on every question, at every depth, with both answering models.
It can still get there by iterating: let the model keep calling and a vector store recovers to near-parity, because eventually it stumbles onto each link. That is the honest shape of this result, and it is still the whole argument — Cogni returns the chain on the first call, and the alternative pays for the same answer in round trips.
| Retrieval | 2 hops | 3 hops | 4 hops | Overall |
|---|---|---|---|---|
| Cogni, spreading | 0.66 | 1.00 | 0.00 | 0.554 |
| Cogni, default mode | 0.45 | 0.98 | 0.00 | 0.476 |
| Cogni with the graph off | 0.00 | 0.00 | 0.00 | 0.000 |
| Plain vector RAG | 0.00 | 0.00 | 0.00 | 0.000 |
Answer accuracy on one recall call, through the real Cogni MCP server, GPT-4o answering, on a generated corpus of entity chains among 250 distractor documents. Mean of 14 runs at the shipped configuration — 45 questions each, every run recording deviations_from_shipped: []. Swap the answerer for Claude Opus 4.8 and Cogni holds the same shape: 0.61 spreading, 0.59 default mode across ten runs. Turning Cogni’s own graph off reproduces the zero exactly — same store, same embeddings, same prompt, so the difference is the traversal and nothing else.
Reassembling a chain scattered across documents
Strip the answering model out and ask a purely mechanical question: of the four documents that carry a chain, how many does a single recall call surface? No model, deterministic, same store, same call, and the same eight rows returned by each side.
| Retrieval | Chain recall@8 | Chain docs found (of 4) | Rows returned |
|---|---|---|---|
| Cogni, as served | 0.850 | 3.4 | 8.00 |
| Plain vector RAG | 0.650 | 2.6 | 8.00 |
| Cogni with the graph off | 0.583 | 2.3 | 8.00 |
5 chains × 3 seeds against 300 distractor documents, text-embedding-3-small, shipped settings, no model in the loop. Retrieval quality, not answer accuracy.
Adding the graph does not cost you the search
Bolting a graph onto retrieval usually means trading away the plain lookup. Cogni runs a full dense-vector search underneath the graph and returns both, so on the benchmarks where a vector store is strongest it should tie. Here is that claim tested rather than asserted — same question, same store, eight rows each, asking simply whether the answer reached you:
| Benchmark | Plain vector RAG | Cogni, as served | Where the answer ranked |
|---|---|---|---|
| Needle in a haystack, to 32k words | 1.000 | 1.000 | 1st → 1st |
| Continual learning, 5 probe kinds | 0.750 | 0.750 | 1.3 → 1.7 |
| LoCoMo long conversations | 0.500 | 0.500 | 2.1 → 2.6 |
Share of questions whose answer reached the eight rows returned, measured 2026-08-12 on the served path with no answering model. These are retrieval numbers and are not comparable to a published answer score — the matching rule is deliberately cruder. What is comparable is the two columns against each other.
A tie is easy to produce by accident — if the graph contributed nothing, every row would come from the vector search and of course the numbers would match. So we checked what the rows were actually made of. In the same runs, roughly half the rows Cogni returned came from graph traversal rather than the vector search (45% on needle-in-a-haystack, 56% on continual, 59% on LoCoMo). Half the context was replaced, and the answer stayed exactly where it was. The floor is not an assumption in our architecture; it survived a large deliberate change to the channel above it.
Where Cogni is second, or simply doesn’t have it
A comparison page that only lists wins is an advertisement. These are the things we would raise if we were evaluating Cogni.
If your problem is slice one long report into chunks and ask questions about it, that is a vector store’s home ground and you should use one. Cogni is built for the memory an assistant accumulates — written statements, one fact at a time, with names in them.
We used to publish a document-chunking benchmark here. We stopped, because we measured what our entity graph does to arbitrary prose and the answer was: nothing useful. Sliced into 400-word windows, the strongest links a novel produces are words like table and hmm, connecting everything to everything. That number was measuring our chunker, not our product, so it told you nothing about what Cogni will do with your memory.
Point-in-time recall works on storage time: what did I know as of last Tuesday. What we cannot yet answer is when was this true — back-fill something you learned late about an earlier period and it gets today’s timestamp. Temporal knowledge-graph products with a bi-temporal model are genuinely ahead of us here. It is on the roadmap as a pair of optional dates on a memory, not a rebuild.
Cogni retrieves by meaning and by graph connection, and both are approximate. Ask for an exact string — an error code, a SKU, an order id, a name spelled unusually — and you are relying on the embedding happening to put it near your query. Several comparable products ship a BM25 keyword channel alongside; we do not yet. It is a known gap, not a design position.
The retrieval method is patent-pending and the code is not public, so you cannot read it or run it yourself. Several alternatives are open source and self-hostable, and if that is a hard requirement they are the better answer today. A self-hosted tier with local embeddings is on the roadmap and not shipped.
Four approaches to agent memory
Memory products are easier to tell apart by architecture than by feature list, because the architecture decides what is possible and what a feature checkbox does not. There are broadly four designs in the market, and the axis that separates them is simply: how many language models sit between you and your own data?
| Cogni | Graph memory built by an LLM | Plain vector RAG | Built-in assistant memory | |
|---|---|---|---|---|
| Follows connections between facts at recall | yes | yes | no | no |
| An LLM reads your text when you save it | no | yes | no | yes |
| A model shapes the results when you recall | no | sometimes | no | yes |
| Same question, same store, same rows every time | yes | no | yes | no |
| One memory shared across different AI vendors | yes | if self-hosted | if self-hosted | no |
| Recall cost grows with your model’s token price | no | yes, at ingest | no | yes |
| Anything to operate (vector DB, GPU) | no | if self-hosted | yes | no |
Columns are architectures, not products, and each cell describes the design rather than any one vendor’s current release. We have deliberately not put competitor names in the grid: capabilities move faster than a marketing page does, and a table asserting what someone else shipped last month is the kind of claim that is wrong by the time you read it. Where a product’s own documentation is the authority, go and read it.
Several serious products — Hindsight, Zep and Graphiti, Cognee and others — build an entity graph and traverse it. Anyone claiming to be the only one doing this is not paying attention. Some of them are excellent, open source, and worth your evaluation.
The common way to build that graph is to have a language model read each memory and decide what it means. Cogni builds and walks it deterministically, with no model at either end. That is what makes recall repeatable, keeps the cost flat regardless of which model you use, and means your memories are never interpreted by a second model before you see them.
What happens as your memory grows
The usual failure mode for a memory product is silent: retrieval keeps returning results, they are just gradually less likely to be the right ones. So the number to watch is not latency, it is whether the search still finds what an exhaustive scan would find.
Cogni widens its search as a store grows to hold that constant, and pays for it in milliseconds:
| Memories stored | Search accuracy | Index lookup | Approx. recall time |
|---|---|---|---|
| 1,000 | 0.992 | 140 µs | ~6 ms |
| 10,000 | 0.992 | 309 µs | ~14 ms |
| 50,000 | 0.996 | 1,018 µs | ~45 ms |
| 100,000 | 0.985 | 2,285 µs | ~101 ms |
Search accuracy is recall@10 against an exhaustive brute-force scan of the same store. A single Cogni recall performs roughly 44 index lookups, which is where the recall-time column comes from. It excludes the embedding round-trip, which is a constant network cost and dominates in practice. Measured on the compiled substrate the hosted service runs.
How these were measured
The settings are the shipped ones. Every Cogni number on this page comes from the same code path and the same default configuration a new free account gets — not a research harness and not a tuned configuration. A figure you cannot reproduce by signing up is not a figure about the product, so we do not publish one.
The corpus has to look like memory. Cogni stores what an assistant writes down: short statements with names in them. Benchmarks that slice arbitrary prose into fixed-size chunks measure something else, so we do not publish results from them — in either direction.
The rows are matched. Cogni’s recall can return more rows than a plain vector search, and more context makes almost any retrieval score look better. Every comparison here caps both sides at the same count, so no margin comes from a bigger budget.
Retrieval numbers and answer numbers are kept apart. Where no model was involved we say so. Retrieval quality is what Cogni controls; what a model then does with good context is a property of that model.
The corpora are synthetic where they need to be. The cross-vocabulary and needle results use generated corpora, because a chain whose links deliberately share no vocabulary is not something you can find pre-labelled, and neither is a haystack you control the length of. The continual-learning scenario is written in-house. The conversation results use the public LoCoMo dataset.
Results in your own use will vary, and here is the honest reason. Cogni’s tools are called by your model over MCP, so how often it checks its memory depends on the model and the prompt. These numbers measure what happens when it does check.
Want a table we haven’t published, or the configuration behind one of these? Ask — support@getcogni.io.
Check it yourself.
Free needs no card. Connect in about a minute, and the cross-vocabulary case is the one to try first.
Get started free