Alternatives

mem-port vs mem0 vs Hermes Agent

Three open source projects people compare when they go looking for AI memory. They aren't the same shape: mem0 is a universal memory layer with a hosted option, Hermes Agent is a full self-improving agent that keeps its own agent memory, and mem-port is a local memory server that existing copilots share.

Feature comparison for AI memory: mem-port, mem0, Hermes Agent
Criterion	mem-portLocal MCP memory server	mem0Universal memory layer	Hermes AgentSelf-improving agent CLI
What it is	An AI memory server. One local daemon holding a shared knowledge graph; it never calls a model itself.	An AI memory layer: SDK, self-hosted Docker server, and a managed cloud platform.	A full autonomous agent from Nous Research, with agent memory built in rather than offered separately.
External infrastructure	None. One process, one embedded SurrealDB store on local disk.	Library mode runs a local Qdrant; the self-hosted server is a Docker stack with Postgres/pgvector, plus a graph store for relations.	None for its own store — SQLite on disk.
API key required	No. Embeddings run on a local ONNX model, so semantic search works offline.	Yes by default — an LLM (OpenAI by default) extracts facts, though every component is overridable.	Yes. It's an agent, so it needs a model provider to run at all.
Storage engine	Embedded SurrealDB (surrealkv://) — graph relations and vector search in the same process.	A vector store (Qdrant, pgvector and ~20 others), optionally paired with a separate graph store.	SQLite with FTS5, plus agent-curated facts in a MEMORY.md file.
Retrieval	Semantic vector search over memories and skills, plus graph lookups by entity.	Vector similarity search over LLM-extracted facts.	Full-text search across past sessions, with session lineage preserved.
Shared across copilots	Yes, natively. Any MCP client sending the same library-id header reads and writes one graph.	Yes, via the separate OpenMemory MCP server (Docker: API, Postgres, Qdrant).	hermes mcp serve exposes Hermes to MCP clients; the memory stays Hermes-owned.
Portability	Namesake feature: export_library and import_library move a whole library as one .memport.json bundle.	Tied to whichever vector and graph stores you deployed, or to the hosted platform.	Copy the SQLite file; trajectory export targets training data rather than memory hand-off.
Reusable skills	First-class: save_skill and search_skills, shared by every connected copilot.	Memories only — no separate skill primitive.	Yes — Hermes writes and improves its own skills, for Hermes.
License	MIT	Apache-2.0	Open source (Nous Research)

What it is

mem-port: An AI memory server. One local daemon holding a shared knowledge graph; it never calls a model itself.
mem0: An AI memory layer: SDK, self-hosted Docker server, and a managed cloud platform.
Hermes Agent: A full autonomous agent from Nous Research, with agent memory built in rather than offered separately.

External infrastructure

mem-port: None. One process, one embedded SurrealDB store on local disk.
mem0: Library mode runs a local Qdrant; the self-hosted server is a Docker stack with Postgres/pgvector, plus a graph store for relations.
Hermes Agent: None for its own store — SQLite on disk.

API key required

mem-port: No. Embeddings run on a local ONNX model, so semantic search works offline.
mem0: Yes by default — an LLM (OpenAI by default) extracts facts, though every component is overridable.
Hermes Agent: Yes. It's an agent, so it needs a model provider to run at all.

Storage engine

mem-port: Embedded SurrealDB (surrealkv://) — graph relations and vector search in the same process.
mem0: A vector store (Qdrant, pgvector and ~20 others), optionally paired with a separate graph store.
Hermes Agent: SQLite with FTS5, plus agent-curated facts in a MEMORY.md file.

Retrieval

mem-port: Semantic vector search over memories and skills, plus graph lookups by entity.
mem0: Vector similarity search over LLM-extracted facts.
Hermes Agent: Full-text search across past sessions, with session lineage preserved.

Shared across copilots

mem-port: Yes, natively. Any MCP client sending the same library-id header reads and writes one graph.
mem0: Yes, via the separate OpenMemory MCP server (Docker: API, Postgres, Qdrant).
Hermes Agent: hermes mcp serve exposes Hermes to MCP clients; the memory stays Hermes-owned.

Portability

mem-port: Namesake feature: export_library and import_library move a whole library as one .memport.json bundle.
mem0: Tied to whichever vector and graph stores you deployed, or to the hosted platform.
Hermes Agent: Copy the SQLite file; trajectory export targets training data rather than memory hand-off.

Reusable skills

mem-port: First-class: save_skill and search_skills, shared by every connected copilot.
mem0: Memories only — no separate skill primitive.
Hermes Agent: Yes — Hermes writes and improves its own skills, for Hermes.

License

mem-port: MIT
mem0: Apache-2.0
Hermes Agent: Open source (Nous Research)

Sourced from each project's public documentation in August 2026 — check each agent memory GitHub repo for current details. All three are open source and worth reading; pick the one whose shape matches your problem, not the longest column.

The status quo

mem-port vs AGENTS.md

Most projects already hold their agent context in a markdown file — AGENTS.md, CLAUDE.md, .cursorrules. It's the right tool for standing rules, and mem-port doesn't replace it. The difference isn't who writes it; agents generate and update these files routinely. It's that a file is one document, edited whole and loaded in full every session, while mem-port is a store that takes one record at a time and returns only the ones a question needs.

Feature comparison for AI memory: mem-port, AGENTS.md
Criterion	mem-portQueried knowledge graph	AGENTS.mdMarkdown file in the repo
What it is	A local daemon holding a knowledge graph, exposed to agents as MCP tools they call while they work.	A file checked into the repo, loaded into the model's context at the start of a session.
How it's written	One record at a time. save_memory, save_episode, save_skill and save_adr are ordinary tool calls mid-task, and several copilots can write at once — they're talking to one daemon, not editing one file.	Whole-file edits. Agents write these files too, but adding one fact means rewriting the document, and two agents doing it at the same time overwrite each other.
How it's read	On demand. Semantic search returns the records relevant to the question actually being asked.	All of it, every session. Nothing is selected, so context cost scales with the file's length.
As it grows	Keeps growing. Retrieval stays scoped no matter how large the library gets.	Hits a ceiling. Past a point it's too long to prepend to every prompt, so it gets trimmed back rather than kept.
Structure	Five record types — memories, episodes, entities, skills, ADRs — each answering a different retrieval question.	Free-form prose. A house rule, a past incident, and a design decision all look the same on the page.
History	ADRs carry a lifecycle (proposed → accepted → superseded/deprecated) and a supersede chain; episodes record what happened.	Git history, if it's committed. The file itself only shows what's true right now.
Scope	A library-id, not a directory. One library can span repos and machines; separate library-ids stay fully isolated.	The directory tree, plus a user-global file in some tools. Nothing crosses machines except through git.
Across copilots	One graph. Any MCP client sending the same library-id reads and writes it — nothing to duplicate.	AGENTS.md is converging into a shared standard, but tools still read their own files as well, and every repo keeps its own copy to update.
Review	No pull request gate — records land as agents write them. You prune with forget_memory, forget_skill, forget_adr.	Reviewable in a pull request like any other file, and that's a real advantage for rules the whole team is bound by.
Setup	One command, npx @rsl-innovation/mem-port serve, plus a connect command per copilot. Node >= 22.	None. Create the file and commit it.

What it is

mem-port: A local daemon holding a knowledge graph, exposed to agents as MCP tools they call while they work.
AGENTS.md: A file checked into the repo, loaded into the model's context at the start of a session.

How it's written

mem-port: One record at a time. save_memory, save_episode, save_skill and save_adr are ordinary tool calls mid-task, and several copilots can write at once — they're talking to one daemon, not editing one file.
AGENTS.md: Whole-file edits. Agents write these files too, but adding one fact means rewriting the document, and two agents doing it at the same time overwrite each other.

How it's read

mem-port: On demand. Semantic search returns the records relevant to the question actually being asked.
AGENTS.md: All of it, every session. Nothing is selected, so context cost scales with the file's length.

As it grows

mem-port: Keeps growing. Retrieval stays scoped no matter how large the library gets.
AGENTS.md: Hits a ceiling. Past a point it's too long to prepend to every prompt, so it gets trimmed back rather than kept.

Structure

mem-port: Five record types — memories, episodes, entities, skills, ADRs — each answering a different retrieval question.
AGENTS.md: Free-form prose. A house rule, a past incident, and a design decision all look the same on the page.

History

mem-port: ADRs carry a lifecycle (proposed → accepted → superseded/deprecated) and a supersede chain; episodes record what happened.
AGENTS.md: Git history, if it's committed. The file itself only shows what's true right now.

Scope

mem-port: A library-id, not a directory. One library can span repos and machines; separate library-ids stay fully isolated.
AGENTS.md: The directory tree, plus a user-global file in some tools. Nothing crosses machines except through git.

Across copilots

mem-port: One graph. Any MCP client sending the same library-id reads and writes it — nothing to duplicate.
AGENTS.md: AGENTS.md is converging into a shared standard, but tools still read their own files as well, and every repo keeps its own copy to update.

Review

mem-port: No pull request gate — records land as agents write them. You prune with forget_memory, forget_skill, forget_adr.
AGENTS.md: Reviewable in a pull request like any other file, and that's a real advantage for rules the whole team is bound by.

Setup

mem-port: One command, npx @rsl-innovation/mem-port serve, plus a connect command per copilot. Node >= 22.
AGENTS.md: None. Create the file and commit it.

AGENTS.md and mem-port answer different questions, and running both is the expected setup. Keep the markdown file for the standing rules a repo should enforce on every session — conventions, commands, things a reviewer should be able to see in a diff. Use mem-port for what accumulates while you work: decisions and their supersede chains, what happened last time, procedures worth reusing — the context that outgrows a single document, and shouldn't have to be re-explained to the next copilot.