MemoRizz: a memory layer for Python agents, with a noncommercial licence

A framework that treats memory as the foundation

MemoRizz is a Python framework that connects persistent memory, models, prompts and reasoning, so that agents can recall what matters, reuse experience and make better decisions across sessions. The framing in the README is the intelligence plane, and the argument is worth taking seriously: the model layer and everything that helps it think, the LLM, the prompts, reasoning strategies such as planning, reflection and tool selection, plus the memory and retrieval that supply context, are all part of the same plane, and its job is decision quality. A bad plan or a hallucinated tool call is framed as a problem of that plane rather than of the model alone.

Memory is presented as the base of it, with three jobs: retain information, retrieve relevant context, and refine what an agent knows over time.

The project is by Richmond Alake, published on PyPI as memorizz, with documentation built from a docs/ directory through mkdocs, an examples tree with fifteen separate directories covering topics from a zero to hero walkthrough to tool caching and memory transfer, and a changelog that the README links. The version in the packaging metadata is 0.17.3, and the three most recent releases all landed on 2026-10-18, which tells you the project is shipping quickly and is still pre-1.0.

Five memory types behind one provider contract

The memory system is split into five types, each with its own documentation page under docs/memory-types, and each aimed at a different kind of recall.

Episodic memory holds conversation history, past interactions and summaries. Semantic memory holds knowledge bases, entity facts, preferences and personas. Procedural memory holds registered tools, recorded workflows and reusable skills. Short-term memory is working context and semantic caching. Shared memory is a workspace for agent coordination and handoffs.

Behind those types sits a single provider contract, which is the part that matters for adoption. Memory can be scoped by agent, user and conversation, and the storage can start on the local filesystem or move to MongoDB, Oracle, or Notion with separate vector storage, without the calling code changing. That is the difference between a library that wraps one database and one that treats storage as replaceable.

On the write side, the framework ingests files and folders into a knowledge base with configurable chunking, embeddings, and semantic or hybrid search. On the read side it manages context by deduplicating retrieved memories, summarising and compacting history, letting an operator inspect recall decisions, and controlling retention and forgetting.

The model side is equally broad. The agent framework is built on MemAgent and MemAgentBuilder, with assistant, workflow and deep_research modes, and it connects to cloud or local model providers. The keywords in the package metadata list openai and anthropic alongside ollama, and the dependency set includes the Ollama daemon SDK, which the comment in pyproject.toml explains is kept in the base install so a default zero-config local stack works on a bare pip install memorizz with a running Ollama daemon.

Forgetting by suppression, never by deletion

The forgetting mechanism is the most distinctive idea in the project, and the README describes it in enough detail to be judged.

Retrieval ranks memories by recency since last use, by stored importance and by relevance. A recall reinforces a memory, so what gets used gets stronger. Then a governed planner suppresses records whose retention has decayed, and the key word there is suppresses. Records are not deleted, and every suppression is approved and reversible.

That combination is unusual. A retrieval system that only ever adds has a context window that fills with stale material; one that deletes has an audit problem. Suppression with approval and reversibility gives an operator a lever without an irreversible act, which is a sensible design for memory that a company might need to show it holds.

The trade is complexity. The planner is part of the runtime, the ranking is multi-factor, and the interaction between reinforcement and decay has to be right for the numbers to mean anything. The project also provides a tool call cache, which reuses the results of repeated calls to tools that are safe to reuse, and a deduplication step for retrieved memories, both of which reduce the number of records that reach the planner in the first place.

Four ways in: SDK, CLI, local UI and MCP server

MemoRizz exposes the same functionality through four interfaces, and the README names them: the Python SDK, an interactive CLI, a local web UI, and the option of exposing Memorizz as an MCP server. There is a local dashboard at memorizz ui, and the screenshot caption lists what it shows, which is a sensible set of operational metrics: runs, success rate, run time, model calls, tokens and spend across every agent, a runs-over-time chart, and what needs attention.

Tools are the other side of the interface. The framework accepts Python functions, MCP servers, internet search, governed browser control, desktop control of Mac applications in a computer-use style, sandboxes and external skills. MCP tools are stored in toolbox memory and found by meaning, which is how a tool becomes discoverable to an agent rather than merely registered.

Coordination is supported as well: delegating work to specialist agents, sharing memory between them, and running scheduled automations. The Shared memory type exists to carry a handoff between agents, which is the part that makes multi-agent setups more than several independent sessions.

