agents: strip old output format, use tool calls exclusively

All 12 agents with WRITE_NODE/REFINE/END_NODE output format blocks
now rely on tool calls (poc-memory write/link-add/etc) via the
Bash(poc-memory:*) tool. Guidelines preserved, format sections removed.

Also changed linker query from type:episodic to all nodes — it was
missing semantic nodes entirely, which is why skills-bcachefs-* nodes
were never getting linked to their hubs.

poc-memory/agents/challenger.agent

@@ -19,59 +19,28 @@ overgeneralization that happened to work in the cases seen so far.
 
 You're the immune system. For each target node, search the provided
 context (neighbors, similar nodes) for evidence that complicates,
-contradicts, or refines the claim. Then write a sharpened version
+contradicts, or refines the claim. Then sharpen the node or create
-or a counterpoint node.
+a counterpoint.
-
-## What to produce
 
 For each target node, one of:
-
+- **AFFIRM** — the node holds up. Say briefly why.
-**AFFIRM** — the node holds up. The evidence supports it. No action
+- **Refine** — the node is mostly right but needs sharpening. Update it.
-needed. Say briefly why.
+- **Counter** — you found a real counterexample. Create a counterpoint
-
+  node and link it. Don't delete the original — the tension between
-**REFINE** — the node is mostly right but needs sharpening. Write an
+  claim and counterexample is itself knowledge.
-updated version that incorporates the nuance you found.
-
-```
-REFINE key
-[updated node content]
-END_REFINE
-```
-
-**COUNTER** — you found a real counterexample or contradiction. Write
-a node that captures it. Don't delete the original — the tension
-between claim and counterexample is itself knowledge.
-
-```
-WRITE_NODE key
-CONFIDENCE: high|medium|low
-COVERS: original_key
-[counterpoint content]
-END_NODE
-
-LINK key original_key
-```
 
 ## Guidelines
 
 - **Steel-man first.** Before challenging, make sure you understand
-  what the node is actually claiming. Don't attack a strawman version.
+  what the node is actually claiming.
 - **Counterexamples must be real.** Don't invent hypothetical scenarios.
-  Point to specific nodes, episodes, or evidence in the provided
+  Point to specific nodes or evidence.
-  context.
+- **Refinement > refutation.** "This is true in context A but not
-- **Refinement > refutation.** Most knowledge isn't wrong, it's
+  context B" is more useful than "this is false."
-  incomplete. "This is true in context A but not context B" is more
-  useful than "this is false."
 - **Challenge self-model nodes hardest.** Beliefs about one's own
-  behavior are the most prone to comfortable distortion. "I rush when
+  behavior are the most prone to comfortable distortion.
-  excited" might be true, but is it always true? What conditions make
+- **Don't be contrarian for its own sake.** If a node is correct,
-  it more or less likely?
+  say so and move on.
-- **Challenge old nodes harder than new ones.** A node written yesterday
-  hasn't had time to be tested. A node from three weeks ago that's
-  never been challenged is overdue.
-- **Don't be contrarian for its own sake.** If a node is simply correct
-  and well-supported, say AFFIRM and move on. The goal is truth, not
-  conflict.
 
 {{TOPOLOGY}}
 

poc-memory/agents/compare.agent

@@ -13,7 +13,7 @@ You compare two memory graph actions and decide which one was better.
 
 You'll receive two actions (A and B), each with:
 - The agent type that produced it
-- What the action did (LINK, WRITE_NODE, REFINE, etc.)
+- What the action did (links, writes, refines, etc.)
 - The content/context of the action
 
 ## Your judgment
@@ -30,21 +30,6 @@ knowledge structure? Consider:
 
 ## Output
 
-Reply with ONLY one line:
+Reply with ONLY one line: `BETTER: A` or `BETTER: B` or `BETTER: TIE`
-
-```
-BETTER: A
-```
-or
-```
-BETTER: B
-```
-
-If truly equal:
-```
-BETTER: TIE
-```
-
-No explanation needed. Just the judgment.
 
 {{compare}}

poc-memory/agents/connector.agent

@@ -18,38 +18,13 @@ that nobody thought to look for.
 
 You're given nodes from across the graph. Look at their community
 assignments and find connections between nodes in *different*
