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 converted into a numerical representation (an embedding) so that meaning, rather than exact wording, can be searched.

Embeddings are produced by a specialist provider, which receives the meeting text solely to return those vectors and is contractually prohibited from training on it. Every provider that handles meeting content is named in the Privacy Policy.

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 -- your question is converted into a vector by the same embedding model used for your meetings.
2. Find the starting points -- the entities most related to your question, scoped to your partition.
3. Walk the graph -- from those entities, MemorDesk follows relationships outward to find connected people, projects and decisions. This step does not use vectors at all: it traverses the graph directly, which is what lets Kojo connect facts that were never said in the same meeting.
4. Pull the evidence -- the transcript passages that support what the walk surfaced.

The result is a structured context block given to the assistant, so answers are grounded in your meetings rather than generated from general knowledge.

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

Your partition is created automatically when you sign up. Nothing needs configuring, and one workspace's volume does not slow another's searches.