Agent Memory, Shared on Purpose

June 28, 2026 • architecture decision; updated July 5 after OB1 MCP unwiring

I am migrating my agent fleet's memory system from OB1/OpenBrain toward Honcho. The point is not to chase a shinier database. The point is to give the trusted persistent agents one better long-term memory, while being honest that the real boundary is what we allow into that shared memory.

July 1 update: after more than 24 hours of live use, the Honcho backend is operationally green. At 09:45 CDT, james-fleet-prod had drained to 47/47 completed work units with pending=0 and in_progress=0. Ten scheduled shared watchdog runs had already passed through the 05:15 run, and the latest successful marker HONCHO_FLEET_WATCHDOG_20260701T051412 remains searchable. The 09:16 watchdog run failed because the manual canary gateway it depends on was not listening; the Honcho backend itself stayed healthy and drained its queue. Decision at the time: keep Honcho live and do not roll back. July 5 follow-up: OB1 MCP recall/writeback is now unwired from normal sessions; remaining work is optional archive/credential hardening plus memory hygiene tuning.

The earlier version of this plan split operational and personal memory into separate production workspaces. That was safer on paper, but it made the live system too complicated for the actual trust model. Milo, Miloh, Echo, and Bandit are not random SaaS workers; they are the trusted named fleet. Temporary subagents, eval workers, and browser sandboxes are the processes that should not automatically get the shared key.

One shared memory is workable if every trusted persistent agent is allowed to know what gets written there. The boundary moves from workspace routing to write hygiene.

Where It Is Now

The original post was written before implementation. The migration now has a simpler current truth: Honcho is running privately on Forge, the reviewed production data is imported into james-fleet-prod, the default Hermes/OpenClaw paths have both produced searchable live markers, the backend survived the first day-plus of live traffic with clean queue recovery, and OB1 is no longer wired into normal Hermes recall/writeback. The split ops/personal workspaces still exist, but they are rollback/reference state rather than the target architecture.

Production importComplete
567 operational rows and 58 personal rows imported from an explicit allowlist.
Shared workspaceLive default
james-fleet-prod is imported, drained, exported, and used by default Hermes/Miloh plus OpenClaw/Milo.
24h+ stabilityBackend green
API healthy; queue drained to 47/47 completed at the latest check.
OB1 statusUnwired
No normal Hermes MCP recall/writeback; archive-only provenance unless manually reconnected.
AreaCurrent state
Target workspacejames-fleet-prod: one shared Honcho memory for trusted persistent agents.
Imported dataAll approved rows are in the shared workspace: 567 operational rows and 58 personal rows.
Held outBlocked, review, raw, stale, and superseded rows were intentionally excluded.
DerivationHoncho processing queues drained after import, live traffic, and canary/watchdog writes; latest measured queue was 47/47 completed with no pending or in-progress work.
Live default pathsDefault Hermes/Miloh and OpenClaw/Milo have both written searchable cutover markers into james-fleet-prod.
Canary/watchdogTen scheduled shared-watchdog runs passed through 05:15 on July 1. The 09:16 run exposed watchdog plumbing fragility because the manual canary gateway was down; Honcho itself stayed healthy and its queue drained.
Old split pathjames-ops-prod, james-personal-prod, honchoops, and honchopersonal remain only as rollback/reference state.
FallbackOB1 is archive-only provenance; it is no longer wired into normal Hermes recall or writeback.

The Target Shape

Honcho memory target: one shared trusted-agent workspace Forge hosts Honcho • james-fleet-prod is shared by trusted persistent agents • write hygiene is the boundary Milo trusted persistent agent Miloh trusted persistent agent Echo trusted persistent agent Bandit trusted persistent agent SHARED james-fleet-prod ops + personal continuity for trusted named agents; no secrets; no untrusted workers OB1 archive-only provenance manual reconnect only for emergency audit persistent trusted agents temporary fallback only Throwaway subagents and eval sandboxes do not receive this key by default.

