Inside this guide
The January beginning
We started building ClawVault in January 2026 around a practical problem: useful context was getting lost between agent sessions. Decisions had to be explained again, and a new session could inherit an incomplete picture of the work.
Our development history begins on January 30 with categorized documents, metadata and links. A public MCP companion was committed the same day so compatible tools could store, search and read that context. The npm registry records version 1.1.0 on February 1.
Sources: January 30 ClawVault MCP commit · ClawVault npm release metadata
A decision needs a different shape from a preference
Imagine three notes from an account review. The client prefers a written update. The team chose a particular reporting source. An account manager agreed to deliver a draft on Friday.
Those notes serve different purposes. The preference helps with communication. The decision needs its context and reasoning. The commitment needs an owner and a way to tell whether it has been fulfilled. Storing them with those distinctions makes the next lookup more useful.
ClawVault's early approach used categories and human-readable Markdown. A person could inspect the note, and an agent could retrieve a relevant slice of the archive instead of loading every conversation.
Keep the influences visible
The later memory taxonomy built on Benthic's classification, which the ClawVault documentation credits. The project developed its own storage, retrieval and operating conventions around that work.
We built around that foundation with a practical goal: make memory easy to inspect, retrieve and carry into the next session. A person should be able to read a note, understand its purpose and correct it when the work changes.
Sources: ClawVault introduction and classification attribution
The structure developed through February
The January source defined a document shape and named categories, while allowing custom category strings. It would be inaccurate to describe that initial version as a strict schema system for every memory type.
On February 13, the graph release connected memories through typed relationships and added retrieval profiles. The February 15 template release then gave primitives declared fields and defaults. Its validation was advisory: a warning did not mean a write had been blocked.
A label, a schema and an enforced business rule solve different parts of the problem. Keeping their release dates and behavior distinct makes the history more useful to someone designing an agent today.
Make every useful note answer a few questions
For a business workflow, the note itself is only part of the context. Someone returning to it should be able to understand why it exists and whether it is still relevant. A polished summary that loses those details can create more work than it saves.
As an operating practice, we would ask these questions before promoting an observation into shared context:
- What kind of information is this: an observation, decision, preference or commitment?
- Which source or conversation supports it?
- Who owns the decision or the next action?
- What could make it stale or require a fresh check?
- Who is allowed to see it in the next workflow?
A remembered fact may need a live check
Suppose an agent remembers that an estimate was accepted. Before preparing an invoice reminder, the workflow still needs the current accounting status. The note explains an earlier conversation; the accounting system establishes whether an invoice now exists and whether a payment has been recorded.
Similarly, a customer's communication preference can guide a draft without authorizing a new message. A record of an earlier approval does not automatically approve a different amount, recipient or action.
These are illustrative operating examples. They show why memory should be connected to the actual workflow contract: useful context, current facts where required, and a clear person for unresolved decisions.
Test continuity by resuming the work
A memory demonstration should include the next session. Save the relevant context, begin again and ask the agent to continue a bounded task. Check whether it finds the correct record, recognizes uncertainty and avoids treating old plans as completed actions.
Include a changed fact in that test. If the owner or project status has moved on, the workflow should know when to check the source and update its working understanding. Also test a missing record. An honest gap is more useful than an answer assembled from unrelated notes.
During monthly care, review stale records, repeated retrieval misses and unresolved contradictions. Agree on retention and review ownership as part of the scope. The size of the archive is rarely the measure the business actually cares about.
Apply the lesson to today's stack
OpenClaw now documents a native memory system. For a new deployment, evaluate the current runtime and its supported memory path before carrying forward an older installation. ClawVault's history can inform that choice without requiring every new workflow to use the original stack.
The lasting lesson is inspectable structure. A useful memory can be found, understood and connected to the work that needs it. Our approach to managed agents carries that forward: identify the authoritative record, preserve context for the handoff and verify current state before consequential action.
If your team repeatedly reconstructs the same decisions, bring one example. We can map where durable context would help, which facts need live verification and how the workflow can remain useful as the business changes.
Explore the next step
Company brain & Cortex · Lead response and booking · Workflow automation · Managed AI agents
Continue reading: OpenClaw for small business: start with one workflow you can verify