A vector database is a good starting point for AI-agent memory, but a weak final architecture if the agent must remember not only text, but relationships between people, projects, decisions and deadlines. I ran into this with Digital Shadow: Qdrant was good at finding similar fragments, but real life refused to fit into neat collections.

Short version: a serious assistant needs hybrid memory. Vectors for semantic search. A graph for relationships. PostgreSQL for exact data where guessing is unacceptable.

Where pure vector memory broke

At first, Digital Shadow memory was split into collections: projects, partners, crypto and personal. Clean on a diagram. Not in real life. One partner is involved in two projects. One decision from a personal conversation affects business. One document belongs to several contexts.

To preserve connections, I had to duplicate data. I wrote strict prompts, added routing rules and configured tools. The agent still made mistakes: a business meeting went into personal memory; a personal topic appeared in project memory.

The problem was not the prompt. It was the data model.

“Vector search retrieves information by semantic meaning, not just exact keyword matches.” — Qdrant Documentation

That is the strength of a vector database. It is excellent for finding semantically similar material: documentation, FAQs, manuals and meeting fragments. But “similar” and “related” are not the same thing. A query about a partner may require a chain of relationships: person → project → meeting → decision → deadline → document.

Why business context is a graph

Operational memory is made of relationships. Who spoke with whom. When. In which project. What was promised. Why an option was rejected. Which decision depended on another decision.

In a graph model, this is natural: entities, relationships and properties. A person is connected to a project, the project to a document, the document to a risk, the risk to a task, the task to a deadline.

“Nodes represent entities or discrete objects in a domain. Relationships represent a connection between a source node and a target node.” — Neo4j Documentation

That is almost the native language of assistant memory. Not because Neo4j or any graph database is fashionable, but because business questions often require relationship traversal: “what did we promise this client after that meeting?”, “why did we choose this stack?”, “which decisions depend on supplier X?”

What changed in Digital Shadow

I moved to Graphiti + FalkorDB for graph memory and PostgreSQL for exact entities. Evening reflection no longer becomes just a note. It becomes episodes, facts and relationships: who was mentioned, which project it belongs to, which decision appeared and what changed from the previous state.

Graphiti describes this as a Context Graph — a temporal knowledge graph, meaning a graph of entities, relationships and facts that changes over time. For an assistant, this matters more than a static database: business relationships are not permanent. A partner changes role, a project closes, a deadline moves, a contract is updated.

“Graphiti helps you create and query Context Graphs that evolve over time.” — Graphiti Documentation

FalkorDB acts as the graph database in this architecture, while PostgreSQL remains the place for data where the answer must be exact: tasks, deadlines, statuses, access rights, users and settings. If the assistant says “the deadline is in three days,” that should come from an exact table, not a similar memory.

PostgreSQL: facts without poetry

An LLM can explain beautifully, but it should not be the source of truth for operational facts. Vector search can find a similar note, but it does not own the current task status. A graph can show relationships, but it does not replace a transactional system.

PostgreSQL is suited for data that needs structure and auditability: foreign keys, transactions, statuses, deadlines, access rights and logs. The official PostgreSQL documentation highlights SQL support, foreign keys, triggers, views and transactional integrity — exactly the kind of properties an operational layer needs.

The new problem: too much memory

After moving to a graph, the opposite problem appeared. Before, the assistant could miss a connection. Now it sometimes found too many. Ask about a partner and you get three screens of history: projects, meetings, agreements, decisions and related documents. Formally relevant. Practically unusable.

So we had to add priorities and answer modes: short context by default, depth on request, fresh facts above old ones, important decisions above background observations. Memory must not only store. It must dose.

A practical AI-agent memory architecture

A working architecture looks like this:

  • Vector database: documents, notes, meeting fragments and semantic search.
  • Graph database: people, projects, companies, decisions, events and relationships.
  • PostgreSQL: tasks, deadlines, statuses, permissions, settings and logs.
  • LLM: reasoning and explanation interface, not the only source of facts.
  • Policy layer: access rules, priorities, freshness and visibility constraints.

This is more complex than “put everything into a vector database.” But it is closer to reality. Business is not made only of documents. It is made of documents, people, decisions, deadlines and the relationships between them.