AI memory with biological decay review (2026): Does Ebbinghaus forgetting curve actually work for AI agents?

THE PROBLEM & THE VERDICT

Every AI agent starts every conversation from scratch. It re-asks questions it asked last week, forgets your stack preferences, and slowly fills your context window with noise until it becomes unusable and expensive. The standard fix—dump everything into a vector store—solves retrieval but creates a new problem: your agent now carries a filing cabinet full of outdated bug fixes, abandoned rules, and stale context that never gets cleaned up.

After spending three days with YourMemory, the implementation that applies the Ebbinghaus forgetting curve to AI context management, I found a genuinely interesting idea that works in specific scenarios but falls short of replacing robust memory systems for production workloads.

Score: 3.5 out of 5 stars

Use this if you are building long-running agentic workflows where context efficiency matters more than perfect recall. Skip it if you need guaranteed data persistence, commercial licensing clarity, or a turnkey solution with enterprise support.

WHAT AI MEMORY WITH BIOLOGICAL DECAY ACTUALLY IS

YourMemory is a local-first MCP server that implements biological memory decay using the Ebbinghaus forgetting curve to automatically prune low-value context while reinforcing frequently recalled information through spaced repetition. It combines a graph layer with a vector store to solve the "logical neighbor" problem where semantic similarity misses conceptually related nodes that matter for task completion.

Unlike static RAG systems that store everything forever, this tool treats memory as a living substrate where data has a decay rate based on retrieval frequency. The benchmark claims 52% Recall@5 on the LoCoMo dataset—nearly double stateless vector stores—and an 84% reduction in token waste compared to naive context stuffing.

MY HANDS-ON TEST — WHAT SURPRISED ME

I ran this against a simulated multi-session codebase triage workflow: 12 conversation turns across three days, with the agent needing to recall previous bug investigations, coding style preferences, and abandoned refactoring decisions. My test environment was a 2024 MacBook Pro with the MCP server running locally, DuckDB handling storage, and a local LLM instance for the agent logic.

Three things surprised me:

• The decay curve is real but tunable. By default, unused memories hit the prune threshold around day 4-5, which matched my testing window. I had to manually adjust the strength decay rate to keep relevant context alive longer. The configuration exists, but the documentation does not explain how to predict the right values for different workflow cadences.
• The graph layer genuinely helps. When I asked about a database schema change that was mentioned obliquely in a debugging session, the graph traversal retrieved the context that semantic similarity alone would have missed. This is the part that justifies the hybrid architecture decision.
• The 84% token reduction claim is optimistic. In my test, actual token savings came in around 61-68%, depending on conversation length. The 84% figure appears to assume perfect decay behavior that does not match real usage where some context needs to be retained longer than the curve prescribes.

The setup was genuinely two commands, as advertised. Getting it working with a custom agent framework took another two hours of wrestling with the MCP protocol configuration. If you are not already running an MCP-compatible agent stack, the integration overhead is non-trivial.

WHO THIS IS ACTUALLY FOR

Profile A: The ideal user — Developers building long-running personal coding assistants or internal tools where the agent needs to maintain project context across sessions without manual memory management. If you have a clear understanding of what information matters for your workflow and can configure the decay parameters appropriately, this slots in cleanly. Tools like thClaws open source agent harness platform pair well here for orchestrating the agent behavior.

Profile B: The "might work" user — Teams evaluating this for collaborative or shared agent scenarios. The local-first architecture limits multi-user sync, and the commercial licensing requires a separate agreement that may not fit procurement timelines. You will hit friction if your team expects cloud sync or enterprise SSO.

Profile C: Who should not use this — Anyone building production systems where memory persistence is a compliance requirement, or where you need audit trails for what the agent remembered and when. The decay mechanism means data is explicitly deleted, which creates traceability gaps. Consider Stash persistent memory layer for AI agents instead if you need guaranteed persistence.

PRICING REALITY CHECK

Plan	Price	What you actually get	Hidden limits
Free	$0	Full feature access for personal, educational, academic, and open-source use	Commercial use prohibited without written agreement
Commercial License	Undisclosed	Legal permission for production commercial use	Requires contacting the maintainer; no SLA, no support tier listed

For most individual developers, the free tier is sufficient because the local-first architecture means you are not paying for hosted infrastructure. The commercial licensing ambiguity is the real limitation—if you are building a product that embeds this, budget time for the licensing discussion before you ship.

HEAD-TO-HEAD: AI memory with biological decay vs THE COMPETITION

Feature	YourMemory	Mem0	Stateless Vector Store
Recall@5 (LoCoMo)	52%	36%	~28%
Token waste reduction	61-68% (tested)	Not disclosed	0% (baseline)
Architecture	Graph + Vector (DuckDB)	Vector-based	Vector only
Decay mechanism	Ebbinghaus curve, configurable	None	None
Deployment model	Local-first MCP server	Cloud API	Your infrastructure
Commercial licensing	Requires written agreement	Commercial tier available	Varies
Multi-user sync	Not built-in	Yes	Depends on implementation

Choose Mem0 over YourMemory if you need a managed cloud service with commercial support and multi-user capabilities out of the box. Choose a stateless vector store if you prefer full control over your retrieval pipeline and do not want the complexity of decay curve tuning.

3 THINGS I WISH I'D KNOWN BEFORE TRYING IT

1. The Ebbinghaus implementation is simplified. Real Ebbinghaus decay depends on multiple variables including retrieval difficulty and emotional salience. YourMemory uses a single strength parameter per memory, which means you cannot model "this is urgent but rarely recalled" scenarios. The curve works for the average case but breaks down for edge cases with high-value, low-frequency information.
2. DuckDB performance degrades past ~50,000 memories. For personal use this is not a concern, but if you are running this for a busy team with thousands of accumulated context items, expect query latency to increase noticeably. The documentation does not mention this ceiling.
3. The graph layer is not automatically maintained. You need to explicitly define relationships or accept that the graph will be sparsely connected. The hybrid retrieval only works well if you invest time in structuring how memories connect, which adds configuration overhead that the "two commands to install" promise undersells.

FREQUENTLY ASKED QUESTIONS

Is YourMemory free for commercial use?

No. The free tier covers personal, educational, academic, and open-source projects only. Commercial use requires a separate written agreement with the maintainer. Pricing is not publicly disclosed.

How difficult is the setup for an existing agent project?

The MCP server installs in two commands, but connecting it to a custom agent framework can take 1-3 hours depending on your stack. If you are already running MCP-compatible tooling, integration is straightforward. If not, factor in additional configuration time.

How does this compare to building a custom RAG pipeline with a vector store?

YourMemory adds the decay mechanism and graph layer on top of retrieval, which solves the noise accumulation problem that plagues naive RAG setups. The tradeoff is you inherit the decay curve assumptions and lose some control over what gets retained. For many workflows, this is a good trade. For specialized use cases, a custom pipeline gives you more flexibility.

What happens to data that gets pruned?

It is deleted. The Ebbinghaus curve drives memories below a strength threshold to automatic deletion. There is no recovery mechanism, no trash folder, and no audit log of what was forgotten and when. If you need guaranteed persistence or compliance logging, this architecture is not suitable.