Agent Memory

Agent memory is anything your product remembers about a user across sessions and uses to change its future behavior. The concept exists because users now demand tools that know their preferences, facts, and work without repeating themselves every time. It turns generic chat into an agent that feels like a teammate who actually pays attention.

Designers must own this. Three properties matter. What gets stored. When it gets used. Who can see and change it. Fuzzy answers on any of those three and users stay suspicious.

It is not a chat log. Logs sit there. Memory must alter outputs. It is not raw vector embeddings either. Those are implementation details. The design surface is the contract with the user about what the agent will remember and how it will act on it.

Common confusion comes from treating memory as one undifferentiated bucket. Teams dump preferences, facts, work context, and inferred signals together then act shocked when trust collapses. Split them. Each type demands its own rules for storage, surfacing, and expiration.

ChatGPT shipped memory to millions in early 2025. The model wrote entries during normal conversation. Users later found 400 facts they never approved including misread jokes and embarrassing trivia. The only signal was a toast that lasted two seconds. Claude did it differently. Projects launched as explicit containers. Users name them, fill them, draw the boundaries. Scope becomes obvious because the user drew it.

Cursor rules took memory as code. Drop a .cursorrules file in your repo and the agent reads it on every run. Visible in git. Editable in your editor. Scoped to the project. Exportable by definition. Granola treated every notebook as its own memory room. No global profile. Just the documents present. Each approach shows tradeoffs in automation versus trust.

Use agent memory when building tools for repeated work where continuity creates value. Design tools, coding environments, and personal assistants earn their keep here. The memory moat beats model quality as a retention driver within two years.

Skip it for one off tasks or high privacy use cases where forgetting is the feature. Automated memory reduces friction until it surprises someone with stale data at the wrong moment. Explicit memory builds trust but adds user labor. Pick your pain. There is no universally correct side.

The five principles cut through the noise. Visible. Editable. Scoped. Expirable. Exportable. Nail them and memory becomes a relationship layer instead of a settings page. Ignore them and your product joins the screenshot and complain cycle.

Run the workshop before you ship anything. List the four types for your product. Draw the inspector first. Set default scopes and expiration rules. Write the export format. If it reads like a database dump, throw it out and start again.

Memory is not a backend checkbox. It is the claim your product makes about who the user is. Get it right and users stay. Get it wrong and they feel watched by a stranger who knows too much.

Build memory like a relationship instead of a log file. Every entry either matches the user's self image or grates against it.