Memory Failure Clinic

Agent memory rarely fails as one undifferentiated thing. A fact can be lost at write time, extracted incorrectly, indexed under the wrong identity, displaced by ranking, filtered by time or namespace, changed by consolidation, or altered by an integration after the engine returns it.

The Memory Failure Clinic turns one small, public reproduction into an explicit diagnosis.

Open a clinic case

What to bring

Bring the smallest fictional timeline that still fails:

2026-08-01 / namespace=demo / source=user
Acme is based in Boston.

2026-08-12 / namespace=demo / source=user
Acme moved to Denver.

Query
Where is Acme based now?

Include exact engine, server, MCP, language, and client versions; the minimal code or API calls; expected output; actual output; and explain data when the failure involves recall or ranking.

What we return

Every accepted case should end with four artifacts:

1. Reproduction — a synthetic case another maintainer can run.
2. Localization — the first stage where observed behavior diverges from the expected behavior.
3. Classification — engine defect, integration defect, configuration issue, label ambiguity, or known boundary.
4. Disposition — a fix and regression test, a documented workaround, or a precise statement of what the engine does not currently solve.

The diagnostic path

write → provenance → extraction → index → candidate retrieval
      → scoring → temporal/namespace filters → lifecycle → integration → answer

The first failing stage matters. Tuning ranking cannot recover a claim that was never stored. Rewriting an MCP prompt cannot repair a cross-namespace engine result. A good diagnosis stops at the earliest broken contract.

Privacy boundary

Do not submit private conversations, production memory exports, credentials, access tokens, customer data, personal data, or unredacted logs. Preserve the shape of the failure with invented entities and text.

The Clinic is public. A confirmed synthetic case may become a regression test, benchmark item, release note, or engineering write-up. Only the material in the public issue should be used.

Cases we want

• relevant memory not recalled
• irrelevant memory outranking the answer
• stale memory treated as current
• namespace or tenant isolation failures
• missed or false structured conflicts
• incorrect consolidation, decay, or expiry
• wrong skill or procedure selection
• MCP behavior that differs from direct engine behavior
• reproducible latency or resource regressions

Small, uncomfortable failures are welcome. They are how a memory system becomes trustworthy.