Memory Products: What You Can Actually Build and Sell
Document parsing found its product shape: Agentic Document Extraction - not “a PDF library,” but a service that turns messy documents into clean, structured, usable data. Memory is at the same moment now. The raw ingredients (vector DBs, extraction pipelines, the taxonomy from this series) are commoditizing; the products - opinionated, packaged solutions to one painful memory job - are still wide open.
Below is the product map. Each entry: what it is, who pays for it, why it wins, and which parts of the series (blogs 1-13) it is assembled from.
Category 1: The Pipeline Products (the direct ADE analogy)
1. Agentic Memory Extraction (AME)
One-liner: Feed it any raw interaction data - chat logs, support tickets, meeting transcripts, emails, CRM notes - and get back clean, structured, deduplicated memories: facts, episodes, rules, each with provenance, confidence, and timestamps.
- The job: every company sitting on years of conversations has zero usable memory in them. AME is the refinery: raw exchange in → typed memory objects out (semantic facts, episodic summaries with outcomes/lessons, procedural rules from repeated corrections).
- Who pays: any team deploying an agent onto an existing business - the “cold-start memory” problem. Their agent shouldn’t start as a stranger when ten years of customer history exists.
- Built from: Blog 5 (extraction + reconciliation), Blog 9 (selection criteria, consolidation pipeline), Blog 4 (episode summarization).
- Why it wins: exactly like document extraction, quality-of-extraction is the entire product. An opinionated pipeline with reconciliation (ADD/UPDATE/DELETE/NOOP), dedup, and truth-maintenance beats “we ran an LLM over the logs” by miles - and is measurable (Blog 12), so you can prove you’re better.
- MVP: one connector (e.g., Intercom or Slack export) → memory objects in JSON + a review UI. Charge per thousand exchanges processed.
2. Sleep-Time Consolidation Service (“Dreams as a Service”)
One-liner: A background service that runs between your agent’s sessions: reflects over recent episodes, merges duplicates, resolves contradictions, promotes patterns into facts and rules, applies decay and archival - and hands the agent a better memory every morning.
- The job: everyone builds the write path’s hot path; almost nobody builds the nightly refinery (Blog 9’s disciplines 2-4). It is genuinely hard: reflection prompts, promotion thresholds, safe forgetting.
- Who pays: teams already running agents with memory stores that are quietly rotting - month-six regret, packaged as a cron job.
- Built from: Blog 9 (background/sleep-time, forgetting toolkit), Blog 4 (reflection), Blog 6 (rule promotion with guardrails).
- Moat: the verify-after-eviction harness (Blog 9) as a built-in guarantee: “we never forget anything you’d miss - provably.”
Category 2: The Infrastructure Products
3. Memory Layer API (the Mem0/Zep lane)
One-liner: Two endpoints - add(exchange) and search(query) - and everything in blogs 5, 7, 8, 9 happens behind them.
- Honest note: this lane has funded incumbents (Mem0, Zep, Letta). Enter it only with a differentiated bet: e.g., on-prem/VPC-only for regulated buyers, edge/local-first memory for privacy-branded consumer apps, or radically better economics. Otherwise, build on these rather than against them, and own a layer above (products 5-10).
- Built from: the whole series; Blog 10 is the competitive map.
4. The Team Brain (organizational memory for agent fleets)
One-liner: One shared, permissioned memory across all of a company’s agents and copilots: decisions, conventions, project state, tribal knowledge - so every agent, in every tool, already knows how this company works.
- The job: per-user memory is being solved by the assistants themselves (Blog 10); cross-agent, cross-tool, team-scoped memory is not. The coding agent, the support agent, and the meeting bot each relearn the same org facts today.
- Who pays: engineering and ops leaders standardizing on agents; this is a seat-priced B2B product.
- Built from: Blog 5 (graph shape - orgs are relational), Blog 6 (shared standing instructions - team-level CLAUDE.md as a managed product), Blog 12 (permissions, provenance, multi-writer trust tiers).
- Moat: write-privilege design (who can teach the team brain what?) is a real product problem, not a wrapper - and integrations compound.
5. Portable Memory / the Memory Wallet
One-liner: The user owns their memory profile - facts, preferences, history - stored in their vault, plugged into any assistant (ChatGPT, Claude, Gemini, local models) via connectors; revocable, exportable, inspectable.
- The job: every assistant is building a walled memory garden (Blog 10); users are already asking to migrate profiles between them. Lock-in creates the counter-demand for portability.
- Who pays: consumers/prosumers (subscription), and assistants that integrate it as a trust feature.
- Built from: Blog 5 (profile shape), Blog 12 (visibility, control, deletion as the trust contract - here it is the product).
- Risk to name honestly: platform dependence - assistants must allow injection/export. The wedge is standards-shaped (an “OAuth for memory”) and privacy-branded.
Category 3: The Trust Products (least crowded, most defensible)
6. Memory Observability & Evals (“Datadog for memory”)
One-liner: Instrument any memory stack and answer: what did the agent remember, retrieve, and use - and did it help? Dashboards for retrieval precision, silent-miss rate, re-ask rate, staleness, tokens-per-query; regression suites (LoCoMo/LongMemEval-style plus your own golden set); A/B harness for memory configs.
- The job: Blog 12’s dashboard, which every serious team needs and almost none has built. Memory failures are invisible in normal logging - the answer was merely worse than it could have been.
- Who pays: any team with memory in production; lands beautifully alongside existing LLM-observability spend.
- Built from: Blog 12 (metrics + failure taxonomy: not-stored / stored-wrong / not-retrieved / ignored / stale - the debugger UI writes itself), Blog 11 (token economics reporting: “your memory saved $X this month” is a renewal-proof chart).
- Why it wins: sells to users of Mem0/Zep/DIY stacks rather than competing with them; vendor-neutral positioning.
7. Memory Firewall (write-path security)
One-liner: A filter in front of the memory store: every candidate write is re-stated, scanned for instruction-like content and injection patterns, provenance-bound, and trust-tiered; every retrieval is fenced and anomaly-checked. Poisoned-source purge on demand.
- The job: Blog 12’s threat model (MINJA-style persistent injection, experience poisoning) is documented, scary, and unmitigated in most stacks - and procedural writes (Blog 6) need privileged handling nobody implements.
- Who pays: security teams at companies deploying agents that read untrusted content (web, email, docs) and keep memory - which is soon everyone. Security budgets are real budgets.
- Built from: Blog 12 (the whole defense stack, productized), Blog 9 (write path as the control point).
- Moat: an attack-pattern corpus that improves with every customer - classic security-vendor compounding.
8. Forgetting & Compliance Engine
One-liner: Retention policies, PII handling, and provable deletion for agent memory - including the hard part: propagating a deletion through derived memories, summaries, embeddings, and caches.
- The job: “user deletes a conversation → everything learned from it dies, everywhere” (Blogs 9, 12) is a genuine engineering problem (provenance graphs, re-consolidation) and an incoming legal requirement. Nobody wants to build it; everyone will need it.
- Who pays: compliance/legal budgets at enterprises shipping memory-bearing assistants - especially healthcare, finance, EU.
- Built from: Blog 5 (provenance metadata), Blog 9 (forgetting toolkit + sacred deletion rule), Blog 12 (privacy contract).
- Positioning gift: “memory you can legally ship.”
9. Temporal Truth Engine (audit-grade memory)
One-liner: Bi-temporal memory for regulated work: every fact carries validity intervals and source; ask “what does the agent believe now?” and “what did it believe on March 3rd, and why?” Full belief-history, exportable for audit.
- The job: Blog 5’s truth problem is a personalization bug for consumer apps but a liability question for financial advice, healthcare, legal agents. Zep points here; a vertical, compliance-first packaging goes further.
- Who pays: regulated enterprises whose agents make consequential statements.
- Built from: Blog 5 (validity intervals, invalidate-don’t-erase), Blog 7 (temporal graph substrate), Blog 12 (provenance, monitoring).
Category 4: The Vertical Memory Products (memory + one domain, deeply)
The pattern: pick one domain where continuity is the value, and build memory shaped exactly for it. Verticals win because the selection criteria (Blog 9), memory shapes (Blog 5), and eval sets (Blog 12) are domain-specific - a generic layer can’t match them.
| Product | The memory it keeps | Why the vertical pays |
|---|---|---|
| Patient Memory (care/health assistants) | Conditions, meds, symptom timeline (temporal!), what advice was given when | Continuity of care is the product; misremembering is harm - importance scoring and audit are non-negotiable (Blogs 8, 9, 12) |
| Relationship Memory (sales/CS copilots) | Every account’s people, promises made, objections, deal history as episodes+graph | “The rep who never forgets a promise” - direct revenue story; CRM integrations as moat (Blogs 4, 5-graph) |
| Student Model (tutoring products) | What this learner has mastered, where they struggle, what explanation styles worked | Adaptive teaching is memory of the learner; episodic “what worked” drives the few-shot loop (Blog 4) |
| Codebase Memory (dev-agent add-on) | Conventions (procedural), architecture facts (semantic), incident/PR lessons (episodic) | Teams already feel this pain; ships as a managed CLAUDE.md/skills layer + incident-lesson miner (Blogs 4, 6) |
| Companion Memory (consumer AI companions) | Life events, people, ongoing threads, emotional context - recency-weighted | The entire product IS memory; churn is directly a forgetting bug (Blogs 4, 8, 9) |
10. Skill Library Exchange (procedural memory as an asset)
One-liner: A registry + marketplace for learned procedures: agents (and teams) package skills - “how we do DB migrations,” “how to file our compliance report” - versioned, tested, shareable across agents and orgs.
- The job: Blog 6’s compounding asset, made tradeable. Voyager showed skills compose; companies are already hand-writing skill folders - a distribution and quality layer is missing.
- Who pays: teams buying vetted skills; vendors distributing “official” skills for their tools.
- Built from: Blog 6 (skill anatomy: description-indexed, on-demand), Blog 12 (this is high-privilege content - signing, review, and provenance are the product’s spine, not an afterthought).
How to choose (the honest strategic read)
- Fastest to revenue: #1 (AME) and #6 (observability) - both sell to people with an existing, felt pain and don’t fight incumbents.
- Most defensible long-term: #7 (firewall) and #8 (compliance) - security/legal budgets, compounding data moats, and the market is forced toward you by regulation and incidents.
- Biggest ceiling: #4 (team brain) and the verticals - memory shaped to a domain compounds into switching costs a generic layer never gets.
- Crowded, enter only with an angle: #3 (generic memory API).
- The bundle play: note that #1 + #2 + #6 is one coherent product (“we build, maintain, and prove your agent’s memory”) - that bundle is the launchable product this series’ Blog 13 blueprint builds toward.
Every one of these is assembled from the same parts you now know: selection → consolidation → storage → scoring → injection, plus forgetting, eval, and security. The product decision is only ever: which stage, for whom, with which fear ranked first.