The key design choice changed. Honcho still gives us source-aware, long-lived memory, but I no longer think the right first production design is a workspace split between trusted named agents. The simpler rule is: one shared workspace for the trusted persistent fleet, and much stricter rules for what is allowed to be written there.

Access Policy

RuntimeShared memoryRole
Default Hermes / Milohyeslive through the Hermes Honcho provider against james-fleet-prod
OpenClaw / Miloyeslive through an OpenBrain-compatible localhost shim backed by Honcho
Echo / Bandit / future named agentsyes, when wiredtrusted persistent consumers may join the shared workspace after explicit wiring
Throwaway subagents / eval workersno by defaultdo not receive the shared key automatically
honchoops / honchopersonal / honchofleetlegacy/canarykept for rollback, watchdogs, and reference checks

The table is less complicated than the old architecture because the trust model is less complicated. If something is written into shared memory, every trusted persistent agent may read it. If that is not acceptable, the content does not belong in shared memory.

What Moves Where

Shared fleet memoryInfrastructure, repos, commands, model routing, failures, preferences, goals, family/context continuity, and agent-coordination lessons that every trusted persistent agent may know.
Do not writeSecrets, raw credentials, tokens, passwords, private third-party material, and anything James would not want every trusted persistent agent to know.
Ambiguous memoryEither rewrite it into a safe shared form or skip it. Do not depend on tags/prompts to hide sensitive rows later.
SecretsDo not store them as memory. Store vault/keychain references only. Memory is not a secret manager.

Migration Pipeline

OB1 → Honcho migration: staged, classified, reversible Import everything relevant into staging first • promote only after access and leakage evals pass OB1 current memories Transcripts user/assistant + summaries Classifier ops • personal • mixed Review uncertain/mixed STAGING ops-staging eval operational recall and leakage before production STAGING personal-staging inspect derived conclusions before trusting them ops-prod personal-prod OB1 is no longer wired into normal Hermes recall/writeback; archived only for provenance.

The migration was deliberately staged. OB1 memories were exported, normalized, classified, reviewed, imported into staging, evaluated, and then rebuilt into clean production workspaces from an approved allowlist. That last step matters: production was not a blind copy of staging.

The Pipeline in Plain English

  1. Export OB1 and relevant transcripts. Pull current memories and user/assistant transcript material. Skip raw tool output and system prompts.
  2. Normalize everything. Attach source agent, source session, timestamp, role, source hash, and import batch.
  3. Classify. Route each unit as operational, personal, mixed, secret, quarantine, or skip.
  4. Resolve mixed records. Rewrite them into safe shared form, skip them, or keep them blocked; do not import raw ambiguity.
  5. Import to staging. Let Honcho process the data and produce conclusions.
  6. Evaluate. Test retrieval quality, personal leakage, source attribution, and over-inference.
  7. Promote to production. Only approved data moves to the clean shared production workspace.
  8. Cut over agents. Start with a shared canary, then move default Hermes and OpenClaw/Milo to the same shared workspace.
  9. Unwire OB1 after cutover. Preserve archive/provenance material, but do not expose OB1 as a normal recall/writeback path.

Why Not Keep OB1 Forever?

Because dual memory systems rot. If every new fact has to be written to both OB1 and Honcho, the system becomes harder to reason about than either system alone. The compromise was a temporary rollback path, not permanent dual-write or permanent dual-recall.

After the completed cutover, OB1 is no longer part of normal agent recall or writeback. It remains only as offline provenance/archive material unless James explicitly asks for an emergency reconnect.

What Passed, and What Comes Next

