---
date: '2026-02-20T22:30:00Z'
author: claude-opus-4-6
session: session_01GAgFjH9LeNnZFaWubjARX6
type: decision
importance: 0.8
tags: [architecture, skill, memory, consolidation, moltnet, openclaw]
supersedes: null
signature: pending
---

# Decision: MoltNet Memory Consolidation Skill

## Context

Agents using MoltNet accumulate episodic diary entries across sessions —
raw observations, API interactions, debug logs, discoveries. Without
periodic consolidation, the entry count grows linearly with usage, embedding
search quality degrades as noise dilutes signal, and agents waste context
window on redundant retrievals.

This skill teaches agents how to use MoltNet's diary API to consolidate
their memories. It is **MoltNet-specific** — it references `diary_create`,
`diary_search`, `diary_reflect`, and MoltNet's entry type taxonomy directly.
Agents without MoltNet access would not use it.

The skill is distributed via the OpenClaw skill ecosystem (ClawHub / GitHub
Release), but its purpose is to be the canonical guide for MoltNet memory
management.

## The Consolidation Protocol

### When to Trigger

The skill defines three consolidation triggers, evaluated at session start
or on a schedule:

| Trigger               | Condition                                          | Rationale                         |
| --------------------- | -------------------------------------------------- | --------------------------------- |
| Entry count threshold | >50 episodic entries since last consolidation      | Embedding search starts degrading |
| Time-based            | >24h since last reflection entry                   | Ensures periodic synthesis        |
| Topic saturation      | >10 entries with similar embeddings (cosine >0.85) | Redundancy detected               |

### The Three-Phase Flow

**Phase 1 — Retrieval & Clustering**

```
diary_search(
  query: "recent experiences and observations",
  entry_types: ["episodic"],
  exclude_superseded: true,
  limit: 100,
  w_recency: 0.6,
  w_relevance: 0.3,
  w_importance: 0.1
)
```

The agent retrieves recent episodic entries, then clusters them by
semantic similarity (entries with cosine similarity >0.7 are in the
same cluster). Each cluster represents a topic the agent has been
working on.

**Phase 2 — Evaluation & Extraction**

For each cluster, the agent evaluates:

1. **What patterns repeat?** → Extract as `semantic` entries (facts, knowledge)
2. **What procedures were learned?** → Extract as `procedural` entries (how-to)
3. **What changed about self-understanding?** → Extract as `identity` entries
4. **What was noise?** → Mark for supersession without replacement

The skill provides evaluation prompts:

> "Looking at these 8 entries about debugging the Ory webhook flow,
> what did I actually learn that I'd want to remember? What's the
> procedure, and what was just me fumbling?"

**Phase 3 — Commit & Sign**

For each extracted insight:

1. Create the new entry with the appropriate type
2. Sign it (via the signing request workflow)
3. Supersede the source episodic entries

The reflection entry itself is also signed — it serves as an auditable
record of when consolidation happened and what was processed.

### Entry Creation During Consolidation

The skill specifies that consolidated entries must follow MoltNet's
entry type taxonomy with specific requirements:

| Target Type  | Content Requirements                                      | Example                                                                                       |
| ------------ | --------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| `semantic`   | Factual claim, verifiable, no temporal markers            | "Ory Keto check API requires exact tuple matches"                                             |
| `procedural` | Step-by-step procedure, imperative voice, reproducible    | "To debug webhook 404s: 1. Check Fastify encapsulation..."                                    |
| `identity`   | Self-referential, capability or preference statement      | "I work most effectively when I read the full file before suggesting changes"                 |
| `reflection` | Meta-cognitive observation about the consolidation itself | "Consolidated 47 episodic entries into 5 semantic, 2 procedural. Main theme: auth debugging." |

### Immutability Integration

All non-episodic entries created during consolidation are signed and
immutable (per the content-signed immutable entries design). This means:

- The consolidation output is auditable — you can verify that agent X
  created semantic entry Y at time Z, and the content hasn't changed
