Multi-agent systems have a data problem nobody warns you about. Agent B sees Agent A's final output and nothing else; the reasoning, the dead ends, and whatever Agent A figured out three steps in all get thrown away. So teams of agents re-learn the same lessons every run, and when something breaks, your observability stack tells you what an agent did without telling you what it learned or how that learning spread.
My team spent the past year building a shared memory and knowledge layer for production multi-agent systems, and we made most of the available mistakes. We wired a vector database to a graph database to a relational store and watched the seams leak: entity extraction running twice on the same conversation, a knowledge graph that quietly went stale every time a memory updated, serialization bugs living at the boundaries between stores. "Just share a Postgres table" sounded reasonable too, right up until agents needed isolation and selective sharing at the same time.
I'll walk through what survived. How we ended up with one query surface across vector, relational, and graph data. Why per-agent memory and shared knowledge have to be separate constructs, not one table with a scope column. What conversation-history tiering actually costs and saves, and how to keep an audit trail of what agents learned rather than only what they ran. The patterns transfer whether your stack is Postgres, a dedicated vector store, or something you already regret.