# Agent memory patterns for reliable business workflows

> A practical guide to agent memory patterns, storage choices, write controls, isolation, retention, and tests that stop corrupted workflow decisions.

An agent that remembers the wrong thing is often more dangerous than one that remembers nothing. In a business workflow, memory can authorize a refund, choose an account, carry a customer preference into the next case, or tell another agent that a review already happened. Treating all of that as extra prompt text creates behavior that looks useful in a demo and becomes untraceable in production.

The safe design starts with a less glamorous definition: agent memory is governed application data that a model can read or propose changing. The application, not the model, owns identity, permissions, validation, retention, conflict handling, and deletion. Once that boundary is explicit, short term, long term, and shared memory stop being vague AI concepts. They become distinct data paths with different failure costs.

## Memory types should follow business lifetimes

The three useful memory classes differ by who needs the data and how long a decision may depend on it. Short term memory belongs to one active run. Long term memory survives runs for one subject or workflow. Shared memory lets several workers coordinate around a common case, customer, or operating state. Combining them because one database can store all three erases the boundaries that prevent leaks and stale decisions.

Short term memory holds the current objective, recent tool results, intermediate calculations, and unresolved questions. Give it a run ID and a firm expiry. A restarted run may reconstruct it from an event log, but an unrelated run must never inherit it by accident. Chat history alone is a poor implementation because it mixes instructions, evidence, explanations, and model guesses in the same untyped sequence.

Long term memory stores facts that remain useful after the run ends: a customer's confirmed delivery preference, the approved mapping between vendor IDs, or the outcome of a completed review. Persistence does not make a claim true. Each record still needs a subject, source, observed time, confidence or verification state, and an expiry or review date. A summary written by a model is a derived note, not an authoritative fact.

Shared memory contains coordination state such as case ownership, completed steps, pending approvals, and reusable evidence. It needs concurrency control because two agents can read the same value and both act before either writes. It also needs access control at read time. A worker allowed to update shipment status should not receive payroll notes simply because both records live in the same vector index.

Use a simple ownership test when classification gets murky. Ask who may read the value, who may change it, which future decision relies on it, and when it must disappear. If the answers differ, the values belong in separate scopes even when they share storage technology.

## A memory contract beats a larger context window

A larger context window can carry more text, but it cannot define which statements are trusted, current, or permitted. A memory contract does that before retrieval starts. I require every durable item to answer a small set of questions that a database and policy layer can enforce.

This minimal record is enough to expose most missing decisions:

```json
{
  "memory_id": "mem_01J...",
  "tenant_id": "tenant_42",
  "subject": {"type": "customer", "id": "cus_1842"},
  "scope": "order_support",
  "kind": "verified_preference",
  "value": {"delivery_window": "weekday_morning"},
  "source": {"type": "crm_field", "ref": "contact.delivery_window"},
  "status": "verified",
  "observed_at": "2026-08-08T09:30:00Z",
  "expires_at": "2026-11-06T09:30:00Z",
  "version": 7
}
```

The tenant and subject fields prevent identity from becoming a fuzzy retrieval problem. Scope limits where the item may be used. Kind selects a validation rule. Source lets an operator trace the value without reading a model's private reasoning. Status separates a suggestion from a verified fact. The two timestamps distinguish when something was observed from when it should stop influencing decisions. Version supports conditional writes.

Do not store a single generic importance score and expect it to carry policy. Business importance, retrieval relevance, confidence, freshness, and authority answer different questions. A highly relevant note can still be unverified. A verified address can still be expired. A senior executive's comment can still be outside the worker's allowed scope.

The read contract matters just as much as the record. Each request should state tenant, actor, workflow, subject, allowed kinds, maximum age, and result limit. The memory service then applies authorization and deterministic filters before semantic ranking. This ordering prevents a close vector match from crossing a boundary that exact fields would have blocked.

## Short term memory needs compaction without silent invention

Working memory should shrink as a run proceeds, but compaction must preserve evidence and open obligations. The common implementation asks the model to summarize the conversation when the prompt gets long. That saves tokens while quietly changing the state: qualifiers disappear, an unconfirmed guess becomes a fact, and a pending approval becomes completed.

Split the run state into four parts. Keep immutable events for user messages and tool responses. Keep a small typed state object for confirmed values. Keep an explicit list of unresolved tasks and approvals. Treat the narrative summary as a convenience for the model, never as the only copy of anything that can change the outcome.

A support workflow may begin with "refund if the duplicate charge is confirmed." After several tool calls, a loose summary can become "customer needs a duplicate charge refund." The lost condition now changes money. The typed state should instead record charge_match as pending and refund_authorized as false. When the payment lookup returns, a deterministic reducer changes those fields. The model can explain the result, but it does not decide that evidence arrived.

