A fact one Bot remembered is reported as remembered to a second Bot, which then never sees it

[Chebaleomkar]

remember from a Bot is deduplicated per person, but read back per Bot.

• server/src/memory/store.ts (the create path for formedBy: "bot") looks for an existing row by (ownerUserId, formedBy = 'bot', importDigest). The unique index has the same shape. It does not include formedByAgentId.
• retrieve returns Bot-formed rows only where formedByAgentId is the asking Bot.

So if Bot A remembers "I prefer metric units" for a person, and Bot B later forms the same sentence, B gets { duplicate: true } with A's id. B never records it, and B's retrieval never returns it. B is told the fact is remembered but never sees it.

There are two possible directions:

1. Scope the dedup lookup and the index to formedByAgentId, so each Bot keeps its own copy.
2. Keep one row per person, and let retrieval include Bot-formed rows from other Bots the person uses.

Which one is intended? I'm happy to send a PR for either.

[kvnloo]

I traced this against current main, and Chebaleomkar's diagnosis matches the store/schema contract exactly.

The surrounding code makes the intended ownership pretty explicit:

• personalMemories.formedByAgentId exists specifically for Bot ownership.
• The schema comment says a Bot-formed memory is delivered only to the Bot that formed it.
• retrieve(..., formed) enforces that with formedByAgentId === formed.botId.
• Source-app revocation is also checked per asking Bot.

Given that contract, I think option 1 is the internally consistent fix: scope Bot-formed deduplication to the forming Bot, rather than widening retrieval across Bots.

Concretely, the partial unique key and both duplicate lookups would become effectively:

(ownerUserId, formedByAgentId, importDigest) WHERE formedBy = 'bot'

That also keeps the current provenance/security property: Bot B does not inherit a fact Bot A observed through an app B may not hold.

The regression matrix I'd want before changing the migration:

1. same Bot + same content twice → one row / duplicate
2. two Bots + same content → two rows
3. Bot A retrieves only A's row; Bot B only B's row
4. deleting A's row prevents A from silently reforming it, but does not tombstone B's independent memory
5. concurrent duplicate formation by the same Bot still collapses to one row

Happy to keep this as architecture guidance rather than competing with the implementation you offered.