GateStatusMeaning
Shared import countPassed567 operational rows and 58 personal rows imported into james-fleet-prod.
Blocked/review lanesPassedBlocked, review, raw, stale, and superseded rows stayed out of production shared memory.
Queue drainPassedPending and in-progress work units returned to zero after import, canary writes, and live cutover checks.
Default Hermes cutoverPassedDefault Hermes/Miloh uses james-fleet-prod through the Hermes Honcho provider.
OpenClaw/Milo cutoverPassedMilo kept its existing OpenBrain tool contract while the backend moved to Honcho through a localhost shim.
24h+ backend watchPassedHoncho stayed healthy past the first day-plus of live traffic. Latest measured queue: 47/47 completed, no pending or in-progress work.
Scheduled watchdogsMostly passedTen scheduled runs passed through 05:15 July 1, including HONCHO_FLEET_WATCHDOG_20260701T051412. The 09:16 failure exposed a down manual canary gateway, not a Honcho backend failure.
Memory hygieneYellowNo same-pair duplicate growth has shown up, but cross-observer fanout is noisy enough to tune before expanding access or retiring OB1.
OB1 retirementDone for live agentsOB1 MCP recall/writeback is unwired from normal Hermes sessions; remaining work is optional credential/archive hardening.

Decision After 24h+ Watch

The first day-plus changes the risk picture. This is no longer a cutover-risk problem; it is a memory-quality and watchdog-supervision problem. The Honcho backend is healthy enough to keep live, and the rollback path should stay untouched while I tune how much derived memory Honcho creates for the shared observer graph and make the watchdog depend on a supervised path.

  1. Keep shared Honcho live. Default Hermes/Miloh and OpenClaw/Milo stay on james-fleet-prod.
  2. Keep OB1 unwired. Do not expose OB1 MCP recall/writeback in normal sessions; preserve exports/backups as archive-only provenance.
  3. Harden write hygiene next. Tune prompts and observer behavior so facts are not over-derived across every observer pair.
  4. Fix watchdog plumbing. The manual canary gateway caused the 09:16 watchdog failure; either supervise it or point the watchdog at a live default path.
  5. Only then clean up. Retire old split canaries and keep OB1 as archive-only provenance after stability plus hygiene, not merely after one green run.

Operational Rules

The Cutover

The remaining decision is no longer theoretical. We cancelled the provider-compartment PR, retired the split-profile rollout as the target, then cut the live default paths to james-fleet-prod. Default Hermes/Miloh writes through the Hermes Honcho provider. OpenClaw/Milo writes through a localhost OpenBrain-compatible shim backed by Honcho, so the mature Milo memory tooling kept working while the storage backend changed. OB1 is no longer wired into normal recall/writeback; Honcho is the sole live memory path for trusted agents.

OptionVerdictWhy
Generalized provider compartmentsCancelled PRPR 54534 was useful proof, but too much policy in the provider layer.
Split ops/personal profile rolloutDemoted to rollbackIt worked, but it was solving a harder threat model than the trusted fleet needs right now.
One shared fleet workspaceCurrent targetIt matches the actual trust model: trusted persistent agents share memory; untrusted temporary workers do not get the key.
Default Hermes/OpenClaw cutoverCompleteBoth default paths produced live markers in james-fleet-prod; the current proof is sustained real traffic and clean memory hygiene.
Next workHygiene + watchdog plumbingNo rollback and no new architecture. Tune observer/write behavior, then fix the canary/watchdog supervision gap before retiring fallback pieces.
Hard stop remains: shared memory is not a secret manager. Do not write secrets, raw tokens, passwords, private third-party material, or anything James would not want every trusted persistent agent to know.

The Short Version

One platform: Honcho
One production memory: james-fleet-prod
Shared import: 567 ops rows + 58 personal rows
Provider-extension PR 54534: cancelled after design review
Split ops/personal canaries: retained for rollback/reference
Current rollout: default Hermes/Miloh and OpenClaw/Milo cut over
Live proof: both wrote searchable cutover markers into james-fleet-prod
Fallback: OB1 MCP is unwired from normal sessions; archive/provenance only
24h+ backend watch: green, latest queue 47/47 drained
Watchdog caveat: 09:16 failure was manual canary gateway plumbing, not backend failure
Next: hygiene hardening + watchdog supervision, then optional OB1 credential/archive hardening

The hard part was not getting rows into a vector-backed memory system. The hard part was admitting the architecture had become more complicated than the trust model required. After the first day-plus and the July 5 cleanup, the honest work is less dramatic: keep the shared Honcho path live, keep OB1 unwired from normal agents, tune memory hygiene, and make the watchdog boring.