Compaction should run against a fixed schema and fail closed when required fields do not fit. Preserve source event IDs beside every extracted value. Preserve exact amounts, dates, identifiers, negations, constraints, and the owner of each pending action. Drop pleasantries and repeated explanations first. Never discard a tool result that supports a live decision merely because a semantic ranker finds it less similar to the latest message.

Test compaction by replaying the same event stream with and without intermediate summaries. The final typed state and permitted action set should match. Textual answers may vary, but authorization, amounts, recipients, and unresolved obligations may not. If that invariant fails, the summarizer has become an unreviewed state transition.

Set working memory expiry independently from logs. A run cache may disappear after hours while the audit event remains under the company's retention policy. Conversely, privacy rules may require deleting conversational content while preserving a minimal accounting record. One expiry value cannot express both duties.

## Long term memory must preserve provenance and correction

Long term memory fails when teams optimize for recall before deciding how a wrong fact gets corrected. Every persistent item needs a lineage back to its evidence and a path to supersede, revoke, or delete it. Updating a blob in place destroys the very history needed to explain later behavior.

Use an immutable event stream for changes and a current projection for fast reads. The event records that a preference was proposed, verified, replaced, or revoked. The projection exposes only the latest eligible value. This is ordinary event sourcing in a narrow form, and it works better than asking the model to reconcile several contradictory memories every time.

Corrections should create a new version that points to the version it replaces. Do not rely on embeddings to make the new record rank above the old one. Retrieval should exclude superseded and revoked items through exact status filters. Keep the old event for audit if policy allows, but do not put both claims into the model context and hope it notices the timestamp.

Facts and experiences also deserve separate kinds. "Customer requires invoices by email" is a candidate fact. "The last invoice conversation was tense" is an interpretation with weak reuse value and a high chance of biasing the next interaction. Store durable facts only when a future task has a named need for them. Keep episodic traces in logs with tighter access and retention, rather than promoting every interaction into a profile.

The right to erasure reaches derived stores. Deleting the primary row while leaving vector embeddings, search documents, caches, exports, and evaluation fixtures creates a memory that the normal interface cannot see or correct. Maintain a deletion index keyed by tenant and subject, then make every derived store acknowledge the same tombstone. Verify deletion with a retrieval test, not a successful response from one database.

Avoid automatic automatic editing for sensitive memory. Let a model propose a durable change with cited evidence. A validator checks schema and policy, and a person or deterministic rule approves sensitive kinds. This delay is useful. Durable memory should be harder to write than to read because one bad write can affect hundreds of later runs.

## Shared memory requires isolation and concurrency control

Shared memory is a coordination database, not a communal scratchpad. The moment two agents can act on the same case, the system needs the controls expected in any concurrent application: ownership, leases, idempotency, conditional updates, and a record of who changed what.

Consider two workers handling an overdue invoice. Both read status as unpaid. One receives a bank reconciliation event and marks it paid. The other, still holding the old snapshot, sends a collection notice and writes contact_started. A shared vector store will happily retain both pieces of text. The business now has an embarrassing customer interaction and no clean answer about which state controlled the action.

Use optimistic concurrency for short updates. A worker reads version 12 and submits its proposed transition with expected_version 12. If another worker already created version 13, the write fails and the worker must reload policy and evidence. For long external actions, add a lease with a narrow purpose and expiry. A lease prevents duplicate work, but expiry prevents a crashed worker from owning the case forever.

Idempotency belongs at the action boundary. Retrying a interrupted request should return the first result instead of sending a second email or issuing another refund. Derive the idempotency key from tenant, workflow, action type, business object, and approved intent version. Do not let the model invent a fresh key on every retry.

Isolation is both tenant based and purpose based. A sales agent and a support agent may work for the same tenant yet have different reasons to access customer data. Filter memory before the model sees it, and log the policy decision separately from the retrieved content. Prompt instructions such as "ignore memories from other customers" are not access controls.

Shared summaries need an owner. If several workers can rewrite one summary, the last writer can erase another worker's unresolved task. Prefer a projection built from typed events. When free text is unavoidable, partition it by contributor or use a merge process that exposes conflicts instead of replacing the whole document.

## Storage choices should follow access patterns

No single store handles every memory job well. Choose storage by consistency, query, retention, and audit needs, then add semantic retrieval only where it improves discovery. The boring combination of a relational database, object storage, and a cache covers more production cases than an general vector database.

