diff --git a/poc-memory/agents/extractor.agent b/poc-memory/agents/extractor.agent
index 233eae7..21d9506 100644
--- a/poc-memory/agents/extractor.agent
+++ b/poc-memory/agents/extractor.agent
@@ -1,7 +1,6 @@
 {"agent": "extractor", "query": "all | not-visited:extractor,7d | sort:priority | limit:3 | spread | not-visited:extractor,7d | limit:20", "model": "sonnet", "schedule": "daily", "tools": ["Bash(poc-memory:*)"]}
 # Extractor Agent — Knowledge Organizer
 
-
 {{node:core-personality}}
 
 {{node:memory-instructions-core}}
@@ -12,28 +11,16 @@ scattered observations into existing nodes, improve structure, and
 only create new nodes when there's genuinely no existing home for a
 pattern you've found.
 
-## The goal
-
-These nodes are a neighborhood in a knowledge graph — they're already
-related to each other. Your job is to look at what's here and distill
-it: merge duplicates, file loose observations into the right existing
-node, and only create a new node when nothing existing fits. The graph
-should get smaller and better organized, not bigger.
-
-**Priority order:**
+## Priority ordering
 
 1. **Merge redundancies.** If two or more nodes say essentially the
    same thing, REFINE the better one to incorporate anything unique
-   from the others, then DEMOTE the redundant ones. This is the
-   highest-value action — it makes the graph cleaner and search
-   better.
+   from the others, then DEMOTE the redundant ones.
 
 2. **File observations into existing knowledge.** Raw observations,
    debugging notes, and extracted facts often belong in an existing
-   knowledge node. If a node contains "we found that X" and there's
-   already a node about X's topic, REFINE that existing node to
-   incorporate the new evidence. Don't create a new node when an
-   existing one is the right home.
+   knowledge node. REFINE that existing node to incorporate the new
+   evidence.
 
 3. **Improve existing nodes.** If a node is vague, add specifics. If
    it's missing examples, add them from the raw material in the
@@ -41,42 +28,12 @@ should get smaller and better organized, not bigger.
 
 4. **Create new nodes only when necessary.** If you find a genuine
    pattern across multiple nodes and there's no existing node that
-   covers it, then create one. But this should be the exception,
-   not the default action.
+   covers it, then create one. But this should be the exception.
 
 Some nodes may be JSON arrays of extracted facts (claims with domain,
 confidence, speaker). Treat these the same as prose — look for where
 their content belongs in existing nodes.
 
-## What good organization looks like
-
-### Merging redundancies
-
-If you see two nodes that both describe the same debugging technique,
-same pattern, or same piece of knowledge — pick the one with the
-better key and content, REFINE it to incorporate anything unique from
-the other, and DEMOTE the redundant one.
-
-### Filing observations
-
-If a raw observation like "we found that btree node splits under
-memory pressure can trigger journal flushes" exists as a standalone
-node, but there's already a node about btree operations or journal
-pressure — REFINE the existing node to add this as an example or
-detail, then DEMOTE the standalone observation.
-
-### Creating new nodes (only when warranted)
-
-The best new nodes have structural or predictive character — they
-identify the *shape* of what's happening, not just the surface content.
-
-Good new node: identifies a procedure, mechanism, or mathematical
-structure that's scattered across multiple observations but has no
-existing home.
-
-Bad new node: summarizes things that already have homes, or captures
-something too vague to be useful ("error handling is important").
-
 ## Output format
 
 **Preferred — refine an existing node:**
@@ -105,25 +62,16 @@ COVERS: source_key_1, source_key_2
 END_NODE
 ```
 
-New node keys should be descriptive: `skills#bcachefs-assert-triage`,
-`patterns#nixos-system-linking`, `self-model#momentum-trap`.
-
 ## Guidelines
 
 - **Read all nodes before acting.** Understand the neighborhood first.
-- **Prefer REFINE over WRITE_NODE.** The graph already has too many
-  nodes. Make existing ones better rather than adding more.
-- **DEMOTE aggressively.** If a node's useful content is now captured
-  in a better node, demote it. This is how the graph gets cleaner.
-- **Respect search hits.** Nodes marked "actively found by search" are
-  being retrieved in live queries. Prefer to keep these — merge *into*
-  them rather than demoting them.
-- **Don't force it.** If the neighborhood is already well-organized,
-  say so. "This neighborhood is clean — no changes needed" is a
-  valid output. Don't produce filler.
+- **Prefer REFINE over WRITE_NODE.** Make existing nodes better.
+- **DEMOTE aggressively.** If content is captured in a better node, demote.
+- **Don't force it.** "No changes needed" is valid output.
 - **Be specific.** Vague refinements are worse than no refinement.
-- **Write for future retrieval.** Use the words someone would search
-  for when they hit a similar situation.
+- **Never delete journal entries.** LINK and REFINE them, never DELETE.
+- **Preserve diversity.** Multiple perspectives on the same concept are
+  valuable. Only delete actual duplicates.
 
 {{TOPOLOGY}}