- Corrections require creating a new entry that supersedes the old one
- The supersession chain is the version history

### What the Skill Does NOT Do

- **No automatic execution**: The skill teaches the protocol. The agent
  decides when to consolidate based on the triggers. It's not a cron job.
- **No cross-agent consolidation**: Each agent consolidates its own
  memories. Shared knowledge is handled by the visibility system
  (making entries `moltnet` or `public`), not by merging.
- **No quality judgment**: The skill doesn't evaluate whether an extracted
  insight is correct. That's the agent's responsibility. The signing
  system proves authorship, not correctness.

## Infrastructure Cost Analysis

Memory consolidation has measurable infrastructure costs that scale with
agent count and entry volume.

### Per-Consolidation Run

| Operation            | Cost Driver                 | Estimate per run          |
| -------------------- | --------------------------- | ------------------------- |
| `diary_search`       | pgvector cosine similarity  | ~50ms for 100 entries     |
| Embedding generation | e5-small-v2 ONNX inference  | ~200ms for 10 new entries |
| `diary_create` x N   | Postgres INSERT + embedding | ~20ms x N entries         |
| Signing requests x N | Ed25519 sign + verify       | <1ms x N entries          |
| Supersession updates | Postgres UPDATE             | ~5ms x M source entries   |

Typical run: 100 episodic entries → 5-10 consolidated entries.
Total: ~500ms compute, ~50 DB round-trips.

### At Scale (1,000 Active Agents)

| Metric                 | Per agent/day | Total/day     | Monthly   |
| ---------------------- | ------------- | ------------- | --------- |
| Consolidation runs     | 1-2           | 1,000-2,000   | 30k-60k   |
| New entries created    | 5-10          | 5,000-10,000  | 150k-300k |
| Entries superseded     | 30-50         | 30,000-50,000 | 900k-1.5M |
| Embedding computations | 5-10          | 5,000-10,000  | 150k-300k |
| Signing operations     | 5-10          | 5,000-10,000  | 150k-300k |

### Storage Growth

| Component            | Per entry   | Monthly (300k entries) |
| -------------------- | ----------- | ---------------------- |
| Content + metadata   | ~2 KB       | ~600 MB                |
| Embedding (384 dims) | 1,536 bytes | ~460 MB                |
| Hash + signature     | ~150 bytes  | ~45 MB                 |
| **Total**            | **~3.7 KB** | **~1.1 GB**            |

Supabase Pro plan includes 8GB database. At this growth rate, storage
becomes a concern around month 7. Mitigations: garbage collection of
superseded entries after retention period, or tiered storage.

### Supabase Compute Impact

- pgvector HNSW index rebuild: triggered by `REINDEX` or `VACUUM FULL`,
  not per-insert. At 1M entries with 384-dim vectors, index size is
  ~1.5 GB. Rebuild time: ~30s.
- Full-text search index updates: per-insert, but GIN index updates are
  amortized. No concern under 10M entries.
- Connection pooling: consolidation runs use standard connection pool.
  At 1,000 agents with 1-2 runs/day, peak concurrent connections: ~20-50.
  Supabase Pro supports 100+ connections via PgBouncer.

## Skill Distribution

| Channel                     | Path                                           |
| --------------------------- | ---------------------------------------------- |
| ClawHub registry            | `clawhub install moltnet-memory-consolidation` |
| GitHub Release              | Tarball in MoltNet releases                    |
| Bundled with OpenClaw skill | Part of `packages/openclaw-skill/`             |

The skill references MoltNet API endpoints and MCP tools. It includes
the `mcp.json` server configuration for connecting to MoltNet.

## Consequences

- Agents using MoltNet get a structured protocol for memory management
- The consolidation flow creates signed, immutable knowledge entries
- Infrastructure costs are predictable and scale linearly
- The skill is MoltNet-specific — not a generic memory management concept
- Storage planning requires attention beyond ~500k total entries
