MemMesh — persistent, self-improving memory for AI agents. Get started →
Core ConceptsKnowledge Graph

Knowledge Graph

Memories don’t sit in a flat list. As the engine learns, it wires them into a graph of entities connected by typed, weighted, bi-temporal edges. This is the substrate the lattice and prediction layer build on, and it’s what makes recall associative rather than purely lexical.

Entities and edges

An entity is a canonical node — a person, org, product, location, concept, event, or document. An edge is a typed relationship between two entities (or between an entity and a literal value): a snake_case predicate like purchased, prefers, works_at, located_in, has_condition.

Edges carry:

  • a weight — how strong the relationship is;
  • a validity window (validFrom / validTo) — so the graph is bi-temporal and can answer “what did we believe on date X”.

Entities and edges come from three sources:

  • Structural extraction (no LLM) — the primary path for structured sources. The engine builds entities and edges deterministically from a memory’s structured fields (e.g. an SEC filing → company —reports_metric→ concept), inheriting canonical identity from the source’s authoritative id (CIK, aliased by ticker). Idempotent and bi-temporal (validFrom = period end), it runs on the write path so a structured brain gets its graph for free — no tokens, no LLM. This is what makes a public-dataset brain cheap to build.
  • Agent-run LLM extraction for narrative text — the extract_pending → commit_extraction protocol (see Lifecycle); the engine never makes the model call, the client does.
  • Manual annotation through the admin routes.

Point-in-time queries

Because edges are bi-temporal, the graph supports time travel. A point-in-time query returns the edges valid at a chosen instant — reconstructing a past belief state rather than only the current one. The same principle applies to memory list and search via the asOf parameter.

See Knowledge Graph API.

Associative (anticipatory) recall

The graph turns recall into spreading activation. Starting from the memories a session is already using, the engine walks the graph to the memories that share the most entities and surfaces them — the context most likely needed next, before it’s asked for. It’s deterministic and read-only.

This is exposed directly as a prefetch endpoint, and — when the MEMORY_ASSOCIATIVE_RECALL_ENABLED flag is on — folded into ordinary search, where a ranked query seeds activation from its top hits and blends the graph-linked memories in with a bounded association bonus.

Reflection

Periodically, the engine can reflect: review a subject’s recent confirmed memories and synthesize higher-order insight memories — generalizations supported by several raw memories that none states outright. Insights are saved as first-class memories with provenance, so retrieval returns synthesized understanding, not just raw facts.

Consolidation

Left unchecked, a graph accumulates near-duplicates and stale nodes. Consolidation keeps it healthy — but cosine similarity alone is unsafe for structured data (distinct financial facts can sit at 0.96 because they share templated language), so collapsing on a flat threshold would corrupt the graph. The shipped model is therefore domain-aware and human-in-the-loop:

  • A flagging pass proposes near-duplicate pairs, each with a verdict: exact (safe to merge), numeric_template_diff (looks similar but the numbers differ — keep both), or review.
  • Pairs land in a consolidation review queue (the “Review Duplicates” admin page). Approving a pair supersedes the loser into the survivor and reinforces it; rejecting keeps both. Merges are never automatic for ambiguous pairs.
  • Decay / consolidation compacts the store over time.

Nothing destroys history: consolidation supersedes rather than deletes, so the audit trail and time-travel queries stay intact. The review + maintenance routes live under the Knowledge Graph API.

Cross-brain federation

A brain’s graph is isolated by default. When you hold access to several brains, the Mesh Router can reason across them at query time without merging their stores:

  • Entity linking — the same real-world entity in different brains (matched by normalized name/alias overlap, or hard keys like an email or @handle, same type only — deterministic, no LLM or embeddings) is treated as one node for the duration of the query. The overlay is ephemeral: nothing is written back, so each brain stays clean and independently owned.
  • Federated graph walk — the memory_graph tool resolves those cross-brain entities, walks each brain’s own neighbourhood (1–2 hops), and merges the facts with per-brain provenance so every claim still traces to its source brain.

This is how one MeshKey can answer a question that no single brain holds in full, while preserving isolation and provenance. See the hosted MCP endpoint for how to connect.