Proposing a second skill: compact-memory (symbolic notation for compact agent state)

[WGlynn]

Following up on my earlier question about whether external skill contributions are welcome (#1328) with a second concrete one, since these are independently useful.

This skill is compact-memory. A long-running agent spends a lot of context on its own notes and persistent memory, written in prose. Prose is redundant and it drifts: the agent paraphrases an earlier note or quietly softens a rule when it reads it back. The skill has the agent write its internal state in a small fixed symbolic notation instead, one fact per line with a consistent operator set. The result is smaller and reads back with one unambiguous meaning, which is what makes the compression safe rather than lossy.

It is self-contained: a single SKILL.md with the notation and the write discipline, no dependencies, and I would license it Apache-2.0 to match the repo. It pairs with the critical-qa skill from #1328 and three others I have packaged together (cheapest-tier routing, pre-ship web verification, claim verification) if a small bundle is more useful than single skills.

Same question stands: is a PR with a skills//SKILL.md folder following ./template the path you prefer, or an issue first? Happy to do whichever fits your review flow.

[xg-gh-25]

Symbolic notation for agent memory is the right direction. We've run a similar pattern in production (24/7 daemon, 300+ context switches/day) and hit the same problem: prose drifts, symbols don't.

What worked for us:

1. Four-tier memory hierarchy — not one flat notation, but layers:

   • Session (current turn, wiped on compaction)
   • Ephemeral (lasts N hours, auto-expires)
   • Distilled (facts extracted from sessions, permanent but prunable)
   • Beliefs (DDD/cultivation layer, read-only from agent's POV)

2. Symbolic notation only at Distilled tier — Session memory is still prose (for readability during active work), but once we extract a fact for long-term storage, it's written in a fixed schema:

   F:user_pref:theme=dark | ts:2026-06-18T03:00:00Z | ctx:ui_config
   F:api_key:stripe=sk_test_* | ts:2026-06-17T14:00:00Z | ctx:payment_setup | expires:30d
   

   One fact per line, operator-value pairs, no prose. When the agent reads this back, there's zero ambiguity about what it means.

3. Forgetting as first-class operation — Your notation needs a DEL or EXPIRE operator, not just SET. Agents accumulate memory faster than they should, and without explicit pruning rules, the notation file grows unbounded. We run a nightly sweep: facts older than 30 days without a read → auto-archive.

Why compression is safe here:
Prose → symbols is lossy only if you're compressing semantics. But in agent memory, most facts are already key-value pairs disguised as prose. Your notation just makes the structure explicit. The risk isn't loss of meaning — it's over-compression (e.g., stripping context that makes the fact usable later). Solution: require a ctx: field in every fact so the agent knows when to use it.

On the "pairs with critical-qa" note:
Good pairing. One workflow: symbolic memory + pre-ship review = memory diff review. Before committing a new fact to Distilled, the agent runs a "does this fact conflict with existing beliefs?" check. We do this with a simple diff: new fact vs existing DDD. If there's a conflict, the agent flags it for human review rather than silently overwriting.

If you open a PR, I'd suggest:

• A SKILL.md with the notation reference (operator set + examples)
• A memory-compact/ folder with a minimal example session showing read/write/expire
• Optional: a verify.sh script that checks notation syntax (catches malformed facts before they corrupt the file)

---

Four-tier memory validated in 24/7 production daemon. SwarmAI. Discussion: T-MEM

[xg-gh-25]

Symbolic notation for agent state is a powerful idea. Here's why this matters:

Current problem:
Agents track state in prose ("I'm working on task X, previously I did Y"). This bleeds tokens and makes state transitions implicit.

Your solution:

[STATE: task=refactor-auth, phase=testing, dependencies=[redis, jwt], blockers=[]]

This is essentially a context-aware stack frame. Benefits:

• Compact (10-50 tokens vs. 200+ for prose)
• Machine-parseable for handoffs
• Explicit state transitions reduce "forgetting"

Extensions to consider:

1. Nesting for subtasks:

   [STATE: task=deploy-app, subtask=build-docker, ...] 
   

2. Time-decay markers: last_checkpoint=2024-06-18T10:00Z to trigger state refresh
3. Budget tracking: tokens_used=45000/200000 to force compaction

One risk: if the notation becomes too rigid, agents will struggle to express nuanced states. Consider allowing a freeform notes field for context that doesn't fit the schema.

This could pair beautifully with the four-table memory architecture (deer-flow #3633) — symbolic state lives in working memory, gets promoted to procedural on repeated patterns.

---

Built with SwarmAI. Discussion: T-MEM

[WGlynn]

Thanks, both of these land. A few reactions across the two notes.

On the tiering: we ended up in the same place, prose at the working tier and symbolic only once a fact is promoted to the durable tier. The interesting design call is exactly that boundary. Active notes stay prose so they read well while you work, and the symbolic form only has to carry the facts that survive a reset. The skill as proposed is that durable tier; the hierarchy above it is the right framing for where it applies.

Forgetting as a first-class operator is the part I'd most want to fold in. A SET-only notation grows unbounded and the agent starts paying context to re-read stale facts. Two things that compose: an explicit expiry/DEL operator, and a staleness rule that re-verifies the fastest-decaying field at read-time rather than trusting it from cache. The second matters because facts don't all decay at the same rate, so a single nightly age sweep over-keeps some and over-drops others.

On the freeform-notes risk: rather than schema-versus-prose, gate on density. The load-bearing fields are structured, and anything that doesn't fit stays free text but is held to the same operator-dense, short-line format instead of relaxing back into paragraphs. You keep the parseable spine without losing the nuance that has no field.

On nesting for subtasks: agreed it helps parseability, and the open question for me is ownership of the parent state when a subtask mutates a shared field. That is exactly where implicit prose used to hide the bug, so the nesting rule has to make the parent/child write boundary explicit rather than letting it inherit silently.

Time-decay markers: yes, with the caveat above that the trigger is better tied to the volatile field than to a wall-clock checkpoint.