Concepts
Hypergraph
Why HyperMemory stores knowledge as a hypergraph, and what that means for your agents
HyperMemory stores what your agents learn in a hypergraph: a graph in which one relationship can join any number of things, not only two. This page explains the idea, why it suits AI memory, and how it maps onto the objects you work with.
Graphs you already know
In an ordinary graph, every edge joins exactly two nodes.
Alice ──leads──► Project Alpha
│
└──works with──► BobThat is enough for simple facts. Real knowledge is rarely that tidy.
What a hypergraph adds
In a hypergraph, one relationship — a hyperedge — can join two or more nodes at once (HyperMemory allows up to 256).
┌──────────────────── Sprint 12 planning ────────────────────┐
│ │
│ Alice ──── Project Alpha ──── Bob ──── Release 2.4 │
│ │
└────────────────────────────────────────────────────────────┘That single hyperedge says that Alice, Bob, Project Alpha and Release 2.4 were all part of Sprint 12 planning. With plain edges you would need several separate links and would lose the fact that they belong to one event.
Why it matters for AI memory
Most things worth remembering involve more than two parties:
- Decisions involve people, the options they weighed, and the outcome.
- Meetings and events connect participants, topics, places and dates.
- Projects span teams, milestones, tools and dependencies.
- Incidents and releases tie together the fix, the bug, the deploy and the people involved.
Example: remembering a decision
With binary edges only
decision ──involves──► Sarah
decision ──involves──► Marcus
decision ──concerns──► API v2
decision ──made at──► Q3 planning
decision ──outcome──► approvedFive edges, and the agent has to walk all of them to rebuild the context.
With a hyperedge
[ Sarah, Marcus, API v2, Q3 planning, decision ]
↑
"Q3 planning approved API v2"One relationship that keeps the whole context together and can be recalled as a unit.
HyperMemory’s data model
| Object | What it is |
|---|---|
| Node | One thing worth remembering: a person, decision, fact, preference, project, document… Each has a key, a description, optional structured data and a node_type. See Nodes. |
| Edge | A directed relationship between two nodes, worded in plain language (for example “checkout service uses Redis for session caching”). See Edges & hyperedges. |
| Hyperedge | One fact over 2–256 nodes, with optional roles for each participant. |
| Ontology | The managed catalogue of node types and relationship types. Every node is filed under one canonical type; HyperMemory classifies it for you when you don’t name one. |
| Memory graph | An isolated knowledge base holding all of the above. Every account has at least one; organizations have their own. See Memory graphs. |
When to use an edge or a hyperedge
| Situation | Use |
|---|---|
| A simple fact between two things (A uses B, A reports to B) | Edge |
| A sequence (A was replaced by B) | Edge |
| A meeting, decision or event with several participants | Hyperedge |
| One piece of work made of five or more nodes (a feature, release, incident or investigation) | Hyperedge naming what they jointly are |
You rarely have to decide by hand. When an agent stores a node, HyperMemory’s background enrichment detects the entities it mentions and links them. The HyperMemory plugins also teach agents to add a hyperedge when several nodes make up one piece of work.