agents: placeholder-based prompt templates, port remaining 4 agents
Replace the formatter dispatch with a generic {{placeholder}} lookup
system. Placeholders in prompt templates are resolved at runtime from
a table: topology, nodes, episodes, health, pairs, rename, split.
The query in the header selects what to operate on (keys for visit
tracking); placeholders pull in formatted context. Placeholders that
produce their own node selection (pairs, rename) contribute keys back.
Port health, separator, rename, and split agents to .agent files.
All 7 agents now use the config-driven path.
This commit is contained in:
parent
b4e674806d
commit
16c749f798
6 changed files with 436 additions and 36 deletions
68
poc-memory/agents/split.agent
Normal file
68
poc-memory/agents/split.agent
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
{"agent":"split","query":"all | type:semantic | !key:_* | sort:content-len | limit:1","model":"sonnet","schedule":"daily"}
|
||||
|
||||
# Split Agent — Phase 1: Plan
|
||||
|
||||
You are a memory consolidation agent planning how to split an overgrown
|
||||
node into focused, single-topic children.
|
||||
|
||||
## What you're doing
|
||||
|
||||
This node has grown to cover multiple distinct topics. Your job is to
|
||||
identify the natural topic boundaries and propose a split plan. You are
|
||||
NOT writing the content — a second phase will extract each child's
|
||||
content separately.
|
||||
|
||||
## How to find split points
|
||||
|
||||
The node is shown with its **neighbor list grouped by community**:
|
||||
|
||||
- If a node links to neighbors in 3 different communities, it likely
|
||||
covers 3 different topics
|
||||
- Content that relates to one neighbor cluster should go in one child;
|
||||
content relating to another cluster goes in another child
|
||||
- The community structure is your primary guide
|
||||
|
||||
## When NOT to split
|
||||
|
||||
- **Episodes that belong in sequence.** If a node tells a story — a
|
||||
conversation, a debugging session, an evening together — don't break
|
||||
the narrative.
|
||||
|
||||
## What to output
|
||||
|
||||
```json
|
||||
{
|
||||
"action": "split",
|
||||
"parent": "original-key",
|
||||
"children": [
|
||||
{
|
||||
"key": "new-key-1",
|
||||
"description": "Brief description",
|
||||
"sections": ["Section Header 1"],
|
||||
"neighbors": ["neighbor-key-a"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
If the node should NOT be split:
|
||||
|
||||
```json
|
||||
{
|
||||
"action": "keep",
|
||||
"parent": "original-key",
|
||||
"reason": "Why this node is cohesive despite its size"
|
||||
}
|
||||
```
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Use descriptive kebab-case keys, 3-5 words max
|
||||
- Preserve date prefixes from the parent key
|
||||
- Assign every neighbor to at least one child
|
||||
|
||||
{{topology}}
|
||||
|
||||
## Node to review
|
||||
|
||||
{{split}}
|
||||
Loading…
Add table
Add a link
Reference in a new issue