The hero card stack is simple: short (session), long (profile), system (controls behavior). “Remembers now / remembers you / controls output” is consumer language — useful if you translate it into retention rules and owners before production.
Short — session memory
Session memory is this thread or run: recent turns, tool results, temporary scratch context. It should expire. It should not silently become the policy record. Support workflows fail when “what worked yesterday in chat” cannot be reproduced because session state lived in one agent’s sidebar.
Long — profile memory
Profile memory is persistent facts about a user or account — preferences, tier, locale, open tickets. It needs consent, correction paths, and deletion when customers churn. Profile data is where GDPR questions actually live — not in generic “we use AI.”
System — behavioral control
System memory is instructions and configuration: prompts, tool allow lists, model routing, safety rules. It is not “more history.” It is how the product behaves. Changes here are releases — version, review, eval — not casual edits.
Do not merge the cards
Teams that dump everything into “memory” get unauditable behavior: yesterday’s experiment becomes today’s default. Separate storage, TTL, and access controls per card — then align with the routing diagram in Memory Types for AI Systems.
Go deeper
Memory without boundaries is liability. Data Boundaries for AI Agents names allow/deny for tools; AI Governance Roles and Ownership names who may change system-level configuration.