Memanto: a companion memory agent for AI agent fleets

The problem Memanto targets: storage without curation

Most agent memory today is persistence. A vector store keeps whatever your agent writes, and a platform-native memory feature keeps it inside that platform. The README makes the argument directly: every platform will store your agents' memory, and none of them will manage it, because managing it across platforms is against their interest. The failure it describes is not lost data. It is two agents believing opposite things about the same auth service, a March preference outranking a decision from last week, and a new agent redoing work another agent already finished and reverted. Memanto is aimed at teams running more than one agent, often across more than one framework (the topics list crewai and langchain, and the repository ships examples/crewai-memory/ and examples/langgraph-memanto/). If you run a single agent with a single session, there is nothing here for you to reconcile.

Six behaviours, each with a command behind it

Memanto is not a library you call from your agent loop. The README calls it a second agent that runs beside your fleet, and it lists six behaviours, each mapped to a CLI command. It observes interaction streams and extracts durable knowledge rather than archiving transcripts, via memanto remember --from-conversation. It consolidates extracted memories into one estate, where duplicates collapse and repeated observations strengthen confidence instead of multiplying rows, driven by memanto schedule enable. It reconciles contradictions by superseding rather than appending, so what is true now and what was believed then stay separate questions, exposed through memanto conflicts. It forgets through decay, expiry and deletion policies run by memanto forget. It briefs an agent with the minimal relevant slice before that agent acts, through memanto agent bootstrap, so agents do not query the estate themselves. And it moves knowledge across frameworks through the Open Knowledge Format with memanto memory export --okf. The README states that each of these is a real behaviour with a command behind it, not a roadmap item.

Installing Memanto and running a first real use

The README gives a one-line install from PyPI. The package requires Python 3.10 or newer and under 4, per pyproject.toml.

pip install memanto

After installing, running the bare command starts an interactive choice between an on-premises mode (Docker, no account) and a cloud mode (free key).

memanto

The next step connects an existing coding agent so it shares the estate. The README lists claude-code, cursor, codex, windsurf, cline, goose and copilot among the supported targets.

memanto connect claude-code

A first write and read pair shows the intended flow. One agent records a decision; a different agent that never saw that session can recall or ask about it later.

memanto remember "Auth migrated to JWT — session cookies deprecated" --type decision
memanto recall "how does auth work"
memanto answer  "why did we drop session cookies?"

The recall command accepts point-in-time and change queries, which is where the reconciliation model becomes visible. The README shows --as-of with a date and --changed-since with a release tag. A local dashboard over the whole estate is available through memanto ui, and the README states it runs on macOS, Linux and Windows.

memanto recall "deployment policy" --as-of 2026-08-05
memanto recall "deployment policy" --changed-since v2.1
memanto ui

For a container path, the repository ships a Dockerfile and docker-compose.yml. The compose file publishes port 8000, loads variables from a .env file, and health-checks http://localhost:8000/ready every 30 seconds. The .env.example file shows MOORCHEH_API_KEY as the one required value, pointing at https://app.moorcheh.ai, with a free tier described as 500 monthly credits, roughly 100,000 operations. Answer and session settings such as ANSWER_MODEL, ANSWER_LIMIT, ANSWER_THRESHOLD, RECALL_LIMIT and SESSION_DEFAULT_DURATION_HOURS are listed as optional with defaults. The Dockerfile installs dependencies with uv, runs the service as a non-root user with uid 1001, and exposes 8000. Note that the healthcheck deliberately hits /ready, which the Dockerfile comment says always returns 200 without calling the external Moorcheh API; /health is the endpoint that gates on Moorcheh connectivity.

Where the design creates real constraints

The most consequential constraint is the dependency on the Moorcheh SDK, pinned at moorcheh-sdk>=1.3.7 in pyproject.toml. The default cloud path needs MOORCHEH_API_KEY, and the free tier is metered in monthly credits. The README's answer to this is on-prem mode: local Docker plus Ollama, no account and no outbound calls, and memanto config backend switches between backends in one command. That is a credible escape hatch, but it means the fully private path is a container deployment, not a pip install, and the README does not document the resource requirements of running extraction and consolidation locally. A second limitation is documentation depth. The security and sovereignty section in the README is still a skeleton: it carries an unfinished editorial note asking a maintainer to fill in specifics from hardening work and to delete anything that cannot be substantiated. Until that section is written, treat the security claims as unverified. Third, the reconciliation model is retrospective. It preserves what was believed and when, which is useful, but it also means the estate accumulates superseded knowledge by design. The README asserts that managed forgetting keeps recall sharp at month twelve; that is a claim, not a measurement, and no benchmark result is published in the repository.

How Memanto differs from Mem0 and Letta

Memanto's own README names Mem0, Letta and Supermemory as sources it can import from with memanto migrate, and the same command is described as working in reverse. The difference in approach is where the intelligence sits. Mem0 and comparable libraries are memory layers your application calls: your code decides what to write and what to fetch. Memanto inverts that. It runs as a separate process with its own scheduling loop, decides what to keep, flags contradictions for review, and pushes a brief to an agent before that agent acts, so the agent does not query anything. That inversion is the whole product thesis, and it is also the cost: you operate a service rather than import a module. The second difference is the interchange format. Memanto exports its estate as OKF, described as plain Markdown that is readable, diffable, committable and greppable, and the README states OKF is an open format any framework or vendor can implement, including competitors. If portability of the memory estate is your deciding criterion, that is the concrete distinction to test: export an estate, read the files, and try importing them elsewhere.

Licence and the cost of staying current

Memanto is MIT licensed, and the README is explicit that there is no open-core tier, no feature flags and no seat limits. For a memory layer that sits next to proprietary agent code, that removes the licensing question entirely, though it says nothing about the licence terms of the Moorcheh service you may connect to. The repository is not archived, and the last push was on 2026-09-10, with releases v0.2.21 on 2026-09-09, v0.2.20 on 2026-09-04 and v0.2.19 on 2026-09-01. That cadence means upgrades arrive often, and the version is dynamic (dynamic = ["version"] in pyproject.toml), so pin your dependency rather than tracking latest. The Dockerfile bakes a VERSION build argument, defaulting to 0.1.1, which is well behind the published release line; override it at build time if the version stamp matters to you. There is no documented migration guide between minor versions in the repository, so the practical upgrade cost is re-running your own recall checks after each bump rather than following a changelog path.

Editorial conclusion

Adopt Memanto if you run several agents across frameworks and want one estate that reconciles contradictions, expires stale facts, and can be exported as plain Markdown. Do not adopt it if you need a memory layer that is fully self-contained in Python with no external service, since the default cloud path depends on a Moorcheh API key. Before committing, verify what the README leaves open: the exact storage format of an OKF bundle, the behaviour of memanto migrate in reverse, and the security section, which still carries unfinished placeholder notes in the repository.

Frequently asked questions

Official sources

1. License: MIT
2. moorcheh-ai/memanto on GitHub
3. Project website
4. README
5. Releases