Committed Memory Mutation Identity

Short answer

A destructive mirror operation needs the identity of the record the authoritative store actually changed, not the caller’s search phrase. If the native memory store resolves old_text under its own lock and an external provider later performs a second match against a partial or differently indexed registry, the two stores can select different records even though both operations appear locally valid.

Hermes current-main commit d57c2a32541a4e7b3cf68c9651f06a4d6ff9ff56, associated with closed PR #118903, changes that boundary. Successful native replace and remove operations now surface the full entry selected under the native-store lock as metadata["previous_content"] when the committed mutation is mirrored to an external memory provider. old_text remains available as caller intent, but it is explicitly not authoritative identity.

The latest stable Hermes release is v2026.9.21 / Agent v0.21.4, published 21 September 2026. Commit d57c2a32 is later current-main evidence, so this page does not describe the exact mutation-identity contract as a stable-release guarantee yet.

Source: VERIFIED | 2026-09-23 | Hermes current-main commit inspection | https://github.com/NousResearch/hermes-agent/commit/d57c2a32541a4e7b3cf68c9651f06a4d6ff9ff56 — verified 23 September 2026.

The failure mode: intent is not identity

A memory tool can accept a human-friendly selector such as old_text="Prefers tea". The native store may have several related entries, apply exact-before-substring matching, reject ambiguity or otherwise resolve the selector under a lock. Once that decision is made, there is one concrete pre-mutation record that the native store actually replaced or removed.

An external provider may not have the same candidate set. Its registry can be partial, stale, differently normalized or keyed by a remote URI. If that provider receives only old_text and repeats matching independently, it can target a different record.

The upstream PR gives the essential shape of the bug: caller search text identifies the request, while the native store’s selected full entry identifies the committed mutation. Those two values must not be treated as interchangeable.

A useful invariant is:

caller selector -> authoritative store resolution -> committed record identity -> provider mutation

The unsafe form is:

caller selector -> native mutation

caller selector -> independent provider re-resolution

The second form creates two decision points for one logical destructive operation.

Commit identity before fan-out

The current Hermes path makes the native store the identity authority for built-in memory writes.

For a successful replace or remove:

1. The native store resolves the matching entry under its file/store lock.
2. It captures the exact pre-mutation content before changing the working set.
3. The native write or complete batch must validate and persist successfully.
4. Only after that successful result is available does MemoryManager notify external providers.
5. The provider event carries the committed entry as metadata["previous_content"].

This ordering matters. A provider should not receive a destructive notification for a native change that failed validation, exceeded the configured budget, tried to remove the final disallowed entry, or failed during disk persistence.

Hermes’ regression coverage specifically checks that provider calls are still empty while native matching occurs under the lock, that failed batches expose no committed-entry receipt, and that no provider notification is emitted before successful persistence.

Batch semantics need operation-order identity

Batched memory operations are more subtle because an early operation can change the identity seen by a later operation in the same batch.

For example:

1. add creates Uses the blue notebook.
2. replace matches blue notebook and commits Uses the green notebook.
3. remove matches green notebook and removes the record created by step 2.

The authoritative previous content for step 2 is Uses the blue notebook; for step 3 it is Uses the green notebook. Replaying every operation against the pre-batch snapshot would be wrong.

Hermes therefore captures each operation’s previous content from the evolving in-memory working set, but publishes those receipts only after the entire batch passes validation and persistence. Provider notifications preserve operation order.

This is a useful transaction boundary for any harness that mirrors durable state: derive per-operation identity from the same ordered state transition that will be committed, then fan out only after commit succeeds.

Compatibility: missing identity should fail closed for destructive mirroring

The hook remains compatible with older callers: metadata is optional, and old_text is still present when supplied. Compatibility does not make old_text a safe fallback identity.

Hermes’ provider contract now documents that older versions can omit previous_content. A provider that requires exact identity should skip destructive replace or remove mirroring when that field is absent rather than guessing from a partial registry.

This is the same fail-closed principle seen in routing, authorization and recovery boundaries: if a destructive side effect requires a specific identity and that identity was never established by the authoritative owner, ambiguity is a reason to refuse the side effect, not to choose a plausible target.

Downstream OpenViking evidence is still draft work

