Skip to content

fix: dedup relevant-memories injection to prevent duplicate bullets - #4

Open
foxsky wants to merge 1 commit into
redis-developer:mainfrom
foxsky:fix/dedup-relevant-memories
Open

fix: dedup relevant-memories injection to prevent duplicate bullets#4
foxsky wants to merge 1 commit into
redis-developer:mainfrom
foxsky:fix/dedup-relevant-memories

Conversation

@foxsky

@foxsky foxsky commented Apr 6, 2026

Copy link
Copy Markdown

Summary

  • Add content-hash dedup filter between searchLongTermMemory results and <relevant-memories> injection
  • The memory server can store the same text across different sessions; without dedup, the top-N results are often 2-3 identical bullets wasting ~67% of the injection token budget
  • Logger now reports unique/total counts for observability

Problem

On a 7-agent OpenClaw board, every <relevant-memories> block contained the same instruction 3 times:

<relevant-memories query-specific="true">
- On April 5, 2026, User received a workspace update notification...
- On April 5, 2026, User received a workspace update notification...
- On April 5, 2026, User received a workspace update notification...
</relevant-memories>

Fix

Read-side dedup using a Set<string> on trimmed text in the auto-recall before_prompt_build handler. Unique results preserved in similarity-ranked order.

Test plan

  • Deploy patched plugin to a gateway with known duplicate memories
  • Verify <relevant-memories> blocks contain unique bullets
  • Check logger output shows injecting 1/3 query-specific memories (deduped) pattern
  • Verify no regression for agents with no duplicate memories

🤖 Generated with Claude Code

The memory server can store the same text content across different
sessions (e.g., repeated workspace-update instructions or identical
heartbeat prompts). When `searchLongTermMemory` returns the top N
results by similarity, these duplicates occupy multiple result slots,
causing the `<relevant-memories>` block to contain 2-3 identical
bullets and waste ~67% of the injection token budget.

This was observed on a 7-agent OpenClaw board where every
`<relevant-memories>` block contained the same instruction 3 times:

```
<relevant-memories query-specific="true">
- On April 5, 2026, User received a workspace update notification...
- On April 5, 2026, User received a workspace update notification...
- On April 5, 2026, User received a workspace update notification...
</relevant-memories>
```

Fix: add a content-hash dedup filter (Set<string> on trimmed text)
between the search results and the injection. Unique results are
preserved in their original similarity-ranked order. The logger now
reports `unique/total` counts so operators can see the dedup ratio.

This is a read-side fix only. A complementary write-side fix (dedup
on insert into the memory server) would prevent duplicates from
accumulating in the first place, but that requires changes to the
agent-memory-server, not this plugin.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant