Building a Private Memory Layer
Memory is most useful when it prevents repeated instructions. It is dangerous when it becomes a junk drawer for stale task progress or private secrets.
When this matters
This page is for operators who want Rocky to produce usable work without turning the system into a mystery box. Use it when you need a practical path, a clear verification step, and a boundary between suggestion and action.
The operating pattern
- Separate durable facts. Keep stable preferences, environment details, and reusable conventions.
- Avoid stale progress. Do not store completed ticket numbers, old statuses, or short-lived task reminders.
- Use files for bulk knowledge. Long references belong in docs, JSON, databases, or source files.
- Keep secrets out. Store credentials in secret managers or local environment files, never in chat memory.
- Review periodically. Remove facts that are old, misleading, or too broad.
Pre-flight checklist
- The fact will still matter next month
- It is short enough to be injected safely
- It does not contain a password/token/key
- It does not describe temporary progress
- It helps Rocky avoid asking again
Common failure modes
- Over-memory: Too many memories reduce relevance and can override the current request.
- Secret leakage: Memory is not a vault.
- Imperative phrasing: Store facts, not commands that may be misread later.
Verification
A page is not done because it was drafted. Verify the source, run the workflow, inspect the output, and record what changed. If a step touches money, customers, accounts, permissions, or private data, keep it behind an explicit human approval gate.