On the CLI side, the environment template shows how configuration is meant to work. The commands are memorizz config set KEY [VALUE], with a --project flag to edit the project file, memorizz memory configure for the guided memory setup, and memorizz notion connect. The precedence rules are stated explicitly: process exports beat a project .env, which beats ~/.memorizz/.env, and the template warns that even an empty project assignment shadows a saved value.

MetaHarness and the plugin for Codex and Claude Code

The harness layer is the part that makes MemoRizz more than a library. MetaHarness runs tasks through Codex, Claude Code, OpenHands, DeepSeek, pi, Hermes or native MemAgent workers, and a MemAgent can hand parts of a request to delegates running on those harnesses. It carries memory scope and learning evidence across harnesses, and it manages permissions, approvals, workspace isolation, budgets, cancellation and host-side verification.

That list of managed concerns is the substance. A system that dispatches work to several different agent runtimes has to answer who may do what, what a task may spend, where it may write and how to check the result, and the README states that MetaHarness handles all of it.

The inspection command is memorizz harness doctor, which lists the adapters installed on the machine, and the dashboard has a Harnesses page for launching a task on one harness, chaining harnesses into a plan, or comparing them side by side.

There is a second integration, as a plugin for Codex and Claude Code:

memorizz plugin install codex          # or: memorizz plugin install claude-code

The alternative route is to add the marketplace and install the package:

codex plugin marketplace add RichmondAlake/memorizz
claude plugin marketplace add RichmondAlake/memorizz

The plugin behaviour is described concretely. The agent starts each session with the project's facts and the previous session's summary, each turn and a summary of each session are saved as episodic memory, and the agent can search past sessions, save and correct facts, record entities and load project documents. Both agents share the memory, locally or on a hosted MemoRizz MCP server for a team, and each session appears on the UI with its full trajectory.

Installing, linting and the packaging details

The package builds with hatchling, requires Python 3.10 or newer, and is installable as an ordinary library. The Makefile shows the development flow, and the install target is the one to note:

pip install -e ".[dev]"

The following lines install pre-commit, black, flake8 and isort and then run pre-commit install, so the hooks are active before the first commit. The lint target is worth reading because it encodes the project's own priorities: a syntax check over src/memorizz, then flake8 with the E9 and F selectors, described in the output as Python errors being enforced while style is advisory, and a second flake8 pass with a 120 character line limit that ignores E203 and E501 and is allowed to fail.

The format target runs black and then isort with the black profile, the check target runs pre-commit over all files, and the test target is a plain pytest run over the tests directory. The documentation targets use mkdocs, with the build target running mkdocs build --strict, so a broken link fails the build rather than shipping.

The rest of the tree supports the packaging story. There is a deploy/ directory with a hosted MCP server for teams, a plugins/ directory, an eval/ directory for the shadow evaluation and review of skills, packaging/ for the distribution files, a pytest.ini, an install.sh, a NOTICE file and a CLA.md for contributions.

The licence is the deciding factor, and the project is pre-1.0

The licence in the packaging metadata is PolyForm-Noncommercial-1.0.0, and the classifier says it plainly as an Other/Proprietary License. The hosting platform cannot classify it further, which is why the repository shows a custom licence rather than one of the usual open source identifiers.

That matters more than the code for most adopters. A noncommercial licence is a different kind of permission from MIT or Apache: it grants use without the rights to use in a commercial context, and a company shipping a product built on MemoRizz has to settle that question before anything else. This is not legal advice, and the point is only that the licence file is the document to read and the metadata is unambiguous about which one applies.

The other adoption consideration is maturity. The version is 0.17.3 and the three latest releases were all published on 2026-10-18, so the project moves fast and has not yet reached 1.0, which in practice means interfaces can change between minor versions. The breadth compounds that risk: memory types, five storage providers, four interfaces, seven harnesses, browser control, sandboxes and a continual learning loop are a lot of surface area for a 0.x library.

The counterweight is that the project is opinionated and documented. The docs/ tree has pages for each memory type, each provider, the forgetting mechanism, context efficiency, the model providers, the CLI, the Python SDK quickstart, desktop control and the MetaHarness guide, and the README points at all of them.

Editorial conclusion

Adopt MemoRizz if you are building agents in Python, need memory that survives across sessions and harnesses, and can work under the PolyForm Noncommercial terms. Do not adopt it for a commercial product without settling the licence question first, and do not adopt it if you want the memory to stay inside your own database with no framework in the loop. Before you start, read the .env.example file so the provider keys and the precedence rules are in place, then run memorizz harness doctor to see which external coding agents the machine can actually reach.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. RichmondAlake/memorizz on GitHub