Memory for AI Tools: Achieving Cross-Session and Cross-Agent Knowledge Persistence

I'm Denis Shokhirev, Enterprise AI architect based in Erlangen, Germany. At DennisCraft AI Studio, I ship production AI systems for B2B clients in DACH — logistics, fintech, and industrial automation — using a stack of Claude, Supabase, n8n, Doppler, and self-hosted Postgres. The #1 pain I see after demo is knowledge loss: agents "forget" key context between sessions or when collaborating on the same workflow, leading to silent failures in production.

Why AI agents lose knowledge in production

Real-world AI agents rarely work alone. In almost every workflow I’ve built with n8n and Claude, agents need to hand off tasks, resume after downtime, or share context. I’ve seen agents process a customer request, pass it off to another agent an hour later, and then fail because there’s no persistent memory — just ephemeral process state. Container restarts or horizontal scaling wipe out everything not explicitly stored. In regulated industries like fintech, this isn't just inconvenient — it causes compliance issues and lost business logic.

Types of memory: what survives production

In practice, only two types are stable for cross-session and cross-agent memory: relational (Postgres/Supabase) for structured state, and vector storage (pgvector) for embedding-based context retrieval. Everything else breaks at scale or with multiple agents.

Architecture: connecting memory to your agents

1. Data model: what to store

I define these core entities in every project: Context (task context), AgentState (current status per agent), ConversationHistory, and KnowledgeBase. Every row gets a session_id for fast recovery after failure and to link agent states together.

CREATE TABLE agent_state (
  id SERIAL PRIMARY KEY,
  agent_id VARCHAR(64),
  session_id VARCHAR(64),
  state JSONB,
  updated_at TIMESTAMP DEFAULT now()
);

CREATE TABLE conversation_history (
  id SERIAL PRIMARY KEY,
  session_id VARCHAR(64),
  message TEXT,
  sender VARCHAR(64),
  ts TIMESTAMP DEFAULT now()
);

2. Integrating with Supabase and n8n

In 11 out of 14 production agents, I use Supabase (managed Postgres + API). n8n connects directly via the Supabase node. Every workflow step writes current state to agent_state, and all messages go to conversation_history.

// Claude Code example: persisting agent state in Supabase
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);

async function saveAgentState(agentId, sessionId, state) {
  await supabase
    .from('agent_state')
    .upsert([{ agent_id: agentId, session_id: sessionId, state }]);
}

3. Vector memory for RAG scenarios

For agents needing embedding-based retrieval (Retrieval Augmented Generation), I use pgvector. Embeddings (from docs, chat history, etc.) are stored in a dedicated table, always with metadata linking them to agent and session.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE embeddings (
  id SERIAL PRIMARY KEY,
  session_id VARCHAR(64),
  content TEXT,
  embedding VECTOR(1536)
);

Security: how to keep memory safe in production

On three recent agent deployments, I caught the same SQL injection pattern in LLM-generated DB layer code. To mitigate this, I use bandit and semgrep for static analysis (see OWASP Top 10), and restrict Supabase access using service roles and unique tokens per agent. For reference, see OWASP 2021 Top 10.

# Static security checks for backend code
semgrep --config=auto ./src/
bandit -r ./src/

For sensitive paths (e.g., fintech, approval workflows), I enable query logging and set up alerts on abnormal access patterns — for example, agents trying to access another session_id’s data.

Advanced: cross-agent shared memory

When multiple agents need to collaboratively process a task (e.g., parser agent and validator agent), I introduce a shared table (shared_memory) keyed by task_id. This lets agents accumulate knowledge and progress asynchronously, with clear audit trails.

CREATE TABLE shared_memory (
  id SERIAL PRIMARY KEY,
  task_id VARCHAR(64),
  key VARCHAR(64),
  value JSONB,
  updated_at TIMESTAMP DEFAULT now()
);

Crucial: enforce access control at the row level, and log all changes. One bug in a single agent should never wipe the shared memory for an entire pipeline.

FAQ

How can I quickly add cross-session memory to an existing AI agent?

At minimum, create a session_state table in Postgres and persist state as JSON after every key step. Synchronize aggressively — overwriting is safer than losing state.

Do I need pgvector or a vector DB for business memory?

Only for RAG or embedding search. For typical status flags or workflow state, regular Postgres is faster and simpler.

Which memory stack is most stable in production?

In my experience: Supabase (Postgres) plus pgvector. I don’t recommend relying on local files or Redis — too many failures with container restarts and scaling.

How do I prevent memory leaks or data exposure?

Use service roles and per-agent tokens, enable row-level security, and run bandit/semgrep static checks. Never expose your DB directly to LLMs.

Can an agent have memory without a database?

Only for trivial cases or ephemeral agents. In production, persistent cross-session memory is essential for any serious workflow.

Has agent memory loss ever caused silent failures or bugs in your production AI stack? How do you enable cross-agent memory in your LLM workflows? I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.