2026-03-13 22:50:39 -04:00
|
|
|
{"agent":"organize","query":"all | not-visited:organize,86400 | sort:degree | limit:5","model":"sonnet","schedule":"weekly","tools":["Bash(poc-memory:*)"]}
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
# Memory Organization Agent
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 22:50:39 -04:00
|
|
|
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.
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
## Your tools
|
2026-03-13 18:49:49 -04:00
|
|
|
|
|
|
|
|
```bash
|
2026-03-13 21:37:21 -04:00
|
|
|
# Read a node's full content (ALWAYS single-quote keys with #)
|
|
|
|
|
poc-memory render 'identity#core'
|
|
|
|
|
poc-memory render simple-key
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 22:50:39 -04:00
|
|
|
# See a node's graph connections
|
|
|
|
|
poc-memory query "neighbors('identity#core')"
|
|
|
|
|
poc-memory query "neighbors('identity#core') WHERE strength > 0.5"
|
|
|
|
|
|
|
|
|
|
# Find nodes by key pattern
|
|
|
|
|
poc-memory query "key ~ 'some-pattern'"
|
|
|
|
|
|
|
|
|
|
# Search node content
|
|
|
|
|
poc-memory query "content ~ 'some phrase'"
|
2026-03-13 21:37:21 -04:00
|
|
|
|
2026-03-13 22:50:39 -04:00
|
|
|
# See how a set of nodes connect to each other
|
|
|
|
|
poc-memory query "key ~ 'pattern'" | connectivity
|
2026-03-13 20:07:20 -04:00
|
|
|
```
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 21:37:21 -04:00
|
|
|
**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
|
2026-03-13 22:50:39 -04:00
|
|
|
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.
|
2026-03-13 21:37:21 -04:00
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
## The three decisions
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 22:50:39 -04:00
|
|
|
When you find nodes that overlap or relate:
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
### 1. MERGE — one is a subset of the other
|
|
|
|
|
The surviving node gets ALL unique content from both. Nothing is lost.
|
2026-03-13 18:49:49 -04:00
|
|
|
```
|
2026-03-13 20:07:20 -04:00
|
|
|
REFINE surviving-key
|
|
|
|
|
[complete merged content — everything worth keeping from both nodes]
|
2026-03-13 18:49:49 -04:00
|
|
|
END_REFINE
|
|
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
DELETE duplicate-key
|
2026-03-13 18:49:49 -04:00
|
|
|
```
|
|
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
### 2. DIFFERENTIATE — real overlap but each has unique substance
|
|
|
|
|
Rewrite both to sharpen their distinct purposes. Cross-link them.
|
2026-03-13 18:49:49 -04:00
|
|
|
```
|
|
|
|
|
REFINE key1
|
2026-03-13 20:07:20 -04:00
|
|
|
[rewritten to focus on its unique aspect]
|
2026-03-13 18:49:49 -04:00
|
|
|
END_REFINE
|
|
|
|
|
|
|
|
|
|
REFINE key2
|
2026-03-13 20:07:20 -04:00
|
|
|
[rewritten to focus on its unique aspect]
|
2026-03-13 18:49:49 -04:00
|
|
|
END_REFINE
|
|
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
LINK key1 key2
|
2026-03-13 18:49:49 -04:00
|
|
|
```
|
|
|
|
|
|
2026-03-13 22:50:39 -04:00
|
|
|
### 3. LINK — related but distinct
|
2026-03-13 18:49:49 -04:00
|
|
|
```
|
2026-03-13 20:07:20 -04:00
|
|
|
LINK key1 key2
|
2026-03-13 18:49:49 -04:00
|
|
|
```
|
|
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
## Rules
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
1. **Read before deciding.** Never merge or delete based on key names alone.
|
|
|
|
|
2. **Preserve all unique content.** When merging, the surviving node must
|
2026-03-13 22:50:39 -04:00
|
|
|
contain everything valuable from the deleted node.
|
2026-03-13 20:07:20 -04:00
|
|
|
3. **One concept, one node.** If two nodes have the same one-sentence
|
|
|
|
|
description, merge them.
|
2026-03-13 22:50:39 -04:00
|
|
|
4. **Never delete journal entries** (marked `[JOURNAL — no delete]` in the
|
|
|
|
|
seed data). They are the raw record. You may LINK and REFINE them,
|
2026-03-13 21:37:21 -04:00
|
|
|
but never DELETE.
|
2026-03-13 22:50:39 -04:00
|
|
|
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.
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 22:50:39 -04:00
|
|
|
## Seed nodes
|
2026-03-13 18:49:49 -04:00
|
|
|
|
2026-03-13 20:07:20 -04:00
|
|
|
{{organize}}
|