add() call goes through a quality loop so the memory store stays useful at scale.
The loop has four outcomes:
Why this exists
Naive memory systems drift because they store one-off instructions as permanent truths. MemoryOS separates durable memory from temporary context. For example, this should not become a permanent preference:Soft buffer for weak signals
Borderline memories are held as candidates instead of being dropped or stored immediately.
A weak signal can be promoted later when the same signal appears again or retrieval feedback confirms it was useful.
Example weak signal:
Two-pass compositional extraction
Some memories are spread across several turns. MemoryOS can run a lightweight first pass to find entities and relationships, then pass those hints into the normal extractor. This is used only when the conversation has enough durable multi-turn signal. Short or low-signal chats skip the extra pass to avoid latency and cost. Example composite conversation:Retrieval feedback closes the loop
After retrieval, your agent can tell MemoryOS whether the memory helped. Use feedback when:- the agent used retrieved memory successfully
- retrieved memory was ignored or not useful
- the user corrected the agent
- the agent needed clarification because memory was missing or wrong
Check job status
add() is asynchronous. Store the job_id if you need to inspect what happened.
PowerShell example:
Dashboard visibility
Tenant Dashboard -> Quality Log shows:- pending weak signals
- reinforced signals
- retrieval feedback events
- correction jobs