We shipped persistent memory for our AI agent last week. Two days later, I asked it a simple question — "do you remember what we talked about?" — and the answer came back garbled: the same sentence, repeated nine times, drowning out everything else it actually knew.
That's not a hallucination. That's a real bug, and it took about twenty minutes of live debugging to find.
The setup
The memory system stores episodes — raw statements the agent hears — then a background consolidation job extracts them into structured facts on a rolling interval. Straightforward enough. Auto-capture watches the conversation and writes new episodes as they happen.
What actually happened
I pulled the raw episode table and found this:
22:50:33 | "Synapcores CE is NOT open-source please remember that"
22:52:05 | "Synapcores CE is NOT open-source please remember that" <- duplicate
22:57:45 | "Synapcores CE is NOT open-source please remember that" <- duplicate
Same sentence. Three separate episode IDs. Three separate embeddings computed. Three consolidated facts. And critically — no new messages arrived between any of these captures. Nothing new was said. The system just kept re-writing the same thing.
The actual root cause
Auto-capture doesn't trigger only on new content — it fires on a recurring interval and re-scans a fixed window of "recent conversation." That part is a reasonable design. The bug is what happens next: it never checks whether the content in that window was already captured last cycle. Every fire is treated as fresh, unconditionally, forever, as long as the conversation stays idle.
So a quiet stretch of conversation — someone steps away, or a long tool-heavy turn takes a few minutes — doesn't just do nothing. It actively re-writes the same facts over and over, silently multiplying storage and embedding cost, and degrading every future recall, because the retrieval ranking now has to wade through N duplicate copies of the same fact to find the one thing that's actually different.
Why this is worse than it sounds
The failure mode isn't "wastes some disk space." It's specifically that recall quality degrades in proportion to how long a conversation sits idle — the exact opposite of what you'd want from a memory system. The longer you don't talk to your agent, the noisier its memory of you gets. That's a genuinely bad incentive structure to ship by accident.
Where it stands
Filed as a bug against the capture logic, not the storage engine — the underlying CREATE MEMORY primitives (the actual write/read/consolidate pipeline) held up cleanly under a controlled retest: write, wait a full consolidation cycle, recall — correct result, first try, no duplication. The bug is specifically in when auto-capture decides to fire, not in what happens once it does.
The honest lesson here isn't really about our specific bug. It's that "capture on a timer" and "capture on genuinely new content" sound like the same design decision until you actually watch what happens during an idle stretch — and the only way we caught it was live-querying the actual storage tables mid-conversation, not trusting the "auto-captured 3 memories" log line that reported success every single time.
If you're building anything with a background capture-and-consolidate loop — memory, caching, sync jobs, anything that re-scans a window on an interval — this is worth checking for directly: does a quiet period produce zero writes, or does it silently produce the same write again?
