Bloomberg's March 2026 coverage of AI memory read like a pricing-war story: a user-acquisition play. Anthropic rolled out Claude memory and sold it as a reason to leave ChatGPT. Once business journalists frame what your product remembers as competitive ammunition, memory is no longer just an engineering toggle.
Inside most product teams, though, it still gets treated that way. Someone selects a vector store, the framework ships a default retention policy, and leadership declares the product "has memory." No one documents what gets kept, what must be discarded, or when the system should tell the user it remembered something. Those are product decisions, and almost nobody writes them down.
What follows is the artifact teams skip: a memory spec you can paste into your next AI PRD, along with guidance on where it belongs in your product context repository.
Memory as a product surface
In 2026, ChatGPT, Claude, and Gemini rebuilt memory. Each one answered the same design question a different way.
- Silent: ChatGPT saves facts about you without fanfare. Memory builds up as conversations continue, and many users only learn it exists after it has already been shaping responses.
- Announced: Claude surfaces every recall and hands control back to the user. Nothing is retrieved invisibly, and editing stored items is a primary workflow.
- Ambient: Gemini wove memory into Personal Intelligence, pulling from Google account context until the line between "remembered in chat" and "known from your data" blurs.
Three heavily resourced teams examined one capability and chose three trust models. That split is the evidence: there is no neutral factory setting here. Each approach bets on a different user reward.
A typical monthly ChatGPT user carries 40 to 80 stored facts about them, most never reviewed. Whatever posture your product adopts, that is the profile scale you own within months of shipping.
.png)
Scale won't spare you. As soon as an AI feature saves anything across sessions, you have already chosen one of these postures, whether you meant to or not.
What goes in the memory spec
Four decisions belong in the spec before launch. Each carries a tempting bad default.
- The store list: information categories the product may save. Write them out: preferences, goals, prior decisions, writing style, org context. "Whatever the model finds useful" is not a policy; it is a screenshot waiting to happen.
- The never-store list: categories that must never persist, even when users offer them freely. Health information, credentials, third-party details, vent-session paste-ins. This list separates a memory feature from a liability machine.
- Retention windows: lifespan per category. A goal stated last week warrants a long shelf life; an inferred mood does not. Bind windows to categories and let idle memories fade rather than pile up.
- User controls: view, edit, delete, export. Fix the minimum set during spec work, because bolting on a memory browser post-launch means migrating data you never organized for human reading.
Start with the never-store list. It is brief, it surfaces the hardest debates, and legal will actually read it.
Decide when the product tells the user it remembered
Disclosure was the 2026 launch decision teams fought over most. It is also the one PMs most often leave to whatever phrasing the model generates.
One practical rule: announce at recall when memory altered the output. If the product shaped an email differently because it knows the user's report structure, say so in a single line. If it applied a saved formatting preference, stay quiet; nobody needs a ping about margins.
Announce at write for sensitive categories. Before storing anything about the user's team, customers, or plans, surface the moment of capture. A low-key "I'll remember your Q4 goal is retention" is one line that buys a correction before a bad fact sets.
Every disclosure needs an off-ramp. A recall notice lacking an "edit this" control feels like surveillance. The same wording with one-tap correction feels like a colleague verifying notes. Copy barely changes; the affordance defines the feature.
Switching costs, memory import, and retention math
Memory may be the first AI capability where PM logic and engineering logic diverge. Engineers want to store more because richer context produces better outputs. The business argument is narrower.
User-curated stored context becomes switching cost. Half a year of corrected memory makes a competitor's empty starting point painful; that is why memory import turned into an acquisition lever the instant rivals shipped exports. If your product accepts a competitor's memory dump, the moat you undermine is the one you are constructing. Spec export, import, and re-verification on day one. Do not ingest a dump on trust.
Coverage rarely dwells here, but founders should: retention is legal surface area, not merely UX. Each stored fact can be discovered, subpoenaed, and requested under GDPR. Enterprise buyers already ask what your product remembers about staff and how to wipe it; a written memory spec converts a three-week security review into a document attachment. The retention window you choose is a risk call that product owns, because only product sees trust, cost, and legal together.
Trust accumulates like storage. A product whose memory is transparent, editable, and well-behaved earns room to remember more. One unsettling recall burns that credit for a quarter.
Wrong, stale, and creepy: spec the correction path
Memory breaks three ways; each deserves its own spec line.
- Wrong memories: the model saved an inference as truth. The user floated a pivot; the product now treats pivoting as the plan. Fix: visible store, one-step edit, and a rule to tag claims by source ("user said" vs "model inferred").
- Stale memories: accurate once, expired now. New job, shipped launch, abandoned goal. Fix: category retention windows plus recency-weighted recall so recent context beats year-old data.
- Creepy recalls: factually correct but socially wrong. Surfacing personal detail at work, or something the user forgot they shared. Fix: write-time disclosure for sensitive categories and recall rules bounded by context, not relevance alone.
These failure modes explain why memory cannot ship as a binary toggle. Toggles have two states. Memory systems have lifecycles, and that lifecycle is what you document.
Where the memory spec lives in your context repository
A memory spec works only if everyone drafting PRDs, humans and agents alike, encounters it every time. That means it sits alongside the rest of your product context: a version-controlled context repository, not a wiki tab that closes forever.
Product Map materializes this layout in your GitHub repo under .productmap, numbered by lifecycle phase so teammates and agents know where each artifact belongs:
.productmap/
├── INDEX.md # master index; agents read this first
├── 00_company/ # team, resources, one-pager, product vision
├── 01_strategy/
│ ├── business-model/
│ ├── competitors/ # competitor-matrix.md
│ ├── mvp-roadmap/ # roadmap.md
│ ├── okrs/
│ ├── product-market-fit/
│ └── segmentation/ # icp-b2b.md, icp-b2c.md
├── 02_generation/
│ ├── ai-ml/ # model cards, prompt library, memory spec
│ ├── design-ux/
│ ├── growth-sales/
│ ├── marketing/
│ └── user-research/
├── 03_analysis/ # analytics, kpis-metrics, unit-economics, finance
├── 04_delivery/
│ ├── agile-process/ # sprint-planning.md
│ ├── backlog-requirements/ # backlog.md, prioritization.md
│ ├── development/
│ ├── lean-experiments/
│ └── risk-compliance/ # retention windows echo here
├── 05_people/ # communication, negotiation, talent
├── 06_operations/ # product-ops playbooks
├── 07_tools/ # tool notes by category
├── 08_frameworks/ # rice.md, jobs-to-be-done.md, okrs.md
├── 09_templates/ # prd, ai-prd, adr, persona templates
└── 10_data/ # analytics, feedback, interviews, researchThe memory spec appears in two places. A reusable section extends the AI PRD template in 09_templates/, so every new AI feature brief opens with memory questions already on the page. The live spec for your shipped product lives in 02_generation/ai-ml/ beside model cards, with retention choices echoed in 04_delivery/risk-compliance/ where compliance checklists reference them.
Once committed, every agent drafting specs picks it up automatically, the same way it reads ICP and the roadmap. That is context engineering in practice: decide once, apply on every run.
The copy-paste spec section
Drop this block into your next AI PRD and complete every row. Empty fields mean you are outsourcing decisions to a framework default.
- Store list: categories the product may persist, with one example each.
- Never-store list: categories the product must drop even when volunteered.
- Source labels: stored as "user said" or "model inferred," recalled accordingly.
- Retention windows: lifetime per category, and what decay looks like.
- Disclosure rules: when the product announces a write, a recall, or neither.
- User controls: view, edit, delete, export, and where they live in the UI.
- Import and export: what leaves with the user, what you accept from rivals.
- Correction path: the flow from wrong recall to fixed memory, in steps.
- Memory metrics: corrections per week, recall-driven edits, deletion rate.
Nine rows. A junior PM can finish a draft in an hour and end debates that Slack would never resolve. ChatGPT, Claude, and Gemini answered these prompts differently. Each answer produced a different product. Yours warrants the same intentionality before a framework default decides for you.
