Agent Memory Is Three Postgres Extensions in a Trench Coat
September 30 - October 2
Ask a vendor what agent memory is and you get an architecture diagram with four databases on it. It can be one. Every fact an agent stores lands three ways in parallel: raw text for full-text search, an embedding in pgvector, and entity-relationship triples extracted into an Apache AGE graph. Retrieval is one hybrid query across all three, because each index catches recall the other two miss.
I'll build a memory live on the platform my team runs, query it back out of all three shapes, and map every piece to the stock Postgres underneath, because that part works at your job on Monday. The behavior this buys: an agent resumes work it started last week, one agent picks up what another learned, and "why does the agent believe this" becomes a SQL query instead of a shrug. The scars it cost: entity extraction ran twice on the same conversation, the knowledge graph quietly went stale every time a memory updated, and per-agent memory and shared knowledge turned out to need separate constructs, not one table with a scope column. We learned that last one the slow way.