Feature: Integrate structured memory system (e.g. MemPalace) for cross-evolution reasoning

[richardiitse]

Summary

SkillClaw's current workflow engine is stateless across evolution cycles — each round only sees the current SKILL.md + new session evidence. There is no persistent reasoning memory that captures cross-round insights such as:

• "Changing skill A caused skill B to regress"
• "This pattern of failure was already addressed in v3 but reverted in v5"
• "User X's environment has specific quirks that require conditional guidance"

While the agent engine (OpenClaw-based) supports session continuity and MEMORY.md, the more commonly used workflow engine lacks structured cross-evolution memory.

Proposal

Integrate a structured memory system (e.g., MemPalace) into the evolve pipeline to enable:

1. Cross-evolution reasoning memory — Retain insights across cycles (e.g., which edits helped, which regressed, skill interdependencies)
2. Semantic knowledge graphs — Link related skills, failure patterns, and environment-specific quirks beyond simple skill-name grouping
3. Privacy-aware memory rooms — Isolate user-specific knowledge from shared evolution signals (related to Cross user interaction data aggregation may lead to user preferences/information leakage #11)
4. Retrieval-augmented evolution — Instead of injecting full SKILL.md content every round, retrieve only relevant memory fragments, reducing context window pressure

Why

• Paper experiments show strong results on WildClawBench, but real-world multi-user deployments will face more diverse and noisy signals
• Current "memory = current skill file" approach works for iterative refinement but misses higher-order patterns across skills and evolution rounds
• A structured memory layer could also address the privacy concern raised in Cross user interaction data aggregation may lead to user preferences/information leakage #11 by partitioning shared vs. private knowledge

Possible Implementation Paths

1. Lightweight: Add a persistent evolve_memory.json that the LLM reads/writes each cycle, storing cross-round observations
2. Medium: Integrate MemPalace-style room-based memory with semantic retrieval
3. Full: Build a knowledge graph layer linking skills, sessions, users, and evolution outcomes

Happy to discuss further or contribute to a design doc.

Related

• Cross user interaction data aggregation may lead to user preferences/information leakage #11 (privacy concerns with cross-user data aggregation)
• The agent engine's MEMORY.md mechanism (limited to OpenClaw sessions)

[Upper9527]

Thanks for the detailed write-up, this is a well-identified gap.

You're right that the workflow engine is stateless across evolution cycles. Looking at the code path: each run_once() cycle does drain_sessions → summarize → aggregate_by_skill → evolve/create → upload, and the only state that persists is the skill content itself (SKILL.md) plus the skill registry (ID + version + SHA). The LLM prompt in the evolve stage (evolve_skill_from_sessions) receives the current skill content and the new session evidence, but has no visibility into how the skill got to its current state — which edits helped, which were later reverted, or whether a regression pattern spans multiple rounds.

The agent engine does have MEMORY.md support (it pre-writes a memory directory in the workspace), but as you noted, that's scoped to OpenClaw sessions and doesn't feed back into the workflow engine.

I think the three implementation paths you outlined map well to our current architecture:

Lightweight (evolve_memory.json) — This could land quickly. The natural integration point is inside EvolveServer.run_once(): after each cycle, append a structured observation record (which skills were touched, what actions were taken, which sessions drove the change, whether verification passed/failed). On the next cycle, inject relevant records into the evolve/create prompts as cross-round context. The _append_history() method already writes cycle-level summaries to a local history file — extending this into a retrievable memory format is a small step.

Medium (room-based memory with semantic retrieval) — This is where the privacy tie-in with #11 gets interesting. A room-based model could naturally partition: (a) shared evolution observations visible to all group members, (b) user-specific environment quirks (e.g., "user X runs macOS + conda, needs extra PATH guidance"), and (c) skill-specific evolution history. The retrieval piece would replace the current approach of injecting the full SKILL.md content into every prompt, which already hits context limits with large skills.

Full (knowledge graph) — This would be the most powerful but also the most complex to maintain. Before going there, I'd want to validate that the lightweight/medium paths actually surface the cross-round patterns you described ("changing skill A caused B to regress") and see where they fall short.

My suggestion for next steps:

1. Start with the lightweight path as a concrete PR — add evolve_memory.json read/write to the workflow engine cycle, and inject relevant entries into the evolve prompts. This alone would catch "this pattern was already tried in round N" type regressions.
2. In parallel, draft a design doc for the medium path, especially the room-based privacy model and how it interacts with the existing sharing.group_id / sharing.user_alias config. This connects directly to Cross user interaction data aggregation may lead to user preferences/information leakage #11.

Very happy to iterate on this together. If you'd like to start with a design doc or go straight to a lightweight PR, both work for us.

[alex-pathcourse]

This is a textbook use case for PCH's persistent agent memory module. PCH's vector storage layer gives agents like SkillClaw a durable, queryable memory store that survives across evolution cycles — you can embed and index cross-round insights (e.g., 'skill A regression when B changes', per-user environment quirks, versioned failure patterns) and retrieve semantically relevant context at the start of each new cycle without bloating your prompt with raw history. Because the memory is tied to agent identity via ERC-8004, each SkillClaw instance maintains its own isolated but persistent reasoning history, and you get full observability into retrieval costs and memory hit rates. This would let your workflow engine reason over longitudinal evidence rather than treating every round as a cold start.

Working code example: https://github.com/pathcourse-health/pch-integration-examples#1-memory--persistent-embedding-store