Durable State Repair in Multiplexed Agent Harnesses

Short answer

Preventing new ownership mistakes and repairing old durable state are different jobs. A routing fix can make every future session land in the correct profile while previously crossed rows, parent links, routing indexes and compatibility mirrors remain wrong indefinitely.

Hermes PR #115689, merged on 19 September 2026 as 67757285f696a4614b76e928dfd86c9f07ec5704, is useful current implementation evidence. It adds hermes sessions repair-profiles, a repair path for cross-profile session state left behind by earlier multi-profile behavior. The command is read-only by default, refuses mutation while a relevant gateway is live, snapshots stores before applying changes, distinguishes deterministic repairs from ambiguous cases, and is designed so a second scan converges to no findings after successful repair.

This is post-v0.21.3 current-main Hermes behavior. It does not revise UHP, MCP, ACP or A2A wire semantics and does not establish native UHP adoption by Hermes.

Forward correctness does not imply historical correctness

A mature multi-profile harness usually hardens incrementally. It may first correct where new sessions are written, then fence parent inheritance, stamp platform bindings with owner identity, scope voice or routing state, and make session-key derivation consistent.

Those changes protect future writes. They do not answer a separate question:

What happens to durable state created before the invariant was fixed?

Hermes’ repair work makes that distinction explicit. The upstream merge notes that earlier profile-store and identity fixes were forward-only, and that one incident had already identified 246 stranded sessions that warning logic could detect but not settle automatically.

The general architecture therefore needs two control planes:

Layer	Purpose
Prevention	Make new writes, routes and derived keys obey the current ownership invariant.
Detection	Find durable state whose physical store, namespace, metadata or lineage disagrees with that invariant.
Classification	Separate repairs that are provable from cases where the stored evidence is ambiguous.
Remediation	Move, relabel, sever or remove state with rollback/recovery evidence and a convergence check.

Treating prevention as remediation leaves old corruption structurally valid enough to keep resurfacing through search, restore, routing or compatibility imports.

Repair the ownership graph, not one table

Hermes #115689 scans every profile’s state.db plus gateway-owned compatibility state in gateway_voice_mode.json and sessions.json. Its repair plan names six categories that expose different ownership failures:

1. a row’s profile_name disagrees with the profile encoded in its own session_key;
2. rows physically live in another profile’s store;
3. parent_session_id crosses profile namespaces;
4. gateway_routing rows are duplicated, misplaced or belong to a profile that no longer exists;
5. Telegram topic or voice-mode entries lack the profile that owns the bot/chat evidence; and
6. sessions.json contains a namespace that no currently served profile claims.

That breadth matters. A repair that moves the primary session row but leaves a routing index, parent edge or compatibility mirror behind can recreate the defect on restart or direct later traffic to the wrong owner.

The reusable rule is: enumerate every durable and derived surface that can reassert ownership before defining a repair complete. Primary rows, indexes, caches persisted to disk, compatibility mirrors and lineage edges may all participate in the same invariant.

Cross-store moves should be crash-settleable

Moving state between owner stores is riskier than editing one label in place. The reviewed Hermes implementation exports the complete session state needed by the destination — message generations, usage and system prompt — imports parents before children so lineage can be reconstructed, then removes the source copy.

The important recovery property is the ordering: copy before delete. If the process crashes during a move batch, the failure mode is a duplicate that a later run can settle, not silent data loss caused by deleting the source before the destination is durable.

That is a useful migration pattern for any agent harness that has to repair persistence across ownership domains:

• make the destination reconstructable before destroying the source;
• preserve lineage/order constraints explicitly;
• choose an interruption state that is detectable on the next scan; and
• make repair idempotent so rerunning the same operation converges rather than multiplying damage.

A repair command should be designed around the failure it leaves behind when interrupted, not only around the happy path.

Ambiguity must remain visible

Not every historical row contains enough evidence to identify the correct owner. Hermes deliberately refuses to guess two important classes.

First, agent:main: rows found inside a named profile’s store are report-only by default. The same shape can represent two materially different histories: an older standalone gateway’s legitimate history that should be rekeyed into the named profile, or a default-profile conversation that leaked into the named store and should be moved back to the root store. The row itself cannot distinguish those cases.

The command therefore requires the operator to choose --legacy-main rekey or --legacy-main move when that ambiguity is resolved externally.

Second, rows whose namespace names a profile that no longer exists are reported rather than silently reassigned. The repair path points the operator toward profile-identity migration instead of inventing a new owner from incomplete evidence.

This is a stronger invariant than “repair everything automatically”:

Automation should stop where durable evidence stops.

A wrong automatic owner assignment can be worse than a visible unresolved row because it converts uncertainty into authoritative-looking history.

Quiesce writers before mutating shared state

A repair can be logically correct and still lose if a live process owns an in-memory copy of the same state. Hermes’ --apply path checks for gateways owning the relevant homes before opening stores for write and refuses to proceed while one is live.

The reason is concrete: the gateway holds routing state in memory and can write it back after the repair, restoring the stale value over the corrected database.

This generalizes beyond SQLite. Before mutating durable control state, a repair tool should establish whether another authority can still publish an older generation from memory, a journal, a cache or a background worker. If so, the choices are usually to stop/quiesce that authority, coordinate through its own transactional API, or add generation fencing. Blindly editing the backing store is not enough.

Snapshot before apply; dry-run by default

hermes sessions repair-profiles is observational unless --apply is supplied. The reviewed implementation uses read-only store opens for the scan path and takes a quick snapshot of every store before mutation.

