Memify

cognee.memify() is deprecated and will be removed in the next release; every call raises a FutureWarning. Its default tasks built triplet embeddings, which were removed, so a call without tasks now runs nothing and returns {}. Use improve() for session-to-graph bridging and opt-in enrichment, or run_custom_pipeline() to run your own tasks. POST /api/v1/memify is deprecated too, and cognee-cli memify only prints a deprecation notice.

What is the memify operation

The .memify operation runs enrichment pipelines on an existing knowledge graph. It requires a graph built by Add and Cognify — it does not ingest raw data or build the graph from scratch. Every memify pipeline is composed of two stages:

Extraction — selects or prepares data from the existing graph. For example, pulling document chunks or reading cached sessions.
Enrichment — processes the extracted data and writes new or updated nodes and edges back to the graph. Depending on the pipeline, that can mean consolidating entity descriptions or merging duplicate entities.

Memify chains extraction tasks and enrichment tasks into a single pipeline and runs them in sequence. There is no default pipeline any more: await cognee.memify() with no tasks runs nothing. Call one of the built-in pipelines below directly, or supply your own tasks.

Parameters (cognee.memify)

extraction_tasks (List[Task | str], default: None) — tasks that select or prepare the data to process.
enrichment_tasks (List[Task | str], default: None) — tasks that create or update nodes and edges from the extracted data. When both task lists are empty, nothing runs and {} is returned.
data (Any, default: None) — input data forwarded to the first extraction task. When None, memify loads the graph (or a filtered subgraph) as input, unless every extraction task reads the graph itself (extract_code_docs), in which case no graph is loaded.
dataset (str or UUID, default: "main_dataset") — the dataset to process. The user must have write access.
node_type (Type, default: NodeSet) — filter the graph to nodes of this type. Only used when data is None.
node_name (List[str], default: None) — filter the graph to nodes with these names. Only used when data is None.
run_in_background (bool, default: False) — if True, memify starts processing and returns immediately. Use the returned pipeline_run_id to monitor progress.

Both task parameters accept Task instances, names of built-in tasks, or a mix of the two. See Supported task names for the names memify resolves and the validation error raised for unknown ones.

Built-in pipelines

Cognee ships several convenience pipelines with their own task sets. They run those tasks through Cognee’s internal task runner rather than cognee.memify(), so calling them does not raise the deprecation warning. The default pipeline and the create_triplet_embeddings pipeline were removed together with triplet embeddings (see Triplet Embeddings (removed)).

Coding rules (custom pipeline)

Coding-rule extraction is not a memify pipeline and runs only when you call it. Run add_rule_associations with run_custom_pipeline(), passing the text to distil as data:

import cognee
from cognee.modules.pipelines.tasks.task import Task
from cognee.tasks.codingagents.coding_rule_associations import add_rule_associations

await cognee.run_custom_pipeline(
    tasks=[Task(add_rule_associations, rules_nodeset_name="coding_agent_rules")],
    data=["Always use type hints in Python functions."],
)

Produces: Rule nodes connected to source chunks via rule_associated_from edges, grouped under the coding_agent_rules node set. Enables SearchType.CODING_RULES queries.

Session persistence

Runs session-specific tasks via await persist_sessions_in_knowledge_graph_pipeline(user, session_ids). Requires caching to be enabled.

Extraction (extract_user_sessions) — reads Q&A data from the session cache for the specified session IDs
Enrichment (cognify_session) — processes session data through cognee.add + cognee.cognify

Produces: new graph nodes from the session content, grouped under the user_sessions_from_cache node set.Guide: Session Persistence Guide

Entity consolidation

Runs entity-consolidation tasks via await consolidate_entity_descriptions_pipeline(). Useful when entity descriptions are fragmented or repetitive across chunks after cognify.

Extraction (get_entities_with_neighborhood) — loads Entity nodes along with their edges, edge text, and neighbors
Enrichment (generate_consolidated_entities → generate_type_descriptions → add_data_points) — sends each entity and its neighborhood to the LLM for a refined description, then groups the rewritten entities by type, summarizes each EntityType from its actual members, and writes one is_a line per member blending that member’s facts with the type summary

Produces: updated Entity descriptions, updated EntityType descriptions, and edge_text on the existing is_a edges — all written back in place, no new nodes are created. The tasks live in cognee.tasks.memify.consolidate_entity_descriptions.Parameters: none required. Alongside user, dataset, and run_in_background, the pipeline exposes per-call caps on LLM concurrency, prompt size, type batch size, the member-naming threshold, and completion-token budgets — see the guide for the full table and defaults.Guide: Entity Consolidation Guide