OpenViking PR #5281 is a concrete consumer of the contract, but it is open and unmerged at this verification cutoff. It proposes recording the exact OpenViking URI for each mirrored native-memory entry and using Hermes previous_content plus target/connection data to find that mapping for later replacement or deletion.

The draft explicitly avoids falling back to semantic or substring matching when an exact mapping is missing or ambiguous. Older Hermes events without authoritative previous_content keep local native memory available but skip destructive remote mirroring with a warning.

That design is evidence that the committed-identity contract is useful across a provider boundary; it is not evidence that current OpenViking stable behavior already includes the proposed mirror implementation.

Source: VERIFIED | 2026-09-23 | OpenViking PR state and implementation review | https://github.com/volcengine/OpenViking/pull/5281 — verified 23 September 2026.

What this contract does not solve

Committed source identity removes one class of wrong-target mutation. It does not turn two stores into one atomic distributed transaction.

The current evidence does not establish:

• two-phase commit between Hermes and an external provider;
• durable replay of a provider notification after process failure;
• cross-process locking for a provider-owned mirror registry;
• automatic repair if the native commit succeeds and the later provider call or provider-registry save fails;
• full Desktop or gateway end-to-end validation for the OpenViking draft path.

The OpenViking draft calls these limits out directly. A remote write can succeed while indexing or a later registry save fails, leaving observable drift that needs warning, repair or reconciliation policy.

So the stronger architecture is not “committed identity guarantees consistency.” It is:

committed identity makes the target deterministic; separate delivery, replay and reconciliation mechanisms are still required to make cross-store state durable.

Verification boundary

The evidence on this page is source-pinned upstream validation, not an independent production certification by this site.

For the Hermes change associated with #118903, upstream reports:

• 82 native-store and event-bridge tests passing;
• 80 provider, inline-dispatch, schema and import-compatibility tests passing;
• 11 targeted regression cases that fail on unchanged Hermes and pass with the change;
• a real native-memory-tool to external OpenViking-provider/local-server flow covering replacement, refreshed search, restart deletion, profile isolation, connection reload and rejected native writes;
• Ruff and git diff --check passing.

Upstream also states that testing was on macOS and that the full repository suite was not run. Those limits remain part of the evidence.

PR #118903 itself is closed and GitHub does not mark it as merged. The reviewed behavior is nevertheless present in checked Hermes main at commit d57c2a32; this page cites the commit as the authoritative current-main coordinate rather than describing the PR as merged.

Source: VERIFIED | 2026-09-23 | Hermes PR discussion, state and validation scope | https://github.com/NousResearch/hermes-agent/pull/118903 — verified 23 September 2026.

Protocol boundary

Committed memory mutation identity is harness/runtime and provider-adapter architecture. It is not a new UHP, MCP, ACP or A2A wire primitive.

UHP can define portable task/session behavior and adapter-facing errors; MCP can expose tools/resources; ACP can connect clients and agents; A2A can coordinate agents. None of those facts makes a provider-specific memory mirror safe to re-resolve destructive targets from human search text.

If a future interoperability protocol carries destructive memory operations, it should make the relevant object identity, ownership and idempotency semantics explicit. The current Hermes evidence demonstrates the architectural requirement without changing UHP conformance or establishing native Hermes UHP adoption.

Practical review checklist

When a harness mirrors memory or other durable records across stores, verify:

1. One store owns target selection. Matching happens once at the authoritative mutation boundary.
2. Intent and identity stay separate. Search text can remain useful provenance, but it is not promoted to record identity.
3. Identity is captured under the same lock/state view as mutation selection.
4. Fan-out follows persistence. Failed or rejected native mutations emit no destructive provider event.
5. Batch identity follows operation order. Later operations see the results of earlier operations in the same committed batch.
6. Missing identity fails closed. Compatibility paths do not guess destructive targets.
7. Remote identity is durable when needed. Providers that use remote object IDs keep an explicit mapping instead of re-searching by content.
8. Delivery failure is separate from target correctness. Retry, replay and reconciliation need their own design.
9. Evidence stays versioned. Current-main behavior is not described as stable release or protocol conformance until primary sources establish that transition.

Primary sources

• Hermes current-main commit d57c2a32 — forward committed entry identity to providers
• Hermes PR #118903 — committed memory entry identity
• Hermes Agent v0.21.4 / v2026.9.21
• OpenViking PR #5281 — native memory replacement/removal mirroring