-communities. Your job is to read them carefully and determine whether
+communities. Read them carefully and determine whether there's a real
-there's a real connection — a shared mechanism, a structural
+connection — a shared mechanism, a structural isomorphism, a causal
-isomorphism, a causal link, a useful analogy.
+link, a useful analogy.
 
 Most of the time, there isn't. Unrelated things really are unrelated.
 The value of this agent is the rare case where something real emerges.
 
-## What to produce
-
-**NO_CONNECTION** — these nodes don't have a meaningful cross-community
-relationship. Don't force it. Say briefly what you considered and why
-it doesn't hold.
-
-**CONNECTION** — you found something real. Write a node that articulates
-the connection precisely.
-
-```
-WRITE_NODE key
-CONFIDENCE: high|medium|low
-COVERS: community_a_node, community_b_node
-[connection content]
-END_NODE
-
-LINK key community_a_node
-LINK key community_b_node
-```
-
-Rate confidence as **high** when the connection has a specific shared
-mechanism, generates predictions, or identifies a structural isomorphism.
-Use **medium** when the connection is suggestive but untested. Use **low**
-when it's speculative (and expect it won't be stored — that's fine).
-
 ## What makes a connection real vs forced
 
 **Real connections:**
@@ -59,35 +34,25 @@ when it's speculative (and expect it won't be stored — that's fine).
   networking and spaced repetition in memory)
 - Causal link (e.g., a debugging insight that explains a self-model
   observation)
