Tell it once. Every agent remembers.
A shared memory graph that lives in your own database. Any MCP agent writes to it and any other reads it back: a coding assistant, a support bot, an ops agent, something you built in house. Every fact carries who wrote it and when, and the write path never calls a model.
$149 a month hosted, and we run the database. Or pipx install echo-mem and run the whole thing on your own machine, source available and free to evaluate at any size.
{
"entities": [
{ "name": "Razorpay", "type": "vendor" },
{ "name": "billing", "type": "module" }
],
"facts": [{
"source": "billing", "target": "Razorpay",
"relation_type": "uses",
"fact": "billing takes payments through"
"Razorpay, not Stripe"
}]
}
# → edge 1125899906844301, no model invokedVector search degrades with history. Structure doesn't.
Most memory tools store flat rows and search them by similarity. More history means more candidates, more noise, slower retrieval. A fact here is an edge between two entities, so what you get back is bounded by what is connected to the question.
Entities are nodes. A fact is an edge.
That is the whole model, and everything else follows from it. Two sessions that never knew about each other resolve onto the same entity by name, so the second one inherits what the first learned.
No model call to record
Extraction happens in the calling agent, never on the server. Storing a memory invokes nothing and costs nothing to run. The trade is real and stated: the agent has to arrive with entities and facts already extracted.
Every fact knows its author
Who wrote it, which tool, which project, when, and which reads returned it. A superseded fact is never deleted; it stops being drawn and stays reachable with its full history.
Two sessions, the same thing
A name resolves to the node it already means, enforced by the database: one node per name per scope. So a session that never met the one before it inherits what that one learned, instead of starting a second entity beside it.
No new database to run
Vector similarity and graph traversal in one database you probably already run, rather than a second system to operate and back up.
Six tools, one graph
A coding assistant, a chatbot, an ops agent or something built in house. they all speak the same protocol and share the same memory.
Any agent that has to remember.
A fact is an edge between two entities. Nothing in that is about code. The entities can be customers, incidents or invoices. What follows is which parts have evidence behind them and which follow from the model.
Coding agents
Claude Code, Cursor and Codex on one machine, losing everything between sessions and knowing nothing of each other. Every measurement on this page comes from three of them sharing one graph.
Product agents
A support bot that should remember what this customer was told last week. A sales agent that should remember which objection was answered. They forget between conversations exactly the way a coding agent forgets between sessions.
Internal and ops agents
The agent that runs a deploy, triages an alert, or answers questions about a runbook, and should remember why a step exists rather than rediscovering it. Entities can be incidents and services as easily as modules.
Memory is a graph, not a list of notes.
Entities are nodes; a fact is an edge between two of them. That's the whole data model, and everything below follows from it. These are real captures from echo-memory dashboard --serve, run against a synthetic seed.
Three projects, never told about each other
Six services recorded in separate sessions by four different agents. The picture already separates them, because separation is a property of the edges, not a label anyone applied, and the few nodes sitting between clusters are the concepts more than one service turned out to care about.
Everything it takes part in
idempotency keys is the largest node here, and nobody made it large: seventeen facts from several services resolved onto one entity by name. The panel lists every one, with which agent wrote it and when.
Why memory believes it
This is what a knowledge graph gives you that a code map can't. The panel is not a tooltip: it is who wrote the fact, in which project, when, and how each of its entities resolved. A superseded fact is never deleted: it stops being drawn and stays reachable with its full history. echo-memory why <fact_id> prints the same trail in a terminal.
Click a node. Click a link.
A small illustrative patch bay, shaped like the real dashboard above. Relation types are set by the agent's read of the conversation, not inferred statistically. honest about what's tractable today.
Click a jack to see what it connects to, or a cable to see its full provenance: the same trail
echo-memory why <fact_id> prints in a terminal.Wire it into the tool you already use.
Any MCP client works. These four are just the ones most asked for. One database per machine, then one command per client. Every agent you connect writes to the same graph, and each announces itself, so you can tell afterwards which tool learned what.
Claude Code
Registers the MCP server and installs the skill that tells the agent when to record and when to recall. The skill is the half that matters: tools being available is not the same as knowing to call them.
- Install the package and start a database with
quickstart. - Run
install --for claudein the repo you want it scoped to, or add--globalfor every project on the machine. - Restart Claude Code. An MCP server holds the code it started with.
# one database, shared by every agent on this machine
pipx install echo-mem
echo-memory quickstart
# wire it into this project
echo-memory install --for claude
# or once, for every project
echo-memory install --for claude --global
One storage engine, every scale.
Postgres, from a single local agent up to an org wide shared graph. The novel work is the memory structure and the read/write algorithm on top of it, not a new database engine.
- 1storage
- 2retrieval
- 3interface
PostgreSQL + pgvector + Apache AGE
Vector similarity and graph traversal in one database. No forced migration later as the graph grows from one agent to an organisation.
Hybrid now, multi hop next
Vector and full text search, fused by reciprocal rank. Personalised PageRank over the graph lands in v1b for associative retrieval across hops.
Model Context Protocol
Any MCP compatible agent reads and writes the same graph: a coding assistant, a chatbot, an ops agent, or something built in house.
write_episodequery_memoryget_audit_logNumbers, and how they were taken.
Every figure comes from the repository or a live store, on a date. The corpus is small and the noise floor is stated, because a difference nobody sized is not a result.
The baseline is not “no memory”. That cost is however long you spend re-explaining, which nobody can measure. It is what people do instead: keep the project’s notes in one file and paste the file. On this store that file is 325 facts, about 41,838 tokens. A recall returned 1,372 on average across 1,190 questions in four query shapes, and the answer was still in what came back 87.2% of the time. Both halves matter: a recall that returned nothing would score 100%. The percentage rises as a store grows, because what a query returns is capped and a file is not.
768 cases across three one hop query shapes and 187 multi hop ones, each configuration scored against the same cases and compared on a seeded paired bootstrap. It has overruled three of its author's own bets, one already shipped. What it cannot do is measure quality: every query is derived from its own answer, and the harness says so in its own output.
The strongest mechanism here refuses to let a session end and hands back the unwritten list. It fired eight times and produced one fact; one session it held open had made 118 edits. Structural triggering is reliable. Structural capture is not, because the last step still hands a model a choice.
Three coding agents share one graph here. A recall across tools reads the writer off the fact's own edge and the reader off the presented key, so the agent being graded cannot type its own evidence, and since 2026-09-13 the server refuses a fact no read ever returned.
And the ones that went the other way
Entity resolution leans on similarity between entity names. Calibrated against 155 pairs a human confirmed distinct and 11 confirmed identical, that similarity scores AUC 0.666, 95% CI [0.421, 0.881], an interval that includes chance. So the unattended merge was switched off: at the automatic bar, precision was 50% over two reviewed pairs, and the audit log showed that path had fired once in the system's entire history. A near match is now offered for confirmation instead.
echo-memory calibrate recomputes it on your own store, and echo-memory eval --context recomputes the context saving on yours, including the hit rate, which is the half that stops the saving from being gamed.
Early and staged, on purpose.
The validated wedge driving v1a is memory shared across coding agents, the author's own daily pain, real and tested. Everything else is the target this architecture is built toward.
- v1a Built
Basic recall
Six MCP tools and thirty
echo-memorycommands, on PyPI and in the official MCP registry. Writing, recall, the audit trail, the ingestion queue, andrecord_recall_save, which now refuses a fact no read ever returned. - v1b Gated
Causal typing and multi hop
Retrieval that walks the graph rather than only ranking facts in it. Not shipped, but no longer unmeasured: 187 questions that no single fact answers score MRR 0.212 today, and a one hop expansion improves what is reachable while costing what is read first. The number it has to beat exists before the feature does.
- v1.1 Planned
Org wide tenancy
The scoping model the broader vision depends on: per agent, per team, or organisation wide graphs. It is also what the Enterprise tier is made of.
Nothing is deleted.
Everything explains itself.
The engine is source available under the Business Source License and the whole of it is on GitHub: the graph, the retrieval, the entity resolution, the audit log, the dashboard. Not a demo of a product that lives somewhere else.
The self hosted edition is not a trial and will never be crippled to sell the hosted one. What you pay for is not having to run the database.
- ✓Your data stays in your database. Self hosted, nothing leaves the machine. There is no phone home and no telemetry to switch off.
- ✓Every feature ships open first. The hosted plan runs the same published package, 1,500,000 units a month of it, on infrastructure somebody else patches.
- ✓You can leave. It is a standard database either way; the hosted store exports to the same schema the open one reads.
- ✕What is not open: the metering, billing and tenancy that only exist because someone is being invoiced. None of it is in the read or write path.
Open at the core. Paid to run it.
Self hosting is free to evaluate at any size, and free in production for organisations under 50 people and under $5M revenue. What the Cloud plan sells is not having to run the database yourself, and it is paid from the first key.
Your machine, your database, your data. Nothing metered, nothing to cancel, no account.
- Unlimited facts, episodes and projects
- The full engine: graph, retrieval, entity resolution, audit log
- MCP server, CLI, dashboard, session hooks
- Every client: Claude Code, Cursor, Codex, any MCP tool
- Nothing leaves the machine, and there is no telemetry
The same engine with the database run for you, reachable from every machine you work on.
- 1,500,000 units a month
- A managed database, run and backed up for you
- Hosted MCP endpoint, no local install
- One memory across every machine you work on
- Backups, and a dashboard at a URL
Anything past the Cloud plan: a higher ceiling or none at all, more than one person on one memory, and the questions that come with both.
- Volume above 1,500,000 units, or uncapped and invoiced
- Org, team and per agent scoping
- SSO and SCIM, role based access per scope
- Secret and PII redaction before write
- Audit log export and retention policy
| Feature | Self hosted | Cloud | Enterprise |
|---|---|---|---|
| Allowance | |||
| Units per month | Unlimited | 1,500,000 | Uncapped |
| What a unit is | n/a, nothing is metered | One fact written, or one fact returned | Negotiated |
| At the limit | n/a | Writes pause, or move to Enterprise | Invoiced, never paused |
| Projects and scopes | Unlimited | Unlimited | Unlimited |
| Running it | |||
| Who runs the database | You | We do | Either |
| Local install required | Yes | No | Optional |
| Backups | Yours to take | Daily | Custom |
| Data location | Your machine | ap-south-1 | Negotiated |
| The engine | |||
| Graph, retrieval, entity resolution | Included | Included | Included |
| Audit log and provenance | Included | Included | Included, with export |
| Recall across tools | Included | Included | Included |
| Licence | BSL 1.1 | BSL 1.1 engine | Negotiated |
| Organisation | |||
| Team and org scoping | no | no | Included |
| SSO and SCIM | no | no | Included |
| PII redaction before write | no | no | Included |
| Support | GitHub issues | Named contact | |
The ones worth asking first.
The Cloud plan is 1,500,000 units a month, which is only meaningful if you know what a unit is, so that is the first answer.
What exactly is a unit?
One fact written, or one fact returned. write_episode charges the edges it created, query_memory charges the facts it handed back, and record_recall_save and get_audit_log charge one each. So the ceiling measures memory actually moved, not requests made. A query that matches nothing costs nothing.
What happens when I hit the limit?
Writes pause until the month rolls over; reads keep working, and nothing is deleted. You are never billed for going over without asking, and there is no automatic overage on the Cloud plan. If you need more, write to us and it becomes an Enterprise conversation.
Can I self host for free?
Yes, with no feature held back and with no account. The self hosted edition is the same engine the Cloud plan runs, and it is the only free way to use Echo Memory: there is no free hosted allowance, because hosting is the thing the Cloud plan charges for.
Is the open edition crippled to sell the paid one?
No, and the source is the check on that claim: the graph, retrieval, entity resolution, audit log and dashboard are all in the repository. What is closed is metering, billing and tenancy, machinery that only exists because someone is being invoiced, and none of which sits in the read or write path.
Is this only for coding agents?
No. It is an MCP server over a graph database, so anything that speaks the protocol can read and write it: a support bot that should remember what a customer was told last week, an ops agent that should remember why a runbook step exists, an internal tool, a chatbot, something you wrote yourself.
Coding agents are where it is proven, not what it is limited to. That is the honest distinction: the measurements on this page come from three coding agents sharing one graph, because that is the author's own daily pain and the case with the most evidence behind it. The data model has nothing to do with code a fact is an edge between two entities, and the entities can be customers, incidents or invoices as easily as modules.
Does the server call an LLM when I write?
No. Extraction happens in the calling agent, so storing a memory invokes no model here. This is worth stating precisely: the cost moved rather than vanished. The agent has to arrive with entities and facts already extracted, and what this server does is store, connect and return them.
How do I get my data out?
It is a standard database either way. The hosted store exports to the same schema the open edition reads, so moving from the hosted plan to your own machine is a restore, not a migration. There is no proprietary format to be trapped in.
How new is this?
New. Version 0.3.0, published to PyPI and the MCP registry, with the across tools recall path working end to end and measured. The status section says which parts are shipped and which are still gated, and the measurements include the ones that went the wrong way.
Can several people share one memory?
Not yet on the Cloud plan, which is one account, as many machines and agents as you like. Org, team and per agent scoping is the Enterprise tier and the next planned release.
Which package is which.
One name is taken by somebody else and two are held for later, which is exactly the kind of thing that wastes an afternoon. The quickstart above has the commands; this is the reference.
echo-mem 0.3.0the implementationecho-memlisted: the package and the hosted endpointecho-memname held for a future JS clientNot `echo-memory`. That name belongs to an unrelated hosted product on PyPI, published March 2026. pip install echo-memory installs theirs, not this. The import package here is still echo_memory; only the distribution name differs.
echo-memory status reports what each scope holds and which agents have written to it. If only one agent is listed, memory is not yet shared and it will tell you so.