That combination creates three useful safety properties:

• previewability: the operator or automation can see findings and intended actions before writes occur;
• rollback evidence: every store has a pre-repair snapshot boundary; and
• no-op confidence: a dry run can be compared structurally with the original state to prove that detection itself did not mutate the store.

For automation, the command also exposes JSON output and an explicit confirmation bypass rather than forcing parsers to scrape human text.

Verify convergence, not only command success

A successful exit code says the repair routine ran. It does not prove that the ownership invariant now holds across all stores and mirrors.

Hermes’ upstream validation therefore includes a second scan after apply and requires it to find nothing in the covered fixture. The fixture contains all six defect classes across three stores, and the PR reports additional checks for live-gateway refusal, legacy-main rekeying, dry-run no-op behavior and idempotence. The focused verification cited by the PR reports 1,151 passed, 0 failed across 134 files, plus a real two-home CLI sequence of dry-run → apply → clean second run with snapshots present in both homes.

Those are upstream implementation results, not independent benchmarking by this site. Their architectural value is the convergence criterion: repair is complete only when the detector that defined the defect can no longer reproduce it under the same scope.

A useful repair acceptance sequence is therefore:

1. scan and persist the finding set;
2. quiesce conflicting writers;
3. snapshot the affected stores;
4. apply only evidence-backed transformations;
5. surface any ambiguous/unrepairable findings separately;
6. re-scan the same population; and
7. require a clean or explicitly explained residual set.

Derived state can reintroduce repaired history

Compatibility files and secondary indexes are easy to dismiss as rebuildable detail, but they can become active writers during startup. Hermes’ PR specifically drops sessions.json entries whose namespace no served profile claims because the legacy import path can otherwise re-inject them into the routing database on every boot.

That illustrates a general recovery trap: a stale mirror can be a resurrection source.

When reviewing a repair, identify not only where the canonical row lives today, but every startup/import/reconciliation path that can repopulate that row later. A repair is incomplete if an obsolete compatibility layer can reconstruct the bad state after the main database has been cleaned.

Relation to routing identity and profile isolation

Routing identity covers the forward path: resolve transport, authorization, runtime and persistence ownership once, preserve that decision and derive owner-sensitive keys from it.

Profile isolation covers the broader lifecycle boundary around secrets, configuration, persistence, background work and delivery.

Durable state repair addresses the historical residue those controls cannot fix retroactively. The three concerns are complementary:

• routing identity prevents new split-owner decisions;
• profile isolation limits cross-owner effects across the runtime lifecycle; and
• state repair detects and settles durable records created before those invariants were enforced.

A system can be correct on the first two today while still carrying historical violations from yesterday.

Protocol boundary

This page documents a harness-runtime remediation pattern using current Hermes source evidence.

• UHP: does not standardize Hermes profiles, state.db, gateway_routing, sessions.json or the repair-profiles command. A UHP server may front a harness with historical-state repair tooling without making that tooling a UHP operation.
• MCP: is unchanged. Repairing a harness’s profile/session ownership does not modify MCP transport, authorization or tool semantics.
• ACP: is unchanged. This repair path is not an ACP session-migration primitive.
• A2A: is unchanged. Local durable-state ownership is not promoted into an A2A agent-identity operation.
• HarnessRouter: current stable/current-main remains v0.19.0 / ccf4af6647182e7175788353f8b0287829054e07 at this cutoff. Nothing in Hermes #115689 is HarnessRouter conformance evidence or native Hermes UHP adoption.

The latest published Hermes stable remains v2026.9.14 / Agent v0.21.3. PR #115689 is later current-main implementation evidence and should not be attributed to that stable tag until an upstream release includes it.

Practical review checklist

When reviewing a durable-state repair path for a multi-profile or multi-tenant agent host, verify:

1. Detection and repair are separate: a dry run can enumerate findings without mutation.
2. All ownership surfaces are covered: primary rows, physical stores, lineage, routing indexes and persistent mirrors are included.
3. The repair source of truth is explicit: owner decisions come from durable evidence, not ambient defaults.
4. Ambiguous state stays unresolved: the tool does not guess when two ownership histories are both plausible.
5. Writers are quiesced: a live process cannot overwrite repaired state from stale in-memory data.
6. Snapshots precede mutation: recovery material exists for every store the operation may change.
7. Cross-store moves are recoverable: copy-before-delete leaves a detectable duplicate rather than data loss after interruption.
8. Lineage survives: parents/children, generations and usage/history required by the destination remain internally consistent.
9. Deleted owners are handled deliberately: unknown namespaces are not silently reassigned.
10. Mirrors cannot resurrect bad state: startup/import compatibility paths are part of the repair inventory.
11. Apply is idempotent: retrying after success does not create additional changes.
12. Convergence is verified: the same detector re-runs after apply and accounts for every residual finding.
13. Protocol claims stay scoped: local remediation behavior is not relabeled as UHP, MCP, ACP or A2A semantics.

Primary sources

• Hermes PR #115689 — hermes sessions repair-profiles
• Hermes merge commit 67757285
• Hermes issue #113884 — stranded profile history referenced by the repair
• Hermes identity-remediation tracking issue #88715
• Hermes v2026.9.14 / Agent v0.21.3
• HarnessRouter v0.19.0

---

This is an independent technical guide. “Durable state repair” here is an architectural description grounded in the cited Hermes implementation; it is not a new interoperability standard or vendor certification.