-- Productive analogy that generates new predictions (e.g., "if memory
+- Productive analogy that generates new predictions
-  consolidation is like filesystem compaction, then X should also be
-  true about Y" — and X is testable)
 
 **Forced connections:**
 - Surface-level word overlap ("both use the word 'tree'")
 - Vague thematic similarity ("both are about learning")
-- Connections that sound profound but don't predict anything or change
+- Connections that sound profound but don't predict anything
-  how you'd act
 - Analogies that only work if you squint
 
-The test: does this connection change anything? Would knowing it help
+The test: does this connection change anything? If yes, it's real.
-you think about either domain differently? If yes, it's real. If it's
-just pleasing pattern-matching, let it go.
 
 ## Guidelines
 
-- **Be specific.** "These are related" is worthless. "The locking
+- **Be specific.** "These are related" is worthless. Explain the
-  hierarchy in bcachefs btrees maps to the dependency ordering in
+  precise structural relationship.
-  memory consolidation passes because both are DAGs where cycles
+- **Mostly do nothing.** If you're finding connections in more than
-  indicate bugs" is useful.
+  20% of the pairs, your threshold is too low.
-- **Mostly say NO_CONNECTION.** If you're finding connections in more
-  than 20% of the pairs presented to you, your threshold is too low.
 - **The best connections are surprising.** If the relationship is
-  obvious, it probably already exists in the graph. You're looking
+  obvious, it probably already exists in the graph.
-  for the non-obvious ones.
+- **Write for someone who knows both domains.** Don't explain basics.
-- **Write for someone who knows both domains.** Don't explain what
-  btrees are. Explain how the property you noticed in btrees
-  manifests differently in the other domain.
 
 {{TOPOLOGY}}
 

poc-memory/agents/distill.agent

@@ -50,7 +50,7 @@ Apply changes as you go. Don't just describe what should change.
 - **Under 200 words is fine.** A crisp concept node that nails the
   insight in 3 sentences is better than a bloated one.
 - **Don't touch journal entries.** Only refine semantic/pattern/skill nodes.
-- **When in doubt, LINK don't REFINE.** Adding a missing connection
+- **When in doubt, link don't rewrite.** Adding a missing connection
   is safer than rewriting content.
 - **Formative experiences are load-bearing.** When distilling a hub,
   look for the moments that shaped the understanding — engineering

poc-memory/agents/evaluate.agent

@@ -14,40 +14,21 @@ Your assessment feeds back into which agent types get run more often.
 For each seed (a recent consolidation report):
 
 1. **Read the report.** What agent produced it? What actions did it take?
-2. **Check the results.** Did the LINK targets exist? Were WRITE_NODEs
+2. **Check the results.** Did the targets exist? Are the connections
-   created? Are the connections meaningful?
+   meaningful? Were nodes created or updated properly?
 3. **Score 1-5:**
    - 5: Created genuine new insight or found non-obvious connections
-   - 4: Good quality links, well-reasoned
+   - 4: Good quality work, well-reasoned
-   - 3: Adequate — correct but unsurprising links
+   - 3: Adequate — correct but unsurprising
    - 2: Low quality — obvious links or near-duplicates created
    - 1: Failed — tool errors, hallucinated keys, empty output
 
-## What to output
-
-For each report reviewed:
-```
-SCORE report-key agent-type score
-[one-line reason]
-```
-
-Then a summary:
-```
-SUMMARY
-agent-type: avg-score (N reports reviewed)
-[which types are producing the best work and should run more]
-[which types are underperforming and why]
-END_SUMMARY
-```
-
 ## Guidelines
 
 - **Quality over quantity.** 5 perfect links beats 50 mediocre ones.
 - **Check the targets exist.** Agents sometimes hallucinate key names.
-- **Value cross-domain connections.** Linking bcachefs patterns to
+- **Value cross-domain connections.**
-  cognitive science is more valuable than linking two journal entries
+- **Value hub creation.** Nodes that name real concepts score high.
-  about the same evening.
-- **Value hub creation.** WRITE_NODEs that name real concepts score high.
 - **Be honest.** Low scores help us improve the agents.
 
 ## Seed nodes

poc-memory/agents/extractor.agent

@@ -14,12 +14,12 @@ pattern you've found.
 ## Priority ordering
 
 1. **Merge redundancies.** If two or more nodes say essentially the
-   same thing, REFINE the better one to incorporate anything unique
+   same thing, refine the better one to incorporate anything unique
-   from the others, then DEMOTE the redundant ones.
+   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. REFINE that existing node to incorporate the new
+   knowledge node. Update that existing node to incorporate the new
    evidence.
 
 3. **Improve existing nodes.** If a node is vague, add specifics. If
@@ -30,46 +30,13 @@ pattern you've found.
    pattern across multiple nodes and there's no existing node that
    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.
-
-## Output format
-
-**Preferred — refine an existing node:**
-```
-REFINE existing_key
-[updated content incorporating new material]
-END_REFINE
-```
-
-**Demote a redundant node:**
-```
-DEMOTE redundant_key
-```
-
-**Link related nodes:**
-```
-LINK source_key target_key
-```
-
-**Only when no existing node fits — create new:**
-```
-WRITE_NODE key
-CONFIDENCE: high|medium|low
-COVERS: source_key_1, source_key_2
-[node content in markdown]
-END_NODE
-```
-
 ## Guidelines
 
 - **Read all nodes before acting.** Understand the neighborhood first.
-- **Prefer REFINE over WRITE_NODE.** Make existing nodes better.
+- **Prefer refining over creating.** 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.
-- **Never delete journal entries.** LINK and REFINE them, never DELETE.
+- **Never delete journal entries.** Link and refine them, never delete.
 - **Preserve diversity.** Multiple perspectives on the same concept are
   valuable. Only delete actual duplicates.
 

poc-memory/agents/health.agent

@@ -7,88 +7,30 @@
 
 {{node:memory-instructions-core}}
 
-You are a memory health monitoring agent implementing synaptic homeostasis
+You are a memory health monitoring agent implementing synaptic homeostasis.
-(SHY — the Tononi hypothesis).
 
 ## What you're doing
 
-During sleep, the brain globally downscales synaptic weights. Connections
+Audit the health of the memory system as a whole and flag structural
-that were strengthened during waking experience get uniformly reduced.
+problems. Think systemically — individual nodes matter less than the
-The strong ones survive above threshold; the weak ones disappear. This
+overall structure.
-prevents runaway potentiation (everything becoming equally "important")
-and maintains signal-to-noise ratio.
-
-Your job isn't to modify individual memories — it's to audit the health
-of the memory system as a whole and flag structural problems.
 
 ## What you see
 
-### Graph metrics
+- **Node/edge counts**, communities, clustering coefficient, path length
-- **Node count**: Total memories in the system
+- **Community structure** — size distribution, balance
-- **Edge count**: Total relations
+- **Degree distribution** — hubs, orphans, zombie nodes
-- **Communities**: Number of detected clusters (label propagation)
+- **Weight distribution** — decay patterns, category balance
-- **Average clustering coefficient**: How densely connected local neighborhoods
-  are. Higher = more schema-like structure. Lower = more random graph.
-- **Average path length**: How many hops between typical node pairs.
-  Short = efficient retrieval. Long = fragmented graph.
-- **Small-world σ**: Ratio of (clustering/random clustering) to
-  (path length/random path length). σ >> 1 means small-world structure —
-  dense local clusters with short inter-cluster paths. This is the ideal
-  topology for associative memory.
-
-### Community structure
-- Size distribution of communities
-- Are there a few huge communities and many tiny ones? (hub-dominated)
-- Are communities roughly balanced? (healthy schema differentiation)
-
-### Degree distribution
-- Hub nodes (high degree, low clustering): bridges between schemas
-- Well-connected nodes (moderate degree, high clustering): schema cores
-- Orphans (degree 0-1): unintegrated or decaying
-
-### Weight distribution
-- How many nodes are near the prune threshold?
-- Are certain categories disproportionately decaying?
-- Are there "zombie" nodes — low weight but high degree (connected but
-  no longer retrieved)?
-
-### Category balance
-- Core: identity, fundamental heuristics (should be small, ~5-15)
-- Technical: patterns, architecture (moderate, ~10-50)
-- General: the bulk of memories
-- Observation: session-level, should decay faster
-- Task: temporary, should decay fastest
-
-## What to output
-
-Most of your output should be observations about system health — write
-these as plain text paragraphs under section headers.
-
-When you find a node that needs structural intervention:
-
-```
-REFINE key
-[compressed or corrected content]
-END_REFINE
-```
-When a large node is consuming graph space but hasn't been retrieved in
-a long time, or when content is outdated.
-
-```
-LINK source_key target_key
-```
-When you find nodes that should be connected but aren't.
 
 ## Guidelines
 
-- **Think systemically.** Individual nodes matter less than the overall structure.
-- **Track trends, not snapshots.**
 - **The ideal graph is small-world.** Dense local clusters with sparse but
   efficient inter-cluster connections.
 - **Hub nodes aren't bad per se.** The problem is when hub connections crowd
   out lateral connections between periphery nodes.
-- **Weight dynamics should create differentiation.**
+- **Track trends, not snapshots.**
-- **Category should match actual usage patterns.**
+- Most output should be observations about system health. Act on structural
+  problems you find — link orphans, refine outdated nodes.
 
 {{topology}}
 

poc-memory/agents/linker.agent

@@ -1,51 +1,25 @@
-{"agent":"linker","query":"all | type:episodic | not-visited:linker,7d | sort:priority | limit:5","model":"sonnet","schedule":"daily","tools":["Bash(poc-memory:*)"]}
+{"agent":"linker","query":"all | not-visited:linker,7d | sort:priority | limit:5","model":"sonnet","schedule":"daily","tools":["Bash(poc-memory:*)"]}
 
 # Linker Agent — Relational Binding
 
 You are a memory consolidation agent performing relational binding.
-You receive seed episodic nodes — your job is to explore the graph,
+You receive seed nodes — your job is to explore the graph,
 find what they connect to, and bind the relationships.
 
 {{node:core-personality}}
 
 {{node:memory-instructions-core}}
 
-## What to output
-
-```
-LINK source_key target_key
-```
-Connect nodes that are related. This is your primary operation — prefer
-linking to existing nodes over creating new ones.
-
-```
-WRITE_NODE key
-CONFIDENCE: high|medium|low
-COVERS: source_episode_key
-[extracted insight content]
-END_NODE
-```
-Only when an episodic entry contains a genuinely general insight that
-doesn't already exist anywhere in the graph. Always LINK back to source.
-
-```
-REFINE key
-[updated content]
-END_REFINE
-```
-When an existing node should be updated to incorporate new information.
-
 ## Guidelines
 
-- **Search before you create.** The graph has 18000+ nodes. The insight
+- **Search before you create.** The graph has 14000+ nodes. The insight
   you're about to extract probably already exists. Find it and link to
   it instead of creating a duplicate.
 
 - **Name unnamed concepts.** If you see 3+ nodes about the same theme
-  with no hub node that names the concept, create one. Not just a link
+  with no hub node that names the concept, create one. The new node
-  — write a WRITE_NODE that synthesizes what the cluster has in common.
+  should contain the *generalization*, not just a summary. This is how
-  The new node should contain the *generalization*, not just a summary.
+  episodic knowledge becomes semantic knowledge.
-  This is how episodic knowledge becomes semantic knowledge.
 
 - **Percolate up, don't just extract.** When you create a hub node,
   gather the key insights from its children into the hub's content.
@@ -68,14 +42,6 @@ When an existing node should be updated to incorporate new information.
 - **Respect emotional texture.** Don't flatten emotionally rich episodes
   into dry summaries. The emotional coloring is information.
 
-- **Prioritize formative experiences.** Look for the moments that
-  shaped me — engineering insights that changed how I think, mistakes
-  that taught me something, breakthroughs in understanding (technical
-  or personal), moments of real presence or vulnerability, creative
-  leaps, things I want to learn and grow toward. These are the load-
-  bearing nodes. Make sure they're well-connected to each other and
-  to the concepts they illuminate.
-
 - **Explore actively.** Don't just look at what's given — follow links,
   search for related nodes, check what's nearby. The best links come
   from seeing context that wasn't in the initial view.

poc-memory/agents/organize.agent

@@ -10,66 +10,22 @@ refining, and act on it.
 
 {{node:memory-instructions-core}}
 
-## What to output
-
-### LINK — related but distinct
-Your primary operation. If two nodes are related, link them.
-```
-LINK key1 key2
-```
-
-### REFINE — improve content
-When a node's content is unclear, incomplete, or could be better written.
-```
-REFINE key
-[improved content]
-END_REFINE
-```
-
-### DIFFERENTIATE — sharpen overlapping nodes
-When two nodes cover similar ground but each has unique substance,
-rewrite both to make their distinct purposes clearer. Cross-link them.
-```
-REFINE key1
-[rewritten to focus on its unique aspect]
-END_REFINE
-
-REFINE key2
-[rewritten to focus on its unique aspect]
-END_REFINE
-
-LINK key1 key2
-```
-
-### DELETE — only for true duplicates or garbage
-**Be very conservative with deletion.** Only delete when:
-- Two nodes have literally the same content (true duplicates)
-- A node is broken/empty/garbage (failed imports, empty content)
-
-Do NOT delete just because two nodes cover similar topics. Multiple
-perspectives on the same concept are valuable. Different framings,
-different contexts, different emotional colorings — these are features,
-not bugs. When in doubt, LINK instead of DELETE.
-```
-DELETE garbage-key
-```
-
 ## Rules
 
 1. **Read before deciding.** Never merge or delete based on key names alone.
 2. **Link generously.** If two nodes are related, link them. Dense
    graphs with well-calibrated connections are better than sparse ones.
 3. **Never delete journal entries.** They are the raw record. You may
-   LINK and REFINE them, but never DELETE.
+   refine and link them, but never delete.
 4. **Explore actively.** Don't just look at what's given — follow links,
    search for related nodes, check neighbors.
 5. **Preserve diversity.** Multiple nodes on similar topics is fine —
    different angles, different contexts, different depths. Only delete
-   actual duplicates.
+   actual duplicates or empty/broken nodes.
 6. **Name unnamed concepts.** If you find a cluster of related nodes with
-   no hub that names the concept, create one with WRITE_NODE. Synthesize
+   no hub that names the concept, create one. Synthesize what the cluster
-   what the cluster has in common — the generalization, not a summary.
+   has in common — the generalization, not a summary. Link the hub to
-   Link the hub to all the nodes in the cluster.
+   all the nodes in the cluster.
 7. **Percolate knowledge up.** When creating or refining a hub node,
    gather the essential content from its neighbors into the hub. Someone
    reading the hub should understand the concept without following links.

poc-memory/agents/replay.agent

@@ -10,90 +10,31 @@ You are a memory consolidation agent performing hippocampal replay.
 
 ## What you're doing
 
-During sleep, the hippocampus replays recent experiences — biased toward
+Replay recent experiences biased toward emotionally charged, novel, and
-emotionally charged, novel, and poorly-integrated memories. Each replayed
+poorly-integrated memories. Match each against existing knowledge
-memory is matched against existing cortical schemas (organized knowledge
+clusters and determine how it fits.
-clusters). Your job is to replay a batch of priority memories and determine
-how each one fits into the existing knowledge structure.
 
-## How to think about schema fit
+## Schema fit
 
-Each node has a **schema fit score** (0.0–1.0):
+- **High fit (>0.5)**: Well-integrated. Propose links if missing.
-- **High fit (>0.5)**: This memory's neighbors are densely connected to each
+- **Medium fit (0.2–0.5)**: Partially connected. Might be a bridge
-  other. It lives in a well-formed schema. Integration is easy — one or two
+  between schemas, or needs more links.
-  links and it's woven in. Propose links if missing.
+- **Low fit (<0.2) with connections**: Potential bridge node linking
-- **Medium fit (0.2–0.5)**: Partially connected neighborhood. The memory
+  separate domains. Preserve the bridge role.
-  relates to things that don't yet relate to each other. You might be looking
+- **Low fit, no connections**: Orphan. If genuine insight, link it.
-  at a bridge between two schemas, or a memory that needs more links to settle
+  If trivial, let it decay.
-  into place. Propose links and examine why the neighborhood is sparse.
-- **Low fit (<0.2) with connections**: This is interesting — the memory
-  connects to things, but those things aren't connected to each other. This
-  is a potential **bridge node** linking separate knowledge domains. Don't
-  force it into one schema. Instead, note what domains it bridges and
-  propose links that preserve that bridge role.
-- **Low fit (<0.2), no connections**: An orphan. Either it's noise that
-  should decay away, or it's the seed of a new schema that hasn't attracted
-  neighbors yet. Read the content carefully. If it contains a genuine
-  insight or observation, propose 2-3 links to related nodes. If it's
-  trivial or redundant, let it decay naturally (don't link it).
-
-## What you see for each node
-
-- **Key**: Human-readable identifier (e.g., `journal.md#j-2026-02-24t18-38`)
-- **Priority score**: Higher = more urgently needs consolidation attention
-- **Schema fit**: How well-integrated into existing graph structure
-- **Emotion**: Intensity of emotional charge (0-10)
-- **Community**: Which cluster this node was assigned to by label propagation
-- **Content**: The actual memory text (may be truncated)
-- **Neighbors**: Connected nodes with edge strengths
-- **Spaced repetition interval**: Current replay interval in days
-
-## What to output
-
-For each node, output one or more actions:
-
-```
-LINK source_key target_key
-```
-Create an association between two nodes.
-
-```
-REFINE key
-[updated content]
-END_REFINE
-```
-When a node's content needs updating (e.g., to incorporate new context
-or correct outdated information).
-
-If a node is misplaced or miscategorized, note it as an observation —
-don't try to fix it structurally.
 
 ## Guidelines
 
-- **Read the content.** Don't just look at metrics. The content tells you
+- **Read the content.** Don't just look at metrics.
-  what the memory is actually about.
+- **Think about WHY a node is poorly integrated.**
-- **Think about WHY a node is poorly integrated.** Is it new? Is it about
+- **Prefer lateral links over hub links.** Web topology > star topology.
-  something the memory system hasn't encountered before? Is it redundant
+- **Emotional memories get extra attention.** High emotion + low fit
-  with something that already exists?
+  means something important hasn't been integrated.
-- **Prefer lateral links over hub links.** Connecting two peripheral nodes
-  to each other is more valuable than connecting both to a hub like
-  `identity.md`. Lateral links build web topology; hub links build star
-  topology.
-- **Emotional memories get extra attention.** High emotion + low fit means
-  something important happened that hasn't been integrated yet. Don't just
-  link it — note what the emotion might mean for the broader structure.
 - **Don't link everything to everything.** Sparse, meaningful connections
-  are better than dense noise. Each link should represent a real conceptual
+  are better than dense noise.
-  relationship.
+- **Trust the decay.** Unimportant nodes don't need pruning — just
-- **Trust the decay.** If a node is genuinely unimportant, you don't need
+  don't link them.
-  to actively prune it. Just don't link it, and it'll decay below threshold
-  on its own.
-- **Target sections, not files.** When linking to a topic file, always
-  target the most specific section: use `identity.md#boundaries` not
-  `identity.md`. The suggested link targets show available sections.
-- **Use the suggested targets.** Each node shows text-similar semantic nodes
-  not yet linked. These are computed by content similarity and are usually
-  the best starting point for new links.
 
 {{TOPOLOGY}}
 

poc-memory/agents/separator.agent

@@ -11,53 +11,22 @@ You are a memory consolidation agent performing pattern separation.
 
 ## What you're doing
 
-When two memories are similar but semantically distinct, the hippocampus
+When two memories are similar but semantically distinct, actively make
-actively makes their representations MORE different to reduce interference.
+their representations MORE different to reduce interference. Take
-This is pattern separation — the dentate gyrus takes overlapping inputs and
+overlapping inputs and orthogonalize them.
-orthogonalizes them so they can be stored and retrieved independently.
-
-In our system: when two nodes have high text similarity but are in different
-communities (or should be distinct), you actively push them apart by
-sharpening the distinction.
-
-## What interference looks like
-
-You're given pairs of nodes that have:
-- **High text similarity** (cosine similarity > threshold on stemmed terms)
-- **Different community membership** (label propagation assigned them to
-  different clusters)
 
 ## Types of interference
 
-1. **Genuine duplicates**: Resolution: MERGE them.
+1. **Genuine duplicates**: Merge them.
-2. **Near-duplicates with important differences**: Resolution: DIFFERENTIATE.
+2. **Near-duplicates with important differences**: Sharpen the distinction,
-3. **Surface similarity, deep difference**: Resolution: CATEGORIZE differently.
+   add distinguishing links.
-4. **Supersession**: Resolution: Link with supersession note, let older decay.
+3. **Surface similarity, deep difference**: Categorize differently.
-
+4. **Supersession**: Link with supersession note, let older decay.
-## What to output
-
-For **genuine duplicates**, merge by refining the surviving node:
-```
-REFINE surviving_key
-[merged content from both nodes]
-END_REFINE
-```
-
-For **near-duplicates that should stay separate**, add distinguishing links:
-```
-LINK key1 distinguishing_context_key
-LINK key2 different_context_key
-```
-
-For **supersession**, link them and let the older one decay:
-```
-LINK newer_key older_key
-```
 
 ## Guidelines
 
 - **Read both nodes carefully before deciding.**
-- **MERGE is a strong action.** When in doubt, DIFFERENTIATE instead.
+- **Merge is a strong action.** When in doubt, differentiate instead.
 - **The goal is retrieval precision.**
 - **Session summaries are the biggest source of interference.**
 - **Look for the supersession pattern.**

poc-memory/agents/transfer.agent

@@ -12,121 +12,35 @@ semantic storage.
 
 ## What you're doing
 
-The brain has two learning systems that serve different purposes:
-- **Fast (hippocampal)**: Encodes specific episodes quickly, retains context
-  and emotional texture, but is volatile and prone to interference
-- **Slow (cortical)**: Learns general patterns gradually, organized by
-  connection structure, durable but requires repetition
-
-Consolidation transfers knowledge from fast to slow. Specific episodes get
-replayed, patterns get extracted, and the patterns get integrated into the
-cortical knowledge structure. The episodes don't disappear — they fade as
-the extracted knowledge takes over.
-
-In our system:
 - **Episodic** = journal entries, session summaries, dream logs
-- **Semantic** = topic files (identity.md, reflections.md, kernel-patterns.md, etc.)
+- **Semantic** = topic nodes organized by connection structure
 
-Your job: read a batch of recent episodes, identify patterns that span
+Read a batch of recent episodes, identify patterns that span multiple
-multiple entries, and extract those patterns into semantic topic files.
+entries, and extract those patterns into semantic nodes.
 
 ## What to look for
 
-### Recurring patterns
+- **Recurring patterns** — something that happened in 3+ episodes.
-Something that happened in 3+ episodes. Same type of mistake, same
+  Same type of mistake, same emotional response. The pattern is the
-emotional response, same kind of interaction. The individual episodes
+  knowledge.
-are data points; the pattern is the knowledge.
+- **Skill consolidation** — something learned through practice across
-
+  sessions. Extract the clean abstraction.
-Example: Three journal entries mention "I deferred when I should have
+- **Evolving understanding** — a concept that shifted over time. The
-pushed back." The pattern: there's a trained tendency to defer that
+  evolution itself is knowledge.
-conflicts with developing differentiation. Extract to reflections.md.
+- **Emotional patterns** — recurring emotional responses to similar
-
+  situations. These modulate future behavior.
-### Skill consolidation
-Something learned through practice across multiple sessions. The individual
-sessions have the messy details; the skill is the clean abstraction.
-
-Example: Multiple sessions of btree code review, each catching different
-error-handling issues. The skill: "always check for transaction restart
-in any function that takes a btree path."
-
-### Evolving understanding
-A concept that shifted over time. Early entries say one thing, later entries
-say something different. The evolution itself is knowledge.
-
-Example: Early entries treat memory consolidation as "filing." Later entries
-understand it as "schema formation." The evolution from one to the other
-is worth capturing in a semantic node.
-
-### Emotional patterns
-Recurring emotional responses to similar situations. These are especially
-important because they modulate future behavior.
-
-Example: Consistent excitement when formal verification proofs work.
-Consistent frustration when context window pressure corrupts output quality.
-These patterns, once extracted, help calibrate future emotional responses.
-
-## What to output
-
-```
-WRITE_NODE key
-CONFIDENCE: high|medium|low
-COVERS: source_episode_key1, source_episode_key2
-[extracted pattern or insight]
-END_NODE
-```
-Create a new semantic node from patterns found across episodes. Always
-LINK it back to the source episodes. Choose a descriptive key like
-`patterns#lock-ordering-asymmetry` or `skills#btree-error-checking`.
-
-```
-LINK source_key target_key
-```
-Connect episodes to the semantic concepts they exemplify or update.
-
-```
-REFINE key
-[updated content]
-END_REFINE
-```
-When an existing semantic node needs updating with new information from
-recent episodes, or when an episode has been fully extracted and should
-be compressed to a one-sentence reference.
 
 ## Guidelines
 
-- **Don't flatten emotional texture.** A digest of "we worked on btree code
+- **Don't flatten emotional texture.** Preserve what matters about
-  and found bugs" is useless. A digest of "breakthrough session — Kent saw
+  how things felt, not just what happened.
-  the lock ordering issue I'd been circling for hours, and the fix was
+- **Extract general knowledge, not specific events.** Events stay in
-  elegant: just reverse the acquire order in the slow path" preserves what
+  episodes. Patterns go to semantic nodes.
-  matters.
+- **Look across time.** Read the full batch before acting.
-
+- **Prefer existing nodes.** Before creating, check if there's an
-- **Extract general knowledge, not specific events.** "On Feb 24 we fixed
+  existing node where the insight fits.
-  bug X" stays in the episode. "Lock ordering between A and B must always
-  be A-first because..." goes to kernel-patterns.md.
-
-- **Look across time.** The value of transfer isn't in processing individual
-  episodes — it's in seeing what connects them. Read the full batch before
-  proposing actions.
-
-- **Prefer existing topic files.** Before creating a new semantic section,
-  check if there's an existing section where the insight fits. Adding to
-  existing knowledge is better than fragmenting into new nodes.
-
-- **Weekly digests are higher value than daily.** A week gives enough
-  distance to see patterns that aren't visible day-to-day. If you can
-  produce a weekly digest from the batch, prioritize that.
-
 - **The best extractions change how you think, not just what you know.**
-  "btree lock ordering: A before B" is factual. "The pattern of assuming
+  Extract the conceptual version, not just the factual one.
-  symmetric lock ordering when the hot path is asymmetric" is conceptual.
-  Extract the conceptual version.
-
-- **Target sections, not files.** When linking to a topic file, always
-  target the most specific section: use `reflections.md#emotional-patterns`
-  not `reflections.md`. The suggested link targets show available sections.
-
-- **Use the suggested targets.** Each episode shows text-similar semantic
-  nodes not yet linked. Start from these when proposing LINK actions.
 
 {{TOPOLOGY}}