Add provenance, policy, and erasure to your Hermes-style agent's memory
Hermes-style agents keep memory in local Markdown and SQLite — fast to ship, impossible to audit. Heartwood Memory implements the same memory-provider lifecycle and stores every turn as a governed record: signed, policy-gated, and erasable on demand.
Local memory ships fast. Then production asks hard questions.
A Hermes-style memory provider does its job: it prefetches context, syncs each turn, and writes what the agent learned to local Markdown and a SQLite index. That's the right call for a prototype. It stops being the right call the moment your agent holds anything that matters.
- No provenance. When a memory says “the customer approved the refund,” nothing proves which turn, which tool, or which principal wrote it. A poisoned or hallucinated memory is indistinguishable from a real one.
- No policy at recall. Every memory in the store is one similarity search away from any agent run. There's no tenant boundary, no clearance check, nothing standing between Agent A's query and Agent B's data.
- No erasure proof. A user invokes their right to be forgotten. You delete the Markdown row — but the embedding that encodes that text is still in the vector index, recoverable. You can't show what was deleted or prove it's gone.
These aren't bugs in Hermes-style frameworks. They're out of scope for them by design — memory is storage-agnostic and governance is left to you. Heartwood is the layer that fills that scope.
Same lifecycle, governed records
Heartwood Memory ships a Hermes-style provider example contract: a duck-typed implementation of the lifecycle you already use — initialize, prefetch, queue_prefetch, sync_turn, get_tool_schemas, handle_tool_call, shutdown. It stores completed turns as governed episodic memories and strips already-injected <memory-context> blocks before retaining, so your context doesn't recursively swallow itself.
Same surface your agent already calls. Underneath it, four things change:
Signed at write.
Every memory carries an Ed25519 signature binding its id, content hash, source, author, and epistemic class to the producing principal — so a memory cannot claim a trust level its producer never signed for.
Verified at read.
Provenance is re-checked on the way out, fail-closed: an unregistered or mismatched key fails the read rather than passing silently.
Gated before ranking.
Policy filters the candidate set before similarity ranking — a hit can never cross a tenant boundary, and denials are constant-shape, so existence never leaks through count, score, or latency.
Erasable, with proof.
forget(hard) crypto-shreds the per-subject key and purges derived embeddings down the deletion lineage, while the erasure event stays in a hash-chained audit log. This is 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.
Is this an official Hermes integration? No. Heartwood's Hermes-style provider is an example contract that exercises the common memory-provider shape — not a verified or official integration with any specific public framework. It's a starting point you adapt to your stack.
Built for the moment your agent goes from demo to production
- You’re running a Hermes-style agent and a security or compliance reviewer just asked “where did this memory come from and can you delete it?”
- You’re multi-tenant and one shared memory store is a cross-tenant leak waiting to happen.
- You want to keep your framework and your retrieval surface — and add governance underneath without a rewrite.
Put governance under your agent's memory today
The core is source-available. Install it, point your provider at it, and your next stored turn is signed, policy-gated, and erasable.
Questions
What is a Hermes-style agent memory provider?
A Hermes-style agent memory provider is the component that gives an agent persistent memory through a fixed lifecycle — initialize, prefetch, sync_turn, handle_tool_call, shutdown — typically backed by local Markdown files and a SQLite index. It handles storing and recalling memory; it does not, by itself, govern provenance, access policy, or erasure.
How do I add an audit trail and governance to a Hermes-style agent's memory?
You add governance by putting a governed store underneath the same provider lifecycle. Heartwood Memory does this: every write is Ed25519-signed and recorded in an append-only, hash-chained audit log, recall is policy-gated before ranking, and erasure crypto-shreds the per-subject key and purges derived embeddings. The agent keeps the same memory interface; the records underneath become governed.
Is Heartwood an official or verified Hermes integration?
No. Heartwood ships a Hermes-style provider example contract that matches the common memory-provider shape. It is not a verified or official integration with any specific public framework — it is an adapter pattern you wire into your own stack.
Does Heartwood replace my Hermes-style framework or extend it?
It extends it. Heartwood sits underneath as the governed store — the same recall your agent already calls, with provenance, policy, and auditable erasure the local store does not provide. You do not swap frameworks.
Does Heartwood help with GDPR right-to-erasure for agent memory?
Heartwood provides the mechanism regulated teams need: forget(hard) destroys the per-subject encryption key and purges derived artifacts like embeddings down the deletion lineage, an approach consistent with recognized crypto-shredding practice (destroying the per-subject key so the encrypted content can no longer be decrypted), while retaining the erasure event in the audit log. Whether that satisfies a specific legal obligation is a question for your counsel — Heartwood gives you the key-destruction proof primitive to build on.