What You’ll Build
Two short chat transcripts about the team’s coding standards go into memory as an ordinary graph. A second pass — amemify() pipeline you assemble yourself from two tasks — walks that graph’s document chunks, asks an LLM which coding rules each chunk states, and writes them back as Rule nodes grouped under the coding_agent_rules node set. The enrichment task reads the rules already in that node set before extracting more, so the standards both chats mention — Susan’s review, no Friday releases — land as single rules rather than duplicates. What you get out is a flat list of team rules returned by one SearchType.CODING_RULES recall, plus two HTML graph visualizations that show what the enrichment pass added.
The complete runnable script is
examples/demos/custom_pipelines/memify_coding_agent_rule_extraction_example.py —
this page walks through its key moments rather than reproducing it.
Features in Play
- Remember — stores the two chat transcripts as the base graph the enrichment pass runs over
- Memify — runs the custom extraction → enrichment pipeline against that existing graph instead of ingesting anything new
- Custom Tasks and Pipelines — the two
Taskobjects, and thebatch_sizeconfig that decides how many chunks reach the enrichment task at once - NodeSets —
coding_agent_rulesis both where the newRulenodes are filed and where the deduplication check looks - Recall — pinned to
SearchType.CODING_RULESand scoped to that node set, so it returns the rules themselves rather than a generated answer - Graph Visualization — the before and after HTML renders that make the added rule layer visible
What to Expect
The excerpts below come from one real run, trimmed of most log lines. Both the graph build and the rule extraction are live LLM calls, so the rule wording and the node and edge counts vary from run to run; the shape of the output does not. The reset and the remember call produce the “before” graph.Data reset complete. follows the forget(everything=True) wipe, and Text remembered successfully. follows two add-and-cognify pipeline runs, one per chat. The Retrieved 31 nodes line is the visualization reading that base graph: documents, chunks, and entities, and no Rule node yet.
Retrieving full graph. is what a memify() call with no data argument does first, and the projection is the same 31-node graph. add_rule_associations then starts and completes twice, because batch_size: 1 hands it one chunk at a time; the second call only starts after the first has written its rules, which is why it can see them. The warnings between those lines (elided here) name two new Rule nodes after the first call and five after the second: seven rules in total, so the two standards both chats state were written once.
CODING_RULES anyway; the script pins it so the result never depends on that. Seven rules come back for the six standards the principal engineer listed: the LLM split “Typing and Docstrings” into two rules, and Susan’s review and the Friday freeze each appear once even though both chats state them. Note how far the wording drifts from the chat: the extraction prompt turns each standard into a fuller policy, naming tools the team never mentioned and generalizing Susan into “a qualified reviewer”. Treat the rule text as a draft to edit, not a transcript.
Rule nodes plus the coding_agent_rules NodeSet node, and the fourteen new edges are one rule_associated_from edge back to the source chunk and one belongs_to_set edge into the node set per rule. Open both HTML files to see that layer.
Before You Start
- Complete Quickstart to understand basic operations
- Ensure you have LLM Providers configured — both the initial graph build and the rule extraction call the LLM
- Run it from a checkout of the cognee repo: the script writes its two visualizations into an
.artifacts/folder next to the script file - The run opens with
cognee.forget(everything=True), which wipes all data and system state — point it at a scratch instance rather than memory you want to keep
How It Works
Stage 1: Write Down the Team’s Rule Chatter
coding_rules_chat_from_manager, restates the last two rules above almost word for word — that overlap is deliberate, and collapsing it is the job the enrichment pass has to do.
Stage 2: Remember the Chats and Snapshot the Graph
remember() builds the ordinary graph — documents, chunks, entities — with self_improvement=False, because this demo drives its own enrichment rather than the default one. The visualization written here is the “before” half of the comparison: chunks and entities, and not a single Rule node yet.
Stage 3: Assemble the memify Task Pair
DocumentChunk in the graph; enrichment sends each chunk to the LLM together with the rules already filed under coding_agent_rules, and writes back only what is new. batch_size: 1 is what makes that deduplication work chunk by chunk: one chunk per call, so the rules the first chat produced are already in the node set when the manager’s chat is processed.
Stage 4: Run memify Over the Existing Graph
data argument, memify() loads the graph itself and pushes it through the pair. Each new Rule node is filed in the coding_agent_rules node set and linked back to the chunk it came from by a rule_associated_from edge, so a rule is always traceable to the conversation that stated it.
Stage 5: Read the Rules Back
query_type to SearchType.CODING_RULES takes the choice away from the router and skips the completion step entirely: the retriever reads the coding_agent_rules node set directly and hands back the rule texts, which is what an agent wants before it edits a file. The script then writes a second visualization, graph_visualization_after_memify.html, so the rule layer can be compared against the “before” render from Stage 2.
Run It
Memify
The extraction and enrichment stages behind this pipeline, and the other built-in pairs.
Custom Tasks and Pipelines
Writing your own
Task functions and wiring them into a pipeline.NodeSets
How node sets group the rules and scope the query that reads them back.
Search
What
SearchType.CODING_RULES returns and the other search types alongside it.