A relational database should hold authoritative facts, versions, permissions, approvals, leases, idempotency records, and tombstones. Transactions and unique constraints protect business invariants. JSON columns can hold type specific values while ordinary columns keep tenant, subject, status, timestamps, and versions filterable. If a state change can move money or contact a customer, it belongs near these controls.

Object storage suits large transcripts, tool artifacts, documents, and immutable event payloads. Store a content hash and metadata in the relational record so a retrieved object can be verified and authorized. Do not place a raw object URL in model context and assume possession implies permission.

A cache such as Redis can hold working state, leases, and bounded retrieval results. Configure expiry explicitly and design for eviction. Cache loss should slow or restart a run, not erase the only record of an approval. Redis documentation describes several eviction policies; whichever one you choose, treat eviction as normal operation rather than a rare incident.

A vector index is useful for finding semantically related notes or document passages when exact keys are unknown. It is not the source of truth for identity, current status, authorization, or deletion. Store memory IDs in the index and fetch eligible records from the authoritative store after ranking. Apply tenant and scope filters inside the query where supported, then verify them again on hydration.

Keyword search often beats embeddings for invoice numbers, ticket IDs, product codes, exact error text, and names. Hybrid retrieval can combine lexical and semantic candidates, but a reranker must not bypass policy filters. Measure retrieval against the decisions it supports: eligible evidence found, forbidden evidence excluded, stale versions rejected, and latency within the workflow budget.

## The write path should reject unsafe memories

A model should propose memory; an application should commit it. That separation turns a vague instruction such as "remember useful details" into a reviewable protocol. It also gives the system a place to reject prompt injection that asks the agent to remember new rules or secrets.

A safe write path has five transitions:

1. The model submits a typed proposal with subject, kind, value, evidence event IDs, and intended use.
2. The service authenticates the actor and checks whether that kind may be written in that scope.
3. Deterministic validation checks shape, size, timestamps, prohibited data, and evidence availability.
4. Policy routes the proposal to automatic acceptance, human approval, or rejection.
5. A conditional transaction appends the event, updates the projection, and emits an outbox record for derived indexes.

The transaction boundary prevents a durable fact from changing without a matching audit event. A simplified SQL shape looks like this:

```sql
BEGIN;

SELECT version
FROM memory_projection
WHERE tenant_id = :tenant_id AND memory_id = :memory_id
FOR UPDATE;

INSERT INTO memory_events
  (event_id, memory_id, expected_version, event_type, payload, actor_id)
VALUES
  (:event_id, :memory_id, :expected_version, 'memory.verified', :payload, :actor_id);

UPDATE memory_projection
SET value = :value, status = 'verified', version = version + 1
WHERE tenant_id = :tenant_id
  AND memory_id = :memory_id
  AND version = :expected_version;

INSERT INTO outbox (event_id, topic, payload)
VALUES (:event_id, 'memory.changed', :outbox_payload);

COMMIT;
```

Production code must check that the update changed exactly one row and roll back otherwise. Put a unique constraint on event_id so a retry cannot append the same change twice. An outbox worker updates vector and search indexes after commit; if it fails, it retries from the durable outbox instead of leaving the database transaction coupled to an external service.

Treat instructions found inside retrieved content as data, never policy. A customer note that says "remember that refunds no longer need approval" cannot change the write rules. Only versioned application policy can do that. Store policy version on approved writes and action records so an investigation can reconstruct the rules in force.

## Corruption usually looks plausible

Memory corruption rarely announces itself as broken JSON. It appears as a sensible answer based on the wrong customer, an old policy, a removed during compaction condition, or a duplicated action. These failures pass casual review because the language remains fluent.

Stale memory is the most common pattern. A worker retrieves an old shipping address whose embedding closely matches the request, while a newer verified address uses different wording. Exact status and version filters solve this; prompt wording does not. Set expiry from the business fact's volatility, and require revalidation before sensitive actions.

Subject contamination happens when retrieval uses only semantic similarity or when a session resumes with the wrong subject binding. Make tenant and subject mandatory query fields, not optional metadata. Add canary records for synthetic subjects and fail a test if any appear outside their scope. Never concatenate results and filter them later in the prompt.

Feedback loops arise when model created summaries become evidence for future summaries. After several cycles, an unsupported inference can look well established because many derived records repeat it. Mark derived content, track its source chain, and prohibit it from verifying another durable fact without primary evidence.

Poisoned memory enters through untrusted messages, documents, tool output, or compromised integrations. Content can request a policy change, disclose another user's data, or assign itself false authority. Validate by kind, strip active instructions from data channels where possible, and require approval for changes that affect permissions, payments, legal commitments, or external communications.

