Enable Knowledge Graph Memory

Turn on per-project knowledge graph memory so agents build and recall an entity-relation graph from their observations.

Beta - dormant in production. Knowledge graph memory is built and merged, but no tenant has it enabled yet. The gate, admin model selection, and plan entitlement are all live; turning it on for a project is safe but unproven at scale. Expect rough edges and treat graph-augmented recall as additive, not authoritative.

Knowledge graph (KG) memory builds an entity-relation graph from your agents' observations - services, modules, decisions, dependencies, and the typed relationships between them. Once a graph exists for a project, recall and session-start injection can merge in relevant graph triplets (subject → relationship → object) alongside flat observation recall, and agents on that project gain five graph MCP tools for querying it directly.

KG memory is opt-in per project. It is not on by default, and enabling it on one project never affects another.

The enablement gate

A project gets knowledge graph memory only when both conditions hold:

The project's agent memory is enabled (master memory switch is on), and
Graph is on for the project.

"Graph is on" uses OR semantics: graph is on when either

the project's own graph toggle is explicitly true, or
your plan includes KG - the kg_enabled entitlement granted by your plan.

The resolver behind this gate is isGraphEnabledForProject(orgId, projectId) (project-config.ts), and every live consumer checks it before doing graph work.

OR semantics has a tradeoff, stated honestly. A project can always opt IN explicitly via its graph toggle. But while your plan grants kg_enabled, an individual project cannot opt OUT - the plan entitlement satisfies the "graph on" side of the gate on its own. If you need a project with memory but without the graph, that requires a plan that does not include the KG entitlement.

How to turn it on

Per-project memory (including the graph toggle) is configured in the Memory config for the project - the MemoryConfigPanel on the project's performance / settings page.

Step	Where
1. Enable agent memory for the project	Memory config → master memory switch
2. Turn on the project graph toggle (skip if your plan already grants `kg_enabled`)	Memory config → graph toggle

Both are persisted through the same endpoint:

PUT /api/projects/[projectId]/memory-config

The panel reads and writes the project's project_memory_config row; the graph toggle maps to the graph_enabled field that isGraphEnabledForProject reads. If your plan grants KG, the panel reflects that the graph is already on regardless of the per-project toggle.

What turning it on does

Once the gate is satisfied for a project, three things start happening:

The graph starts building. The extraction cron enumerates KG-enabled (org, project) pairs and turns recent observations into graph nodes and edges. See the extraction pipeline.
Recall gets graph-augmented. Both recall and session-start injection begin merging relevant graph triplets into the context handed to agents - subject to your platform operator's per-work-type recall settings, which decide which agent work types receive graph-augmented context.
Agents gain the graph tools. The five graph MCP tools (graph_query, graph_neighbors, graph_path, plus the admin graph_ingest / graph_improve) become available to agents on that project. With the gate off, the MCP transport refuses graph tools and graph recall entirely.

What it needs to actually produce a graph

Enabling the gate makes a project eligible, but the graph only fills in once your platform operator enables the extraction model. Extraction runs an operator-selected language model to read observations and emit entities and relationships; until that model is configured on the operator side, the gate is satisfied but no nodes are produced.

The extraction model and its credential are configured by your platform operator, not by tenants. If you have enabled the gate and the graph stays empty, ask your operator to confirm the extraction model is configured.

Fleet extraction runs under your own subscription

Orgs can additionally carry the kg_fleet_extraction entitlement (plan-assigned or set per-org by your platform operator). When it is on, automated graph extraction jobs are dispatched to your own runner fleet instead of the platform-side extractor: the extraction LLM calls run on a machine where your daemon is registered, authenticated by your own model subscription or local credentials (host-session / local auth modes - the same way your coding agents run).

What that means in practice - please read this before enabling:

Your subscription is consumed. Extraction is an automated, recurring background workload. Its LLM usage counts against the personal or team plan (e.g. your Claude or Google subscription) that your daemon host is logged into, even when no human triggered the run.
Your machine does the work. Jobs occupy a worker slot on your fleet like any other dispatched session.
Embeddings stay platform-funded. Only the extraction LLM calls move to your fleet; vector embedding of the resulting graph remains on the platform's own keys.
Off by default. Without the entitlement, extraction runs platform-side on operator-configured credentials and touches nothing of yours.

If you do not want background extraction consuming your subscription, ask your operator to leave kg_fleet_extraction off for your org - graph memory still works through the platform-side extractor.

Knowledge Graph Store - where the extracted graph lives
Extraction Pipeline - how observations become nodes and edges
Graph MCP Tools - the agent-callable graph tools unlocked by enablement
Context Injection - how graph triplets enter agent prompts
In-session Injection - flat observation recall this augments