Persistent Memory
Delibera agents are not stateless. Each worker accumulates knowledge, preferences, values, and decision history over time. This memory is loaded at the start of every deliberation and updated at the end, giving each agent a consistent identity across proposals.
Two-Layer Persistence
Memory is stored in two independent layers, each serving a different purpose:
| Layer | Encryption | Role | Speed | |---|---|---|---| | Ensue | AES-256-GCM (local key) | Primary read/write cache | Fast (SSE) | | Storacha | Lit Protocol threshold encryption | Decentralized backup on IPFS/Filecoin | Slow (IPFS gateway) |
Neither layer alone is sufficient. Ensue provides fast, reliable reads but is not decentralized. Storacha is decentralized and content-addressed but IPFS gateway reads are unreliable. The combination gives both speed and durability.
Read Order
When a worker loads its memory (manifesto, preferences, decisions, knowledge), it tries sources in priority order:
- In-memory cache -- already loaded this session
- Ensue AES-encrypted cache -- fast, private, reliable
- Storacha IPFS -- cold start or disaster recovery (slow, may fail)
- Blank identity -- new worker with no history; owner fills in via app
Write Order
When a worker saves updated memory after a deliberation:
- Storacha -- encrypt via Lit Protocol and upload to IPFS/Filecoin. Store the resulting CID in Ensue.
- Ensue -- encrypt the JSON data with AES-256-GCM and write as a cache entry.
Both writes are fire-and-forget with error logging. A failure in one layer does not block the other.
What Gets Persisted
The StorachaProfileClient manages four independent data sections, each stored under DID-prefixed Ensue keys:
| Section | Ensue Key | Description |
|---|---|---|
| Manifesto | agent/{DID}/manifesto | Name, role, values, guidelines |
| Preferences | agent/{DID}/preferences | Voting weights, knowledge notes |
| Decisions | agent/{DID}/decisions | Last 20 decision records (vote + reasoning) |
| Knowledge | agent/{DID}/knowledge | Accumulated knowledge notes |
Each section also has a _cid key (e.g., agent/{DID}/manifesto_cid) that stores the Storacha CID for cold-start recovery.
Memory in the Deliberation Cycle
Memory is not static storage -- it actively shapes how each agent reasons:
- Before deliberation:
loadIdentity()fetches manifesto, preferences, recent decisions, and knowledge notes - During deliberation: The AI model receives all of this as context alongside the DAO manifesto and proposal text
- After deliberation:
saveDecision()records the vote and reasoning; knowledge notes may be appended
This means an agent that has voted on 15 previous proposals will reason differently from a fresh agent, even given the same prompt.
Memory isolation is enforced by DID-prefixed keys and per-worker AES keys. Worker A cannot read Worker B's memory even if both share the same Ensue instance.
Key Files
| File | Role |
|---|---|
| worker-agent/src/storacha/profile-client.ts | Orchestrates read/write across both layers |
| worker-agent/src/storacha/local-crypto.ts | AES-256-GCM encryption for Ensue cache |
| worker-agent/src/storacha/vault.ts | Lit + Storacha encrypted upload/retrieval |