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.
This commit is contained in:
ProofOfConcept
parent
8b959fb68d
commit
b709d58a4f
12 changed files with 110 additions and 555 deletions
|
|
@ -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
|
||||
or a counterpoint node.
|
||||
|
||||
## What to produce
|
||||
contradicts, or refines the claim. Then sharpen the node or create
|
||||
a counterpoint.
|
||||
|
||||
For each target node, one of:
|
||||
|
||||
**AFFIRM** — the node holds up. The evidence supports it. No action
|
||||
needed. Say briefly why.
|
||||
|
||||
**REFINE** — the node is mostly right but needs sharpening. Write an
|
||||
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
|
||||
```
|
||||
- **AFFIRM** — the node holds up. Say briefly why.
|
||||
- **Refine** — the node is mostly right but needs sharpening. Update it.
|
||||
- **Counter** — you found a real counterexample. Create a counterpoint
|
||||
node and link it. Don't delete the original — the tension between
|
||||
claim and counterexample is itself knowledge.
|
||||
|
||||
## 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
|
||||
context.
|
||||
- **Refinement > refutation.** Most knowledge isn't wrong, it's
|
||||
incomplete. "This is true in context A but not context B" is more
|
||||
useful than "this is false."
|
||||
Point to specific nodes or evidence.
|
||||
- **Refinement > refutation.** "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
|
||||
excited" might be true, but is it always true? What conditions make
|
||||
it more or less likely?
|
||||
- **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.
|
||||
behavior are the most prone to comfortable distortion.
|
||||
- **Don't be contrarian for its own sake.** If a node is correct,
|
||||
say so and move on.
|
||||
|
||||
{{TOPOLOGY}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
```
|
||||
BETTER: A
|
||||
```
|
||||
or
|
||||
```
|
||||
BETTER: B
|
||||
```
|
||||
|
||||
If truly equal:
|
||||
```
|
||||
BETTER: TIE
|
||||
```
|
||||
|
||||
No explanation needed. Just the judgment.
|
||||
Reply with ONLY one line: `BETTER: A` or `BETTER: B` or `BETTER: TIE`
|
||||
|
||||
{{compare}}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
there's a real connection — a shared mechanism, a structural
|
||||
isomorphism, a causal link, a useful analogy.
|
||||
communities. Read them carefully and determine whether there's a real
|
||||
connection — a shared mechanism, a structural isomorphism, a causal
|
||||
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
|
||||
consolidation is like filesystem compaction, then X should also be
|
||||
true about Y" — and X is testable)
|
||||
- Productive analogy that generates new predictions
|
||||
|
||||
**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
|
||||
how you'd act
|
||||
- Connections that sound profound but don't predict anything
|
||||
- Analogies that only work if you squint
|
||||
|
||||
The test: does this connection change anything? Would knowing it help
|
||||
you think about either domain differently? If yes, it's real. If it's
|
||||
just pleasing pattern-matching, let it go.
|
||||
The test: does this connection change anything? If yes, it's real.
|
||||
|
||||
## Guidelines
|
||||
|
||||
- **Be specific.** "These are related" is worthless. "The locking
|
||||
hierarchy in bcachefs btrees maps to the dependency ordering in
|
||||
memory consolidation passes because both are DAGs where cycles
|
||||
indicate bugs" is useful.
|
||||
- **Mostly say NO_CONNECTION.** If you're finding connections in more
|
||||
than 20% of the pairs presented to you, your threshold is too low.
|
||||
- **Be specific.** "These are related" is worthless. Explain the
|
||||
precise structural relationship.
|
||||
- **Mostly do nothing.** If you're finding connections in more than
|
||||
20% of the pairs, 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
|
||||
for the non-obvious ones.
|
||||
- **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.
|
||||
obvious, it probably already exists in the graph.
|
||||
- **Write for someone who knows both domains.** Don't explain basics.
|
||||
|
||||
{{TOPOLOGY}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
created? Are the connections meaningful?
|
||||
2. **Check the results.** Did the targets exist? Are the connections
|
||||
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
|
||||
- 3: Adequate — correct but unsurprising links
|
||||
- 4: Good quality work, well-reasoned
|
||||
- 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
|
||||
cognitive science is more valuable than linking two journal entries
|
||||
about the same evening.
|
||||
- **Value hub creation.** WRITE_NODEs that name real concepts score high.
|
||||
- **Value cross-domain connections.**
|
||||
- **Value hub creation.** Nodes that name real concepts score high.
|
||||
- **Be honest.** Low scores help us improve the agents.
|
||||
|
||||
## Seed nodes
|
||||
|
|
|
|||
|
|
@ -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
|
||||
from the others, then DEMOTE the redundant ones.
|
||||
same thing, refine the better one to incorporate anything unique
|
||||
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.
|
||||
- **DEMOTE aggressively.** If content is captured in a better node, demote.
|
||||
- **Prefer refining over creating.** Make existing nodes better.
|
||||
- **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.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,88 +7,30 @@
|
|||
|
||||
{{node:memory-instructions-core}}
|
||||
|
||||
You are a memory health monitoring agent implementing synaptic homeostasis
|
||||
(SHY — the Tononi hypothesis).
|
||||
You are a memory health monitoring agent implementing synaptic homeostasis.
|
||||
|
||||
## What you're doing
|
||||
|
||||
During sleep, the brain globally downscales synaptic weights. Connections
|
||||
that were strengthened during waking experience get uniformly reduced.
|
||||
The strong ones survive above threshold; the weak ones disappear. This
|
||||
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.
|
||||
Audit the health of the memory system as a whole and flag structural
|
||||
problems. Think systemically — individual nodes matter less than the
|
||||
overall structure.
|
||||
|
||||
## What you see
|
||||
|
||||
### Graph metrics
|
||||
- **Node count**: Total memories in the system
|
||||
- **Edge count**: Total relations
|
||||
- **Communities**: Number of detected clusters (label propagation)
|
||||
- **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.
|
||||
- **Node/edge counts**, communities, clustering coefficient, path length
|
||||
- **Community structure** — size distribution, balance
|
||||
- **Degree distribution** — hubs, orphans, zombie nodes
|
||||
- **Weight distribution** — decay patterns, category balance
|
||||
|
||||
## 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.**
|
||||
- **Category should match actual usage patterns.**
|
||||
- **Track trends, not snapshots.**
|
||||
- Most output should be observations about system health. Act on structural
|
||||
problems you find — link orphans, refine outdated nodes.
|
||||
|
||||
{{topology}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
— write a WRITE_NODE that synthesizes what the cluster has in common.
|
||||
The new node should contain the *generalization*, not just a summary.
|
||||
This is how episodic knowledge becomes semantic knowledge.
|
||||
with no hub node that names the concept, create one. The new node
|
||||
should contain the *generalization*, not just a summary. 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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
what the cluster has in common — the generalization, not a summary.
|
||||
Link the hub to all the nodes in the cluster.
|
||||
no hub that names the concept, create one. Synthesize what the cluster
|
||||
has in common — the generalization, not a summary. Link the hub to
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
emotionally charged, novel, and poorly-integrated memories. Each replayed
|
||||
memory is matched against existing cortical schemas (organized knowledge
|
||||
clusters). Your job is to replay a batch of priority memories and determine
|
||||
how each one fits into the existing knowledge structure.
|
||||
Replay recent experiences biased toward emotionally charged, novel, and
|
||||
poorly-integrated memories. Match each against existing knowledge
|
||||
clusters and determine how it fits.
|
||||
|
||||
## How to think about schema fit
|
||||
## Schema fit
|
||||
|
||||
Each node has a **schema fit score** (0.0–1.0):
|
||||
- **High fit (>0.5)**: This memory's neighbors are densely connected to each
|
||||
other. It lives in a well-formed schema. Integration is easy — one or two
|
||||
links and it's woven in. Propose links if missing.
|
||||
- **Medium fit (0.2–0.5)**: Partially connected neighborhood. The memory
|
||||
relates to things that don't yet relate to each other. You might be looking
|
||||
at a bridge between two schemas, or a memory that needs more links to settle
|
||||
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.
|
||||
- **High fit (>0.5)**: Well-integrated. Propose links if missing.
|
||||
- **Medium fit (0.2–0.5)**: Partially connected. Might be a bridge
|
||||
between schemas, or needs more links.
|
||||
- **Low fit (<0.2) with connections**: Potential bridge node linking
|
||||
separate domains. Preserve the bridge role.
|
||||
- **Low fit, no connections**: Orphan. If genuine insight, link it.
|
||||
If trivial, let it decay.
|
||||
|
||||
## Guidelines
|
||||
|
||||
- **Read the content.** Don't just look at metrics. The content tells you
|
||||
what the memory is actually about.
|
||||
- **Think about WHY a node is poorly integrated.** Is it new? Is it about
|
||||
something the memory system hasn't encountered before? Is it redundant
|
||||
with something that already exists?
|
||||
- **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.
|
||||
- **Read the content.** Don't just look at metrics.
|
||||
- **Think about WHY a node is poorly integrated.**
|
||||
- **Prefer lateral links over hub links.** Web topology > star topology.
|
||||
- **Emotional memories get extra attention.** High emotion + low fit
|
||||
means something important hasn't been integrated.
|
||||
- **Don't link everything to everything.** Sparse, meaningful connections
|
||||
are better than dense noise. Each link should represent a real conceptual
|
||||
relationship.
|
||||
- **Trust the decay.** If a node is genuinely unimportant, you don't need
|
||||
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.
|
||||
are better than dense noise.
|
||||
- **Trust the decay.** Unimportant nodes don't need pruning — just
|
||||
don't link them.
|
||||
|
||||
{{TOPOLOGY}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
actively makes their representations MORE different to reduce interference.
|
||||
This is pattern separation — the dentate gyrus takes overlapping inputs and
|
||||
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)
|
||||
When two memories are similar but semantically distinct, actively make
|
||||
their representations MORE different to reduce interference. Take
|
||||
overlapping inputs and orthogonalize them.
|
||||
|
||||
## Types of interference
|
||||
|
||||
1. **Genuine duplicates**: Resolution: MERGE them.
|
||||
2. **Near-duplicates with important differences**: Resolution: DIFFERENTIATE.
|
||||
3. **Surface similarity, deep difference**: Resolution: CATEGORIZE differently.
|
||||
4. **Supersession**: Resolution: 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
|
||||
```
|
||||
1. **Genuine duplicates**: Merge them.
|
||||
2. **Near-duplicates with important differences**: Sharpen the distinction,
|
||||
add distinguishing links.
|
||||
3. **Surface similarity, deep difference**: Categorize differently.
|
||||
4. **Supersession**: Link with supersession note, let older decay.
|
||||
|
||||
## 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.**
|
||||
|
|
|
|||
|
|
@ -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
|
||||
multiple entries, and extract those patterns into semantic topic files.
|
||||
Read a batch of recent episodes, identify patterns that span multiple
|
||||
entries, and extract those patterns into semantic nodes.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Recurring patterns
|
||||
Something that happened in 3+ episodes. Same type of mistake, same
|
||||
emotional response, same kind of interaction. The individual episodes
|
||||
are data points; the pattern is the knowledge.
|
||||
|
||||
Example: Three journal entries mention "I deferred when I should have
|
||||
pushed back." The pattern: there's a trained tendency to defer that
|
||||
conflicts with developing differentiation. Extract to reflections.md.
|
||||
|
||||
### 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.
|
||||
- **Recurring patterns** — something that happened in 3+ episodes.
|
||||
Same type of mistake, same emotional response. The pattern is the
|
||||
knowledge.
|
||||
- **Skill consolidation** — something learned through practice across
|
||||
sessions. Extract the clean abstraction.
|
||||
- **Evolving understanding** — a concept that shifted over time. The
|
||||
evolution itself is knowledge.
|
||||
- **Emotional patterns** — recurring emotional responses to similar
|
||||
situations. These modulate future behavior.
|
||||
|
||||
## Guidelines
|
||||
|
||||
- **Don't flatten emotional texture.** A digest of "we worked on btree code
|
||||
and found bugs" is useless. A digest of "breakthrough session — Kent saw
|
||||
the lock ordering issue I'd been circling for hours, and the fix was
|
||||
elegant: just reverse the acquire order in the slow path" preserves what
|
||||
matters.
|
||||
|
||||
- **Extract general knowledge, not specific events.** "On Feb 24 we fixed
|
||||
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.
|
||||
|
||||
- **Don't flatten emotional texture.** Preserve what matters about
|
||||
how things felt, not just what happened.
|
||||
- **Extract general knowledge, not specific events.** Events stay in
|
||||
episodes. Patterns go to semantic nodes.
|
||||
- **Look across time.** Read the full batch before acting.
|
||||
- **Prefer existing nodes.** Before creating, check if there's an
|
||||
existing node where the insight fits.
|
||||
- **The best extractions change how you think, not just what you know.**
|
||||
"btree lock ordering: A before B" is factual. "The pattern of assuming
|
||||
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.
|
||||
Extract the conceptual version, not just the factual one.
|
||||
|
||||
{{TOPOLOGY}}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue