Memanto: a sidecar memory agent for multi-agent fleets

The problem Memanto names: storage is solved, management is not

The README opens with a blunt claim: persistence is solved, because Claude, Bedrock, Cursor and vector stores will keep whatever your agents write. What none of them will do, it argues, is tell you that two agents now believe opposite things about your auth service, or that a March preference has quietly outranked last week's decision. Memanto's answer is to be a second agent rather than a library. It runs beside your fleet and decides what to keep, what conflicts, what expires and who needs to know. The target reader is someone running more than one agent, often across more than one framework, who has started to notice that each tool's memory is a silo. A single-agent project with one framework's built-in memory does not have the problem this addresses.

Six behaviours, each with a command behind it

The README lists six things Memanto does on its own judgment, and pairs each with a CLI invocation rather than a roadmap item. It observes interaction streams and extracts durable knowledge instead of archiving transcripts, via `memanto remember --from-conversation`. It consolidates extracted memories into one canonical estate, so duplicates collapse and repeated observations strengthen confidence rather than multiplying rows. It reconciles contradictions by superseding rather than appending, which is what keeps what is true now separate from what was believed then. It forgets on policy through `memanto forget`. It briefs an agent with the minimal relevant slice before that agent acts, through `memanto agent bootstrap`. And it moves knowledge between frameworks through the Open Knowledge Format. The design point worth noting is the query direction: the README says your agents do not query anything, they get briefed. That inverts the usual retrieval pattern, where the agent constructs a search. Whether briefing beats querying in practice depends on how well the extraction step captures what a given agent will later need, and the README does not quantify that.

Getting it running: pip, connect, schedule

Installation is `pip install memanto`. Running `memanto` with no arguments prompts for a deployment choice between on-prem (Docker, no account) and cloud (free key). Wiring an existing tool is one command: `memanto connect claude-code`, with cursor, codex, windsurf, cline, goose and copilot listed as alternatives. The README states this requires no code changes, no wrapper and no rewrite of your agent loop. From there the working loop is CLI calls. `memanto remember "Auth migrated to JWT - session cookies deprecated" --type decision` writes a memory. `memanto recall "how does auth work"` reads it back, and `memanto answer "why did we drop session cookies?"` returns a grounded answer without an extra API key. Two recall flags carry most of the interesting behaviour: `--as-of 2026-08-05` reconstructs what the fleet believed on a past date, and `--changed-since v2.1` shows what moved since a release. `memanto conflicts` surfaces contradictions, `memanto schedule enable` turns on the daily curation loop, `memanto ui` opens a local dashboard, and `memanto config backend` switches between on-prem and cloud. The README also notes macOS, Linux and Windows support.

OKF is the real architectural decision

The export path is where Memanto differs from most memory layers. `memanto memory export --okf` produces the Open Knowledge Format, which the README describes as plain Markdown that is readable, diffable, committable and greppable, as opposed to a proprietary dump you can technically request. `memanto migrate` imports from Mem0, Letta, Supermemory or any OKF bundle, and the README says the same command works in reverse. The stated intent is that OKF is an open interchange format any framework or vendor can implement, including competitors. That is a genuine architectural commitment, and it is also the thing to test hardest before committing: an interchange format is only as good as its round-trip fidelity. The README does not describe the OKF schema, how metadata, timestamps, confidence scores or supersession history are represented in Markdown, or what happens to fields OKF cannot express. If you plan to migrate an existing estate in, that gap matters more than any feature list.

Where the documentation stops short

The Security and sovereignty section is unfinished in the published README. It contains an HTML comment addressed to a maintainer asking them to fill in hardening specifics, stating that the structure is right but the specifics are theirs, and that anything unsubstantiated should be deleted rather than softened. The visible text claims that nothing leaves your machine in on-prem mode, that Docker plus Ollama involves no account and no outbound calls, and then the supplied text ends mid-sentence after "extraction, consolidation,". So the security model is asserted but not documented. For a component that sits between your agents and holds their accumulated knowledge, that is the largest open question in the repository. It is also worth reading the two claims side by side: the README says extraction and consolidation run locally in on-prem mode, and separately offers cloud as an option. Which parts of the six-behaviour loop run where, and what the cloud path transmits, is not spelled out in the material available.

A vector store solves a different problem

The natural comparison is a vector store such as pgvector, Chroma or a hosted equivalent. The difference is not quality, it is who decides. A vector store stores embeddings and returns nearest neighbours; every judgment about what to keep, what duplicates what, and which of two contradictory entries wins is left to your application code. Memanto's premise is that those judgments belong in a separate agent with policies attached, so that supersession and decay happen without you writing them. The cost of that premise is a component you did not write sitting in the path between your agents and their knowledge, with its own configuration, its own scheduled loop and its own failure modes. If your agents are few and their memory needs are narrow, a table with an embedding column and a timestamp gives you most of the retrieval value with none of the operational surface. Memanto earns its place when the number of agents and frameworks makes manual curation untenable.

Licence, maintenance and upgrade cost

The repository is MIT licensed, and the README makes a point of it: no open-core tier gating the useful half, no feature flags, no seat limits. On the evidence of the licence file alone, that removes the usual commercial risk of a memory layer changing terms under you. Maintenance cadence is visible in the release list: v0.2.19, v0.2.20 and v0.2.21 shipped within roughly nine days of each other in early September 2026, and the last push to the default branch is dated 2026-09-10. Three patch releases in nine days at a 0.2.x version number suggests active work and also a moving target. The README does not document an upgrade procedure, a migration path between Memanto versions, or whether the on-prem Docker image is versioned alongside the Python package. If you run the scheduled curation loop in production, pin the package version and check whether the Docker image and the pip package need to move together before you upgrade either. This is a description of what the repository shows, not legal advice on the licence.

Editorial conclusion

Adopt Memanto if you run several agents across more than one framework and you want one estate you can read, diff and commit, with on-prem Docker plus Ollama as the documented option for keeping data in house. Do not adopt it if you need a memory feature inside a single framework, or if you need the security model documented before you deploy: the README's Security and sovereignty section still carries an editor's note asking the maintainer to fill in hardening specifics, and the text ends mid-sentence after the on-prem claim. Verify first that `memanto migrate` handles your existing store's schema, that OKF round-trips your metadata without loss, and that the on-prem Docker image is the one you will actually run, since the README does not state image tags, resource requirements or upgrade steps.

Official sources

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