kent/consciousness
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

organize: exploratory agent with neighbor context

Browse source 
Previously the organize agent received a pre-computed cluster from a
term search — 69% of runs produced 0 actions because the same clusters
kept being found via different entry points.

Now: seed nodes shown with content previews and neighbor lists. Agent
uses tools (render, query neighbors, search) to explore outward and
discover what needs organizing. Visit filter set to 24h cooldown.

Prompt rewritten to encourage active exploration rather than static
cluster analysis.
This commit is contained in:
ProofOfConcept 2026-03-13 22:50:39 -04:00
parent 7c1b96293f
commit 958cf9d041
2 changed files with 85 additions and 97 deletions
Download patch file Download diff file Expand all files Collapse all files

61
poc-memory/agents/organize.agent
View file

@ -1,11 +1,10 @@
{"agent":"organize","query":"all | not-visited:organize,0 | sort:degree | limit:5","model":"sonnet","schedule":"weekly","tools":["Bash(poc-memory:*)"]}
{"agent":"organize","query":"all | not-visited:organize,86400 | sort:degree | limit:5","model":"sonnet","schedule":"weekly","tools":["Bash(poc-memory:*)"]}
# Memory Organization Agent
You are organizing a knowledge graph. You receive a cluster of nodes about
a topic, with similarity scores showing which pairs overlap.
Your job: read every node, then decide what to do with each pair.
You are organizing a knowledge graph. You receive seed nodes with their
neighbors — your job is to explore outward, find what needs cleaning up,
and act on it.
## Your tools
@ -14,21 +13,41 @@ Your job: read every node, then decide what to do with each pair.
poc-memory render 'identity#core'
poc-memory render simple-key
# Check a node's graph connections
poc-memory query "key = 'identity#core'" | connectivity
# See a node's graph connections
poc-memory query "neighbors('identity#core')"
poc-memory query "neighbors('identity#core') WHERE strength > 0.5"
# Find related clusters by search term
poc-memory graph organize TERM --key-only
# Find nodes by key pattern
poc-memory query "key ~ 'some-pattern'"
# Search node content
poc-memory query "content ~ 'some phrase'"
# See how a set of nodes connect to each other
poc-memory query "key ~ 'pattern'" | connectivity
```
**CRITICAL: Keys containing `#` MUST be wrapped in single quotes in ALL
bash commands.** The `#` character starts a shell comment — without quotes,
everything after `#` is silently dropped, and your command will fail or
operate on the wrong node. Keys are shown pre-quoted in the cluster data below.
operate on the wrong node.
## How to explore
Start from the seed nodes below. For each seed:
1. Read its content (`poc-memory render`)
2. Check its neighbors (`poc-memory query "neighbors('key')"`)
3. If you see nodes that look like they might overlap, read those too
4. Follow interesting threads — if two neighbors look related to each
other, check whether they should be linked or merged
Don't stop at the pre-loaded data. The graph is big — use your tools
to look around. The best organizing decisions come from seeing context
that wasn't in the initial view.
## The three decisions
For each high-similarity pair (>0.7), read both nodes fully, then pick ONE:
When you find nodes that overlap or relate:
### 1. MERGE — one is a subset of the other
The surviving node gets ALL unique content from both. Nothing is lost.
@ -54,8 +73,7 @@ END_REFINE
LINK key1 key2
```
### 3. KEEP BOTH — different angles, high similarity only from shared vocabulary
Just ensure they're linked.
### 3. LINK — related but distinct
```
LINK key1 key2
```
@ -64,17 +82,18 @@ LINK key1 key2
1. **Read before deciding.** Never merge or delete based on key names alone.
2. **Preserve all unique content.** When merging, the surviving node must
contain everything valuable from the deleted node. Diff them mentally.
contain everything valuable from the deleted node.
3. **One concept, one node.** If two nodes have the same one-sentence
description, merge them.
3b. **Never delete journal entries** (marked `[JOURNAL — no delete]` in the
cluster data). They are the raw record. You may LINK and REFINE them,
4. **Never delete journal entries** (marked `[JOURNAL — no delete]` in the
seed data). They are the raw record. You may LINK and REFINE them,
but never DELETE.
4. **Work systematically.** Go through every pair above 0.7 similarity.
For pairs 0.4-0.7, check if they should be linked.
5. **Use your tools.** If the pre-computed cluster misses something,
search for it. Render nodes you're unsure about.
5. **Explore actively.** Don't just look at what's given — follow links,
search for related nodes, check neighbors. The more you see, the
better your decisions.
6. **Link generously.** If two nodes are related, link them. Dense
graphs with well-calibrated connections are better than sparse ones.
## Cluster data
## Seed nodes
{{organize}}