GraphRAG Memory Engine

MemorDesk does not store meeting transcripts as flat text. Every meeting is processed into a knowledge graph that connects people, projects, decisions, and blockers across time. When you ask Kojo a question, the answer is assembled from this graph -- not from a keyword search.

How it works end-to-end

1. Semantic chunking

After each transcript is cleaned, a semantic chunking module splits it into coherent paragraphs. Each paragraph is then embedded by MemorDesk's locally-hosted embedding model, producing a high-dimensional cosine-normalized vector. The model runs entirely on MemorDesk's servers and is never sent to a third-party embedding API.

Desktop: Settings > Knowledge (/dashboard/settings/knowledge) -- controls which meetings are indexed.

Mobile: Settings (gear) > Knowledge Base -- same controls on the native screen.

2. Vector search with partition isolation

Chunk and entity vectors are stored in a dedicated vector index. Every search is pinned to either your personal account or your organization's team space. There is no cross-user scanning: partition isolation is structural, enforced at query time by mandatory filter predicates. One user's embeddings are physically unreachable by another user's query, regardless of application-layer bugs.

Search scopes:

3. Entity extraction

MemorDesk extracts six entity types from each meeting:

Each entity is committed to the knowledge graph with full provenance back to the source meetings.

4. Bi-temporal relationship tracking

Every edge in the graph carries start and end timestamps. When a relationship changes (e.g. a decision is reversed, a person changes role), the old edge is closed and a new edge is opened. The graph is a full historical record, not a snapshot.

This means Kojo can answer questions anchored to a point in time: "What did we decide about the API contract three weeks ago?" returns the state of the graph at that date, not the current state.

5. Graph walk and retrieval

When you ask Kojo a question, retrieval runs in four steps:

1. Embed the query -- the same local embedding model converts your question into a vector.
2. Seed entity search -- top-5 entity matches by cosine similarity, scoped to your partition.
3. Graph walk -- a graph traversal engine performs a breadth-first traversal up to 3 hops from each seed entity. This step is vector-free: it traverses the relationship graph directly.
4. Chunk retrieval -- top-12 transcript chunks filtered to the meeting IDs the graph walk surfaced, retrieved by vector similarity.

The result is a structured context block injected into the LLM prompt.

6. User context summary

Each user has a working memory layer maintained by the memory engine:

• Active projects -- current initiatives you are involved in
• Key people -- frequent collaborators
• Open blockers -- unresolved risks from recent meetings
• Recent decisions -- decisions made in the last knowledge window
• Context summary -- a free-text summary injected into every Kojo prompt

This is the layer that makes Kojo feel context-aware even at the start of a new conversation.

7. Memory window and plan gating

Desktop: Settings > Knowledge (/dashboard/settings/knowledge) -- shows your current window and indexed meeting count.

Mobile: Settings (gear) > Knowledge Base.

Provision and scaling

Dedicated partitions are provisioned automatically at signup. New partitions require no manual intervention and add no overhead to other users' queries.