[Feature]: Add support for multi-user / multi-agent / multi-run recording

[Boburmirzo]

Add support for multi-user / multi-agent / multi-run recording

Background

Memori currently supports recording only for a single user. While namespaces exist today, they serve other purposes and shouldn’t be overloaded for user handling.

To make Memori more flexible (for teams, experiments, and multi-agent setups), we should introduce optional identifiers for namespace, agent_id, user_id, and run_id.

Proposal

Extend the storage and SDK to allow passing these IDs as optional scoping keys:

• namespace → optional logical grouping (e.g., environment, tenant, app)
• agent_id → optional identifier for the AI agent
• user_id → optional identifier for the end user
• run_id → optional identifier for a specific execution / workflow run

If not provided, defaults should apply (e.g., default_namespace, default_agent, default_user, default_run).

Example (Python SDK)

mem = Memori(
    namespace="prod",         # optional
    agent_id="shopping_bot",  # optional
    user_id="user_123",       # optional
    run_id="run_456",         # optional
)

mem.record_message(role="user", content="Hi")
mem.record_message(role="assistant", content="Hello!")

history = mem.get_history(user_id="user_123", run_id="run_456")

user_id is more critical to provide one user -> one memory. Under the hood, Memori can manage this with the users table inside one database.

Acceptance Criteria

• Support namespace, agent_id, user_id, run_id as optional fields in SDK and storage
• Defaults apply when not provided (backward-compatible)
• Queries are scoped by any provided combination of these IDs
• Ensure no cross-leakage between different values
• Documentation updated with examples

Why

• Enables multi-user scenarios without breaking single-user apps
• Adds flexibility for multi-agent systems and multi-run experiments
• Keeps backward compatibility by making all fields optional

[sqr00t]

Chanced upon this library and intrigued by the simple interface. Was about to ask how separate user sessions works with this library. Would like to bump up this feature.

The website mentions FastAPI, but docs are unclear how separate sessions may be handled.

Use case for FastAPI may be that:

• FastMCP/ FastAPI/ LangServe based hosting of endpoints for agentic responses.
• Some compatibility with common patterns for user management in such API frameworks via dependency injection of SQLAlchemy resources/ OAuth/ JWT Auth.

[Boburmirzo]

Chanced upon this library and intrigued by the simple interface. Was about to ask how separate user sessions works with this library. Would like to bump up this feature.

The website mentions FastAPI, but docs are unclear how separate sessions may be handled.

Use case for FastAPI may be that:

• FastMCP/ FastAPI/ LangServe based hosting of endpoints for agentic responses.
• Some compatibility with common patterns for user management in such API frameworks via dependency injection of SQLAlchemy resources/ OAuth/ JWT Auth.

@sqr00t Thanks for the question!

This is the reason for this issue exists to support multiple user memories. Looking at my example smart-shopping-assistant backend, that's a perfect real-world example of Memori + FastAPI integration. It shows how you can use customer_id to record user specific conversations or retrieve back.

Once this issue is implemented, you can create one memory per user.

The current FastAPI mention on the website is just a placeholder for the prompt. I am not sure why you are referring to this:)

Let me know if you want to see the specific example for your use case, and we can create an example and update docs?

[Boburmirzo]

Chanced upon this library and intrigued by the simple interface. Was about to ask how separate user sessions works with this library. Would like to bump up this feature.
The website mentions FastAPI, but docs are unclear how separate sessions may be handled.
Use case for FastAPI may be that:

• FastMCP/ FastAPI/ LangServe based hosting of endpoints for agentic responses.
• Some compatibility with common patterns for user management in such API frameworks via dependency injection of SQLAlchemy resources/ OAuth/ JWT Auth.

@sqr00t Thanks for the question!

This is the reason for this issue exists to support multiple user memories. Looking at my example smart-shopping-assistant backend, that's a perfect real-world example of Memori + FastAPI integration. It shows how you can use customer_id to record user specific conversations or retrieve back.

Once this issue is implemented, you can create one memory per user.

The current FastAPI mention on the website is just a placeholder for the prompt. I am not sure why you are referring to this:)

Let me know if you want to see the specific example for your use case, and we can create an example and update docs?

Just follow up on this, currently the simplest approach is to create separate Memori instances for each user and use namespace to uniquely identify users.