Governed memory for AI agents
Heartwood Memory is a governed memory store for AI agents. It gives agents that keep memory in ungoverned local Markdown and SQLite — including Hermes-style and OpenClaw-style runtimes — the provenance-signed audit, policy-gated recall, tenant isolation, and a per-subject key-destruction proof on erasure they don't have natively.
Most agent memory isn't ungoverned or governed. There are three postures.
Agent memory governance isn't a yes/no. It's a spectrum, and most tools sit at one of three points. Knowing which one you're on tells you exactly what you can and can't prove.
| Ungoverned | Coarse-governed | Cryptographic (Heartwood) | |
|---|---|---|---|
| Examples | Hermes-style / OpenClaw-style local memory, Codex-native local store | Dataset-level ACLs + telemetry (e.g. cognee) | Heartwood Memory |
| Where rules live | In your application code, if at all | At the dataset / collection level | At the individual memory record |
| Provenance | None — a memory has no verifiable author | Source tracked at dataset level | Every record Ed25519-signed, re-verified at read, fail-closed |
| Recall policy | Whatever you filter in app code | Dataset access controls | Policy gates the candidate set before ranking; denials don’t leak existence |
| Audit | Logs, if you wrote them | Telemetry / activity logs | Append-only, hash-chained, tamper-evident; silent edits detectable |
| Erasure | Delete the row; embedding remains | Delete from dataset | Crypto-shred per-subject key + purge derived embeddings; erasure event retained |
| Proof | None | Hard to prove at record level | Every governance claim is a gate you can re-run |
cognee governs at the dataset level with access controls and telemetry, and it leads on graph and ontology modeling and adoption. Heartwood governs and proves at the record level: per-memory signatures, policy-before-ranking, and crypto-shred erasure you can re-verify. Different layer, different job. If you need graph-native reasoning today, cognee is further along; if you need record-level proof, that's our lane.
See the full comparison →On erasure, Heartwood emits a per-subject key-destruction proof — not a claim of instant or whole-content deletion. Full key destruction completes within ≤72h on dedicated-vault plans, or up to 90 days on shared-vault plans.
What “cryptographic” actually means here
- Every memory write is signed with Ed25519 (when available) and recorded in a hash-chained audit log.
- A memory can’t claim a trust level its producer didn’t sign for — provenance is the memory-poisoning defense.
- Policy filters the candidate set before ranking, so a similarity hit never crosses a tenant boundary.
- Erasure crypto-shreds the per-subject key and purges derived embeddings — the deletion event stays in the audit log.
- Generated memory is stored only after a faithfulness check and an egress check pass.
Embeddable, single-file, on-device
Heartwood runs where your agent runs. It's an embedded library with a single-file store — on-device, zero-egress by default. Nothing about governing your memory requires shipping it to us.
Start where your agent already is
Governed memory for Codex — via MCP
Heartwood works with Codex-style agents the same way it works with any MCP client: over the Model Context Protocol. Point the agent at Heartwood's MCP server and it gets governed memory verbs — remember, recall (policy-enforced, returns provenance), explain_recall, forget (crypto-shred), evaluate_egress, and assess_faithfulness — instead of an ungoverned local store.
Today: local-stdio MCP. Heartwood's MCP server runs locally and binds to 127.0.0.1 by default — your data stays in your environment.
Roadmap: hosted / remote MCP. We're not there yet, and this page won't pretend we are.
Codex via MCP — questions
Can I use Heartwood as the memory backend for a Codex-style agent?
You can use Heartwood as a governed memory backend for any MCP-capable agent, including Codex-style agents, over the Model Context Protocol. The agent calls Heartwood’s MCP memory verbs — recall is policy-enforced and returns provenance, and forget performs a crypto-shred erasure. This works today over local-stdio MCP; hosted/remote MCP is on the roadmap.
Is Heartwood an official Codex memory backend?
No. Heartwood is a governed memory store you connect to via MCP — the open Model Context Protocol contract — not an official or verified Codex integration. You choose to point your agent at it; it runs in your environment.
Questions
What is governed agent memory?
Governed agent memory is agent memory with enforceable rules attached to each record: verifiable provenance (who wrote it), policy-gated recall (who can retrieve it), tamper-evident audit (what happened to it), and a per-subject key-destruction proof on erasure. It is the difference between storing what an agent remembers and being able to prove and control it.
What makes Heartwood Memory different from other agent memory tools?
Heartwood governs and proves at the individual record level. Every memory is Ed25519-signed and re-verified at read, recall is policy-gated before ranking with no existence leak, the audit log is hash-chained and tamper-evident, and erasure crypto-shreds the per-subject key plus purges derived embeddings. It is newer and narrower than graph-first memory tools — and it is built so every governance claim is a gate you can re-run.
How is Heartwood different from cognee?
cognee governs at the dataset level and leads on graph and ontology modeling and adoption. Heartwood governs and proves at the record level — per-memory signatures, policy-before-ranking, and crypto-shred erasure. They operate at different layers: cognee for graph-native reasoning, Heartwood for record-level, source-auditable governance.
Does Heartwood encrypt my data end-to-end?
No — Heartwood is a managed-key governance layer, not an end-to-end-encrypted vault. Erasure works by crypto-shredding per-subject keys, and the server processes recall under policy. Heartwood’s value is source-auditable governance — provenance, audit, policy, and a key-destruction proof you can verify — not secrecy from the server.
Where does my data live?
In your environment. Heartwood is embedded and runs beside your systems of record — on-device, zero-egress by default. Nothing is shipped to the Heartwood team to use it.