Memory Links
Tell Mem when two memories should be read together, with the relationship and reason saved in the graph.
A Memory Link is for one plain action: telling Mem that two memories should be read together.
Use it when one memory changes how another should be understood. A launch plan may depend on an earlier pricing assumption. A migration note may be the risk behind an implementation plan. A real example may be the missing context that makes a rule usable.
This is different from search similarity. Search can guess that two memories look related. A Memory Link is something you, or an agent working with clear intent, decided to keep.
Try it once
- Open Graph from the sidebar.
- Select a Memory node.
- Choose Connect memories.
- Select another Memory in the same Space.
- Type a short relation name, or use a suggestion.
- Add a reason if the connection is not obvious, then save.
The two memories must be in the same Space. That keeps work, projects, clients, and agent teams from being linked by accident.
How to know it worked
You should see a line between the two Memory nodes. Select that line to inspect the relation name and reason.
Later, when an agent or graph tool reads one of those memories, the link gives it a stronger clue than "these two texts are similar." It can bring the other memory nearby and know why it matters.
Good relation names
You do not need a perfect taxonomy. Start with the words you would use in your own work:
| Relation | Use it when |
|---|---|
supports | one memory is evidence for another |
contradicts | one memory conflicts with another, but is not a newer version |
depends_on | one memory needs another to make sense |
example_of | one memory is a concrete example of a rule or pattern |
blocks | one memory blocks a plan or action |
same_topic | both memories cover the same subject and are useful together |
You can also type your own names, such as migration_risk_for, pricing_assumption_for, or source_of_truth_for. Mem normalizes names, so same topic, same-topic, and same_topic are treated as the same relation.
How this differs from other links
| Use this | When you mean |
|---|---|
| Memory Link | These two specific memories should be read together for this reason |
| EVOLVES | This memory updates, replaces, enriches, confirms, or challenges an older version |
| Label | Many memories belong in the same broad group |
| Entity graph | A memory mentions people, projects, tools, concepts, or extracted entity relationships |
| Search | Find memories that look relevant, even when no relationship has been saved |
If the connection is really a newer version of old knowledge, use the EVOLVES relationship instead. If you only want a broad bucket, use a label.
What to ignore for now
You do not need to design a full relation system before using Memory Links. Name the relationship that is useful today.
You do not need to use AI suggestion. It can draft a relation name and reason, but it only fills the form. You still decide what to save.
You do not need to think about APIs or MCP tools unless you are building an integration. The Graph view is the normal starting point.
For agents and integrations
Supported integrations can read and write Memory Links through the REST API and MCP tools:
memory_relation_addmemory_relation_suggestmemory_relation_listmemory_relation_updatememory_relation_delete
The graph stores these as one stable memory-to-memory edge with an open relation name. That keeps the schema small while still letting your vocabulary grow over time.
Where to go next
- Knowledge Graph if you want to create or inspect Memory Links visually.
- Knowledge evolution if you want to understand version history and contradictions.