PostgreSQL can be a good home for agent memory because it can keep structured records, metadata, permissions, transactions, and vector embeddings close together. The important design decision is not whether to add a vector column. It is deciding which memories deserve structured fields, which need semantic retrieval, and which should never be copied out of the source system.

Use JSONB for explicit, inspectable facts

A preference, workflow state, source ID, timestamp, owner, or expiry is easier to reason about as structured data. JSONB can hold flexible attributes while ordinary columns handle the fields you filter and authorize most often. Keep a schema or validation rule around the values; flexible should not mean anything goes.

Use vectors for finding related experiences

An embedding can help find a previous conversation, similar case, or relevant passage when the wording changes. It should be a retrieval aid, not the source of truth. Store the tenant, actor, memory type, source, created time, expiry, and deletion state beside the embedding so a similarity search cannot float free of the rules around it.

Filter before you trust similarity

Apply tenant and permission filters in SQL before the result reaches the agent. A semantically perfect memory from another organisation is still the wrong answer. Re-check the source record when a remembered fact will drive a high-impact action. The agent should know whether it is recalling an explicit preference, a past episode, or a document that may have changed.

Plan the lifecycle from the beginning

Give short-term memories an expiry. Version or supersede facts rather than silently overwriting them. When a person asks for deletion, remove the structured row, embedding, summaries, and caches that could bring it back. Start with a small memory store, measure whether it reduces repeated work, and add complexity only when the workflow can explain why it needs it.