Library · Data Practice OS

Agent memory

Reference guide · Published · Source reviewed 2026-11-06

Memory is the most tempting agent feature and the easiest one to get wrong. An agent that remembers your preferences is helpful. An agent that silently writes "the fee for X is Y" into a shared store has created an unreviewed, unowned source of truth.

Status: no agreed pattern. This page summarises a platform team's Options paper: agent memory (draft, 23 Oct 2026, "not ready for a decision"). Treat everything here as analysis to inform that decision, not as a standard.

Two decisions, not one

Scopes. How are individual, team and organisation memory separated, governed and controlled?
Boundary with knowledge. When does a remembered fact belong in an authoritative source (policy, data product, rule repository) instead of in memory?

Storage (AgentCore Memory, a Postgres table in Lakebase, a vector store) comes after both are answered.

Options the platform team compared

Option	What it means	Trade-off
0. No long-term memory	Each session starts fresh	Safe; users repeat context
1. Individual memory only	Per-person memory, nothing shared	Low risk; no team learning
2. Scoped memory	Individual, team and organisation namespaces	Meets the goals most directly; duplicates knowledge
3. Individual memory, with shared facts written to the source after review	Team facts become proposals to the owning source	Keeps one source of truth; needs a review step

The platform team's scoring is partial. The choice between options 2 and 3 depends on open questions about duplication and review capacity.

Practice defaults (until a decision is made)

Start with option 0 or 1. Do not enable shared memory writes until an owner, a review step and retention rules exist.
Prefer option 3 for anything shared. A fact other people will rely on goes to its authoritative source through review, not into memory.
The server builds the namespaces. No memory tool takes an actor ID as a parameter. The platform team found that a general-purpose memory MCP server (122 tools, model-supplied actor_id, no scope check) fails scope separation. The platform team's proposal is a small custom server with three tools only: recall, remember and propose_team_fact.
Scope in IAM or the catalog, not in prompts. Each memory call is limited to the caller's own namespace by policy.
Automatic extraction off until content rules exist (what may be remembered, and that no personal information about other people is kept).
Memory is data, never instructions. Treat recalled content like retrieved text: it can carry prompt injection (Guardrails).
Know where the memory model runs. Managed memory services call a model to extract facts, and that call bypasses your AI gateway. Confirm its region for Data residency. The platform team could not confirm it for AgentCore.
Audit by person. CloudTrail may show only the service role. The memory server writes its own audit line (actor, tool, record IDs, request ID). See Identity propagation.

Interim credentials (if SSO is not ready)

The platform team's proposal for a proof of concept was a per-person token, under strict conditions: hash-only storage, expiry of 30 days or less, never in .mcp.json or a repo, and all tokens revoked at the end of UAT. A private network narrows who can reach a service. It does not identify who is calling.

Not when

Do not use memory to cache reference data or rules. Those have owners and effective dates (Where business rules run after migration).
Do not let a platform feature decide this. "Store agent state in Postgres" is a storage choice, not a memory policy.