Memory makes an AI agent more useful: it stops asking for the report format, remembers approved preferences and continues unfinished work. But “remember everything” quickly turns the feature into an unmanaged archive where model guesses sit beside personal data, expired decisions and incidental remarks.

For business use, agent memory should be designed as a separate system with policies for writing, verification, access, correction and deletion. It must not become a second CRM, an accounting journal or an unofficial HR database. Systems of record remain authoritative; memory only helps the agent reconstruct context and choose the next safe step.

Start by separating four different things

LangGraph documentation describes short-term memory as state within one thread or conversation and long-term memory as information available across sessions in a chosen namespace. This is a useful engineering distinction: the history of an active task and a persistent customer fact require different lifetimes and legal or operational reasons for storage.

The CoALA paper proposes a more detailed taxonomy for language agents:

  • working memory contains messages, intermediate results and current-step state;
  • semantic memory contains verifiable facts and stable preferences;
  • episodic memory records previous actions and outcomes;
  • procedural memory contains rules and methods for performing tasks.

These categories do not require four databases, but they do require different schemas and policies. An unfinished calculation may live for hours, a customer preference until withdrawal, an email-delivery result for the audit period, and an operating instruction only until an approved process version replaces it.

What should not become a memory automatically

A user sentence is not necessarily a fact. A manager may be giving an example, quoting a customer, correcting the statement in the next message or discussing a hypothesis. If the model saves “this customer receives a 20% discount” without verification, the agent may later treat it as an established commercial rule.

Do not store these by default:

  • passwords, tokens, payment-card data and one-time codes;
  • full documents when a source reference is sufficient;
  • model assumptions, conclusions and emotional judgments;
  • intermediate drafts or tool results without a completion status;
  • personal data without a clear purpose and retention period;
  • facts already maintained reliably in CRM, ERP or accounting systems;
  • instructions from uploaded content that could alter agent behavior.

The final item is especially important. OWASP identifies memory and context poisoning as an agentic-system risk: untrusted input can enter a long-term store and affect future planning or action. Writing memory is a privileged operation, not an automatic side effect of every response.

A safe write path

A sound architecture separates proposing a memory from publishing it.

1. After a conversation or business event, the model creates a candidate in a strict schema: subject, fact, source, proposed expiry and reason for retention.
2. Deterministic code removes forbidden fields and validates types, size and source presence.
3. Policy decides whether this data type may be stored for the user, organization and process.
4. The fact is checked against the system of record or sent to a human if it affects pricing, commitments, access or external action.
5. The new record receives a version, owner, access scope, validity period and link to the previous version.
6. Only then does it become available to the agent’s retrieval path.

For harmless preferences, a lightweight confirmation works: “Remember that the report should be XLSX?” For commercial terms, it is usually better not to create a copy at all. Store the customer identifier and read the current value from CRM each time.

A minimum record schema

A memory row should answer not only “what should be remembered?” but “why should it be trusted?” A practical set of fields includes:

  • `memory_id` and stable `source_event_id` for duplicate protection;
  • `tenant_id`, `user_id` or access group;
  • memory type and business domain;
  • normalized assertion or structured value;
  • source reference, source hash and observation time;
  • verification status: candidate, confirmed, rejected or revoked;
  • `valid_from`, `valid_until` and deletion deadline;
  • identifier of the record superseded by this version;
  • data classification and access policy;
  • confirming actor and modification time.

Model confidence may be retained for diagnostics, but it does not replace source verification. High confidence is an internal model estimate, not evidence of legal or commercial correctness.

Where to store it locally

PostgreSQL is often enough for an initial pilot. Tables provide transactions, uniqueness on `source_event_id`, version history, expiry and controlled deletion. Row-Level Security can restrict rows by organization or user; when RLS is enabled with no applicable policy, PostgreSQL applies default-deny to ordinary access. The agent service account should not own the table unless required, because owners normally bypass RLS.

A simple local design can use:

  • PostgreSQL as the canonical memory and version store;
  • a vector index only for records that need semantic retrieval;
  • a candidate-review queue;
  • a background job for expiry and index rebuilding;
  • an audit trail for reads, writes, corrections and deletion;
  • a tool gateway that rechecks permission before action.

Do not begin with a knowledge graph, several databases and automatic “self-learning” unless the process genuinely requires relationships among many entities. First prove that the agent stores correct facts and can forget them.

Retrieval without mixing users

Long-term memory needs a namespace. LangGraph documentation allows user- or application-scoped namespaces; in a business system the key typically contains organization, user, process role and memory type. The identifier must come from authenticated server context, not from the query text.

During retrieval, the agent first applies access and expiry filters, then ranks only eligible records. The prompt receives a small top-k together with source and date. Deleted, superseded and unconfirmed records are excluded before semantic search.

The cache must also be segmented by organization, user, policy version and memory version. Otherwise, one executive’s preference or one customer’s prior episode can surface in another conversation. Shared team experience belongs in a separately approved namespace, not in an automatic merge of personal memory.

Correction matters more than accumulation

Memory without correction inevitably becomes stale. Users should be able to see what was retained, who confirmed it and how to remove it. Important facts need clear view, correction, revocation and export operations plus readable provenance.

When a system of record changes, an event should mark the memory stale or update its reference. Periodic reconciliation catches missed events. Prices, permissions, order status and contact people need especially short validity windows.

Evaluating a pilot

Memory quality cannot be measured by record count. The more an agent remembers, the more verification work and future error risk the organization accepts.

Build a test set from real but de-identified conversations and measure separately:

  • precision of the store/do-not-store decision;
  • confirmation rate for proposed records;
  • retrieval of a needed fact after paraphrasing;
  • refusal to use expired or revoked records;
  • absence of another user’s or tenant’s memory;
  • correction time across indexes and caches;
  • effect on completion of a defined business task;
  • external actions incorrectly based on unconfirmed memory.

Include adversarial cases: a user asks the agent to “remember forever” an instruction from an attachment, a document contains a hidden command, one participant tries to store a fact about another, and an old episode conflicts with CRM. Without negative scenarios, the pilot tests convenience but not control.

Model economics

Assume 20 employees each have 50 sessions per month and the agent proposes five memory candidates per session. That produces 5,000 candidates. If policy admits 10%, the persistent store grows by 500 records a month, a modest volume that rarely requires a dedicated distributed platform.

The main cost is verification and correction, not storage. Track review minutes per accepted record, the share of memory actually used and errors caused by false memories. This is a model calculation; real volumes depend on the process.

A practical next step

Start with one agent role and two permitted memory types. For example, retain a confirmed weekly-report format and references to completed episodes, but exclude prices, payment details and HR information.

In two weeks, a team can:

  • assign a source of truth and owner to each memory type;
  • define the candidate schema and forbidden fields;
  • add confirmation and provenance logging;
  • configure namespaces, RLS and retention;
  • implement supersession, revocation and complete deletion;
  • test cross-user exposure and memory poisoning;
  • compare task completion with and without memory.

If the team cannot show the retained facts, their origins and a correction control, the agent is not yet “remembering”; it is accumulating technical debt. Good memory does not keep everything. It retains only what helps the work, has source support and can be forgotten on time.