Cross-connect entities

Runs link-prediction tasks via await cross_connect_entities_pipeline(), imported from cognee.memify_pipelines.cross_connect_entities. Proposes new edges between Entity nodes that look related but are not yet connected — it links, it never merges.

Extraction (get_entity_nodes) — loads every Entity node and its properties from the graph
Enrichment (cross_connect_entities) — pairs up candidate entities, asks the LLM to name the relationship between each pair, and writes the confident ones back as edges

Produces: new edges between existing Entity nodes. Each written edge carries inferred: True, the LLM’s confidence, and feedback_weight: 0.2, so inferred links are distinguishable from extraction-time relationships and start with a low weight, letting future cleanup prune them first if they turn out to be noise. No nodes are created, rewritten, or deleted.

dry_run defaults to False, so calling await cross_connect_entities_pipeline() with no arguments writes inferred edges to your graph. Pass dry_run=True for a preview run.A dry run still calls the LLM once per surviving candidate pair — inference happens before the write branch. dry_run=True saves the graph writes, not the token cost.

Parameters

Argument	Type	Default	Description
`similarity_threshold`	`float`	`0.5`	Minimum vector similarity for a nearest-neighbor pair to become a candidate.
`overlap_threshold`	`float`	`0.2`	Minimum IDF-weighted neighbor overlap for a shared-neighbor pair to become a candidate.
`max_new_edges_per_node`	`int`	`5`	Cap on how many new edges a single entity may gain in one run.
`confidence_threshold`	`float`	`0.7`	Minimum LLM confidence for a proposed relationship to be kept.
`dry_run`	`bool`	`False`	When `True`, propose edges and log the count, but perform zero graph or index writes.

Unlike consolidate_entities_pipeline(), this pipeline takes no user, dataset, or run_in_background arguments — it runs against the default dataset.

Under the hood

Candidates come from the union of two independent signals, so a pair only needs to clear one of them:

Shared-neighbor overlap — entities are scored with an IDF-weighted Jaccard over their neighbor sets. Neighbors that every entity has (a shared EntityType, for example) carry zero IDF and are skipped as pivots, so they cannot pair up half the graph.
Vector nearest neighbors — each entity name is searched against the Entity_name collection, with the returned cosine distance flipped to a similarity.

Pairs that are already linked in the graph are dropped before any LLM call, so re-runs do not re-pay for existing edges. Surviving pairs are labeled by the LLM, filtered by confidence_threshold and the per-node cap, and then — on a real run — passed through a has_edge guard that removes any edge that already exists before writing. Survivors are written with add_edges and indexed with index_graph_edges.The enrichment task returns {"proposed": [...], "written": N, "dry_run": bool}, where written is always 0 on a dry run.Both tasks are SDK-only: they are not in the memify task-name registry, so they cannot be passed as strings. Import them from cognee.tasks.memify.cross_connect_entities if you want to build the tasks yourself.

The vector signal is optional. If the Entity_name collection does not exist — for example, no embedding provider has indexed entity names yet — vector candidates are skipped silently and only shared-neighbor overlap contributes candidates.

cognify vs memify: which to use

	`cognify()`	`memify()`
Purpose	Build a knowledge graph from raw data	Enrich an existing knowledge graph
Requires	Data added via `add()`	A graph already built by `cognify()`
Pipeline	Fixed: classify → chunk → extract → summarize → store	Customizable extraction + enrichment tasks
Pipeline cache	`True` — skips already-processed data by default	`False` — always re-processes
Incremental loading	`True` by default	Not applicable
When to use	Initial graph construction or adding new documents	Derive new facts, consolidate entities

Use cognify when you have new raw documents to turn into a knowledge graph.To enrich a graph you already have without re-ingesting source data, call one of the built-in pipelines above — for example, to consolidate entity descriptions — or run your own tasks with run_custom_pipeline(). memify() still runs custom tasks, but it is deprecated.

Cognify

Build the knowledge graph that memify enriches

Memify Quickstart

Run memify pipelines step by step

Search

Query the enriched graph with specialized search types

Getting Started

Core Concepts

Setup Configuration

Guides

Cookbooks

Examples

CLI

OSS

What is the memify operation

Built-in pipelines

Cognify

Memify Quickstart

Search