Memory & State

• Working memory within a task and session
• Episodic memory: what happened before, per user and per tenant
• Semantic memory: durable facts learned about the domain and the user
• Procedural memory: how this organisation does a task
• Write policy — what earns a place in memory — plus TTL and forgetting
• Redaction, tenant partitioning and the right to erasure

Accountable owner

AI Engineering, with Privacy

• Head of AI Engineering — accountable owner
• ML engineer — recall quality and write policy
• Backend engineer — stores, partitioning, TTL enforcement
• Data privacy officer — retention, erasure, minimisation

Ownership and phase are architectural recommendations, not assessed results.

Pilot may use session-scoped memory only. Long-lived cross-session memory should not ship before poisoning controls and erasure both work.

Signals to watch

• Recall usefulness — memory hits that improved the outcome
• Write rate and store growth per tenant
• TTL adherence and orphaned record count
• Cross-tenant assertions (target zero)
• Erasure completion time

Consolidation, retention and recall policies require evidence. Protect tenant partitions, deletion, consent and quarantine state.

Failure modes

1. Memory poisoning: a hostile fact written once and trusted forever (OWASP ASI06)
2. Unbounded growth degrading recall precision and cost
3. Cross-tenant leakage through a shared store or a careless key
4. A wrong memory causing the same error repeatedly, with confidence
5. Erasure requests that cannot be honoured across derived indexes

Existing tool and standards snapshot · approximately mid-2026. Examples, not required dependencies; verify current versions before adoption.

Memory is where an agent stops being stateless and starts accumulating liability. A write policy is a governance artefact, not an implementation detail.