It sounds counterintuitive, but this is a direct consequence of how agents' memory is structured today. Memory inherits the properties of the storage on which it is built.
* A vector database provides associative memory - recognition of familiar patterns.
* A graph provides relational memory - understanding of connections between entities.
➡️ How most agents use the first and ignore the second?
Example:
A study assistant stores three facts in a vector database:
* Mark is in 10th grade.
* The 10th grade has final exams in March.
* The library closes 2 weeks before the exams.
Mark asks: "Will the library be open next week?"
The vector database will return the first and third fact, because the query includes Mark and the library. The middle fact is skipped, as it does not include either Mark or the library.
It is too far in the embedding space to be retrieved in the extracted context. As a result, the agent either responds with incomplete information or completes the answer with a plausible assumption.
This is a typical case. Any query with several reasoning steps goes beyond similarity search.
Increasing the context and retrieving more data is a partial solution. But the accuracy drops by more than 30% if the relevant fact is in the middle of a long context - a classic "lost in the middle" problem.
A large context window does not equal better memory. It's just more space to miss the important thing.
The solution is to stop viewing memory as a single storage and move to three layers:
* Relational layer: stores the source of the fact, the time of recording, and access. The data origin layer.
* Vector layer: stores the semantics and similarity. The retrieval layer.
* Graph layer: stores the connections and dependencies. The reasoning layer.
Each layer fulfills its task:
* Vector database without a graph - similarity without connections.
* Graph without a vector layer - connections without semantic search.
* Relational storage - accounting for the source without the ability to reason.
In the open-source project Cognee, this approach is implemented in practice.
It uses the ECL (Extract, Cognify, Load) pipeline, which in one pass writes data to all three storages and synchronizes them when new data arrives. Vectors and graph edges are built immediately at the indexing stage.
Additionally:
1. Entity resolution: you can specify a domain dictionary, and the system merges duplicates.
For example, "car manufacturer", "automotive manufacturer", and "automotive concern" are reduced to one canonical entity.
2. Local mode by default: installation via pip, everything works locally. For production, you can switch to Postgres and Neo4j without changing the API.
Project co-founder described this approach from scratch and built a full-fledged agent based on Cognee.
••••••••••••••••••••••••••••••••••••••
🤖 Data & ML | @DataXplore