Context across sessions
AI agent memory that persists with purpose
Let agents remember customers, decisions, and working context across sessions while keeping memory isolated by schema and stored in your PostgreSQL deployment.
- AI agent memory
- persistent agent memory
- LLM memory
- conversation memory
Beyond one conversation
AI agent memory that survives the conversation
An agent that greets a returning customer like a stranger is not an assistant — it is a form with better grammar. SyntheticBrew gives agents per-schema, cross-session persistence: they remember customers, context, and decisions across conversations, without your application replaying an entire history on every turn.
Because memory is part of the runtime, not an SDK exercise, every agent gets it by flipping one configuration switch — and every team stops rebuilding the same persistence layer.
Three layers, one runtime
Persistent agent memory, session history, and knowledge — three kinds of remembering
“Memory” hides three different problems. SyntheticBrew separates them so each is stored, scoped, and retained the right way.
| Layer | What it stores | Scope and persistence |
|---|---|---|
| Session history | Every conversation, persisted as a full event log — reasoning steps, tool calls, results, delegations. Replayable exactly as it ran. | Per session, kept in PostgreSQL for debugging, review, and audit. |
| Memory | Cross-session facts the agent retains: who the customer is, what was decided, what context is still open. | Scoped to (tenant, schema, user). Retention configurable per agent, with a max_entries cap. |
| Knowledge | Narrative documents your team curates — manuals, policies, articles — retrieved via agentic RAG while the agent reasons. | Per schema, the same corpus for every user of that agent system. |
There is a fourth, structured kind: typed knowledge graphs, where entities and relationships are declared as a schema and retrieved deterministically — for facts where a wrong ID is unacceptable.
Boundaries by default
LLM memory scoped by tenant, schema, and user
Persistence without isolation is a liability. Every memory entry in SyntheticBrew is keyed by the (tenant, schema, user) triple, and schemas are hard boundaries: one agent system never leaks context into another, and one customer's history never surfaces in another's conversation.
- Schema isolation — your support agents and your internal ops agents keep entirely separate memory.
- Per-agent retention — each agent sets its own
max_entriescap, so memory stays relevant instead of accumulating forever. - Your PostgreSQL — memory and session history live in the PostgreSQL deployment you run, in Cloud or fully self-hosted. Nothing is parked in a vendor store you cannot query.
agent: support-agent memory: enabled: true max_entries: 100 # per-agent retention cap # every entry is keyed by (tenant, schema, user) # stored in your PostgreSQL — Cloud or self-hosted
Continuity your users feel
Conversation memory in production: remembered customers, replayable sessions
The payoff is concrete. A returning customer is recognized, the open issue is still open, and the agent picks up where the last conversation ended — across web, widget, and API surfaces, keyed by stable session identifiers. When something goes wrong, the persisted event log lets you replay the exact run: every reasoning step, tool call, and result.
This is the backbone of support automation — see SyntheticBrew for customer service. And for what your organization knows, as opposed to what the relationship knows, pair memory with agentic RAG.
Keep exploring
Related capabilities
Questions
AI agent memory: common questions
What is AI agent memory?
Facts an agent retains across conversations — who the customer is, what was decided, what context is still open — as opposed to the transcript of a single session. In SyntheticBrew, memory is per-schema, cross-session persistence built into the runtime: entries are scoped to a tenant, schema, and user, stored in PostgreSQL, and available the next time that user returns.
Agent memory vs RAG — what is the difference?
Memory stores what the agent learned from interacting with a specific user: preferences, decisions, open context. RAG retrieves from a knowledge base you curated — documents, manuals, policies — the same corpus for every user. A production agent usually needs both: RAG for what your organization knows, memory for what this relationship knows.
How is memory isolated between agents and tenants?
Every memory entry is scoped by the (tenant, schema, user) triple, and schemas are hard boundaries — one agent system never leaks context into another, and one customer never sees traces of another. All of it lives in PostgreSQL you control, in Cloud or self-hosted.
Can I replay past conversations?
Yes. Sessions are persisted with their full event log — every reasoning step, tool call, tool result, and delegation — so any past run can be replayed exactly as it happened, for debugging, review, or audit.
Agents that remember. Data you own.
Give your agents cross-session memory in your own PostgreSQL — start in Cloud or self-host the open-source engine.