What Memori Is

MemoriLabs has published Memori as an open-source memory infrastructure layer positioned explicitly for production LLM-based agent systems [1]. The project describes itself as “agent-native memory infrastructure” and functions as an LLM-agnostic, datastore-agnostic, and framework-agnostic persistence layer. Rather than coupling memory to a specific model provider or orchestration framework, Memori is designed to sit alongside whatever architecture a development team has already built [1].

The library ships as two separate SDKs: a Python package installable via pip install memori and a TypeScript package installable via npm install @memorilabs/memori [1].

Execution-Derived Memory vs. Conversation-Derived Memory

The central design distinction Memori draws is between memory derived from what agents do versus memory derived only from what agents say. The project’s stated framing is “memory from what agents do, not just what they say” [1].

For production agent systems, this distinction carries operational weight. Conversation-only memory captures the text of exchanges but can miss the broader execution context that accumulates as agents take actions, call tools, or process structured data across sessions. By targeting agent execution and conversation together as sources of persistent state, Memori aims to give downstream agent calls a richer, more structured picture of prior activity [1].

How Integration Works

The integration pattern in both SDKs follows the same structure: instantiate the existing LLM client, wrap it through Memori’s registration method, and attach attribution identifiers for the user and agent process. No changes to the underlying LLM call syntax are required after registration [1].

In Python, the pattern looks like this:

from memori import Memori
from openai import OpenAI

client = OpenAI()
mem = Memori().llm.register(client)
mem.attribution(entity_id="user_123", process_id="support_agent")

In TypeScript, the equivalent is:

import { OpenAI } from 'openai';
import { Memori } from '@memorilabs/memori';

const client = new OpenAI();
const mem = new Memori().llm
  .register(client)
  .attribution('user_123', 'support_agent');

Once the client is registered, conversations are persisted and recalled automatically in the background without additional code at each call site [1]. The attribution call ties memory to a specific entity and process, enabling scoped recall across sessions.

Deployment Options and Infrastructure Compatibility

MemoriLabs offers a hosted path called Memori Cloud, described as a zero-configuration option. Developers sign up at app.memorilabs.ai, obtain an API key, set the MEMORI_API_KEY environment variable alongside their LLM provider key, and can begin building immediately [1]. Full documentation is available at memorilabs.ai/docs/memori-cloud/.

Beyond the hosted path, the library is described as compatible with existing datastores and agent frameworks, with the explicit positioning that it “plugs into the software and infrastructure you already use” [1]. The project does not require teams to replace or reconfigure their current stack.

Who the Project Targets

Memori is aimed at developers building production agent systems who need persistent, structured state across sessions but want to avoid rebuilding their existing architecture to get it [1]. The low-friction registration pattern and environment-variable-based configuration are consistent with a migration path designed for teams that already have LLM infrastructure in place and want to add memory as an incremental layer rather than a foundational replacement.

FAQ

Q. Does Memori require switching LLM providers or agent frameworks? No. The project is explicitly described as LLM-agnostic, datastore-agnostic, and framework-agnostic, designed to integrate into architectures already in use [1].

Q. What identifiers does the attribution call accept? Based on the published SDK examples, the attribution call takes an entity identifier (such as a user ID) and a process identifier (such as an agent name) [1]. No additional attribution parameters are documented in the available source material.

Q. Is Memori Cloud the only deployment option? Memori Cloud is the documented zero-configuration path, but the library’s stated compatibility with existing datastores suggests self-managed deployment is also possible [1]. Specific self-hosted configuration details are not covered in the available source material.

Q. How does memory recall work after registration? According to the SDK examples, recall happens automatically in the background after the client is registered. A subsequent LLM call can retrieve facts from earlier in the session without explicit retrieval code at each call site [1].

Q. Which Python and Node.js versions are supported? The available source material does not specify minimum runtime versions for either SDK [1].

Key takeaways

  • Memori is an open-source, LLM-agnostic memory infrastructure layer for production agent systems, available as Python and TypeScript SDKs [1].
  • The core design targets execution-derived state, not conversation text alone, as the source of persistent memory [1].
  • Integration requires wrapping an existing LLM client with a single registration call and setting environment variables, with no changes to downstream call syntax [1].
  • Memori Cloud provides a zero-configuration hosted path via API key; the library also claims compatibility with existing datastores and frameworks [1].
  • The project is positioned for teams that want to add persistent agent memory incrementally without replacing their current architecture [1].