Clarification needed: Multi-user isolation, storage granularity, and handling hallucination loops

[talhaanwarch]

I am currently evaluating Memori for a potential application and have three specific questions regarding architecture and data integrity before I proceed:

1. Scope of Memory Storage Does memori.enable() automatically store the entire conversation history by default? Is there a way to configure it to only store specific parts of the conversation, or is it an "all-or-nothing" storage engine?

2. Multi-User / Multi-Tenancy Support If I have multiple distinct users interacting with the same application backend:

How does Memori handle data isolation?

Is there a built-in mechanism (like session IDs or namespaces) to ensure User A’s conversation context is never shared with or accessible to User B?

3. Mitigation of "Hallucination Loops" I am concerned about data integrity regarding LLM hallucinations.

Scenario: If the LLM generates a hallucinated fact and Memori extracts/stores it as an entity or context.

Risk: In future queries, will Memori retrieve this "false fact" and inject it as context, effectively reinforcing the hallucination?

Question: Does Memori have any existing validation steps or "fact-checking" layers before committing data to the long-term memory to prevent this kind of memory poisoning?

[Ashraf-Morningstar]

Yes, by default, when you enable Memori, it is designed to automatically process and store the entire conversation history to build a comprehensive, evolving context for the agent.
Memori is not strictly an "all-or-nothing" storage engine. You have several levers for control, primarily through its pipeline architecture. The storage is determined by a series of steps (a pipeline) that process each turn of the conversation.

Example:- # User A's session
agent_a = Memori(session_id="user_a_unique_id")
agent_a.enable()

All interactions for User A use agent_a

User B's session

agent_b = Memori(session_id="user_b_unique_id")
agent_b.enable()

All interactions for User B use agent_b

[MahmoudHousam]

@Ashraf-Morningstar I have the same concern and want to make sure the distinction between saving the conversation in separate rows per turn or saving the entire conversation as, for example, a JSON object? Having the conversation stored in rows turn-per-turn is understood and design-aware decision, but having a way to dump the conversation as one entity is helpful for some use cases (using the conversation to evaluate user're response against a rubric)