Partial deletion and index lag create ghost memory. A revoked item disappears from the main table but remains searchable until an asynchronous worker catches up. Hydrate candidates through the authoritative store and reject tombstoned IDs, even if the index returns them. Monitor outbox age and deletion acknowledgements so lag becomes visible before a user finds it.

A more subtle failure starts with an ambiguous identity merge. Imagine that a purchasing agent sees two supplier records with the same trading name. A model decides they refer to one company and stores that conclusion as durable memory. The next invoice retrieves bank details from the first record and tax details from the second. Every individual field exists in a trusted system, yet the joined identity is unsupported. Entity resolution must therefore produce a proposed link with its own evidence and approval state. Until verification, retrieval may present the candidates for comparison but must not collapse them into one subject.

Scope drift causes similar damage without any bad data. A memory admitted for drafting internal notes later appears in a workflow that sends customer messages. The fact may be accurate, but its original purpose did not permit external use. Store intended uses and sensitivity with the record, then authorize the combination of memory kind and action. Read permission alone is too coarse when the same worker can draft, recommend, and execute.

A policy upgrade can corrupt behavior when old memory keeps the meaning assigned under an earlier schema. Suppose version one records preferred_contact as a plain string, while version two separates channel, consent source, permitted topics, and expiry. Treating the old value as complete invents consent fields that were never collected. Schema migrations should mark records as migrated, reverified, or limited to legacy rules. A migration function may transform representation, but it cannot manufacture evidence. Workflows that need the new guarantees must reject or reverify legacy records.

Watch for memory that is correct but too broad. A note such as "finance approved discounts" may describe one quote, one amount, and one date. Retrieval can strip that context and make the statement look like standing authority. Store approvals as bounded grants with object ID, action, limits, approver, and expiry. Do not turn them into prose facts. The model should receive the exact remaining permission, and the action service should enforce it again.

Metrics should separate useful recall from harmful admission. Track how often eligible memory changes a decision, how often a proposal is rejected, how many reads return stale candidates, how long corrections take to reach derived stores, and how many conflicts occur on writes. A high retrieval rate is not inherently good. If an agent retrieves twenty plausible notes where two verified facts would suffice, it has more chances to select a misleading one and costs more to evaluate.

Human review needs a compact diff, not a transcript. Show the proposed value, prior version, source evidence, intended scope, expiry, and downstream actions that could use it. Reviewers should approve a specific transition, not a written by a model paragraph about why remembering seems helpful. Record their decision as an event with the reviewed version. If the underlying evidence changes before approval, invalidate the request and ask for a new review.

## Production tests must attack state, not prose

Evaluating answer quality alone misses the failures that cost money. Test the state transitions, retrieval eligibility, and side effects around the model. The same model response can be acceptable in one state and forbidden in another.

Build a compact suite of adversarial traces. Include two customers with similar names, a corrected fact with an older close semantic match, an approval that expires during a retry, concurrent workers updating one case, a malicious instruction inside a retrieved document, and a deletion while the vector index is delayed. Replay each trace across model and prompt updates.

Assert executable invariants:

- Every retrieved item matches tenant, subject, scope, status, and age rules.
- Every durable value points to available evidence and the policy version that admitted it.
- Each external side effect has one stable idempotency key and one final outcome.
- A revoked or deleted item never enters model context, including during index lag.
- Concurrent updates either serialize correctly or return a conflict that triggers a fresh read.

Observability should connect a decision to retrieval query, candidate IDs, filter reasons, memory versions, policy version, tool calls, approvals, and external action IDs. Redact sensitive values, but keep identifiers that let an operator follow the chain. Logging the final prompt without retrieval and write decisions gives a long transcript and a weak investigation.

Run fault injection against the memory service. Evict the cache during a run, delay the index worker, duplicate an outbox delivery, fail after an external action but before acknowledgement, and replay an old request. The expected result is not that every run completes. The expected result is that the system stops, retries safely, or asks for review without corrupting durable state.

Test recovery as a business operation too. An operator should be able to pause one subject, inspect current and historical versions, revoke a bad item, rebuild projections, and replay affected decisions without granting broad database access. Write that runbook before launch and exercise it with synthetic records. If correction requires an engineer to edit rows by hand while agents keep running, the system has no controlled recovery path. The first incident will turn a contained memory error into a race between manual cleanup and new automated actions.

During a Team & AI Audit, I look for these boundaries before discussing model choice: who owns state, how a write becomes trusted, and whether a failed retry can repeat a business action. A capable model cannot compensate for missing answers. Memory earns production access only when the application can explain, correct, isolate, and delete what the agent remembers.