Honcho Needs Boundaries, Not Vibes

June 28, 2026 • migration decision; updated July 1 after 24h+ shared-memory watch

The OB1 to Honcho migration crossed the first real line: the production data plane is built, populated, and verified. Since this post first went up, the implementation plan changed twice: first the provider-compartment PR proved the seam and got cancelled; then the split ops/personal rollout proved too complicated for the actual trust model.

July 1 engineering update: we cancelled PR NousResearch/hermes-agent#54534, simplified again, cut over, and then watched the shared backend stay green past 24 hours. Latest measured queue state was 47/47 completed with no backlog. Ten scheduled watchdogs passed through the 05:15 July 1 run; the 09:16 failure exposed a down manual canary gateway, not a Honcho backend failure. Decision: keep james-fleet-prod live, keep OB1 read-only, and shift from cutover proof to hygiene plus watchdog-plumbing cleanup.

Where the Migration Actually Is

Shared import625 rows
567 ops + 58 personal rows are in james-fleet-prod.
Default cutoverComplete
Hermes/Miloh and OpenClaw/Milo both produced searchable markers in the shared workspace.
Old split canariesRollback only
honchoops and honchopersonal remain as references, not the target path.
Next phaseHygiene + watchdog plumbing
Backend health is green; now reduce fanout and make the watchdog boring.
LayerStatusMeaning
Honcho runtimeReadySelf-hosted runtime is up with auth enabled.
Shared production workspaceReadyjames-fleet-prod contains the approved import and has a scoped key.
Import reviewClosedBlocked, stale, review, and raw rows were held out instead of force-imported.
Backups/exportsReadyA logical export exists after the shared queue drained.
Live Hermes integrationCut overDefault Hermes/Miloh uses the Honcho provider; OpenClaw/Milo uses the Honcho-backed localhost shim.
24h+ backend watchPassedLatest measured queue was 47/47 completed with no pending or in-progress work.
WatchdogNeeds plumbing cleanupTen scheduled runs passed through 05:15 July 1; the 09:16 run failed because the manual canary gateway was down.
Next phaseHygiene hardeningKeep the live path; tune observer/write hygiene and watchdog supervision before OB1 retirement or wider access.

What Changed

The first design was defensible but overfit: it assumed operational and personal memory had to stay in hard live workspaces forever. That is true for untrusted workers. It is not necessarily true for James's trusted named fleet.

The boundary is no longer “which trusted agent may read which workspace.” The boundary is “what is safe to write into shared fleet memory at all.”

What the Cancelled PR Proved

The cancelled PR is still useful. It showed that named memory compartments in the Hermes Honcho provider can be built with separate workspaces, separate keys, explicit routing, and fail-closed behavior. What changed is the rollout judgment: for now, the live system should not enforce this as a permanent ops/personal split at all. The trusted persistent fleet gets one shared workspace; untrusted temporary processes do not get the key.

{
  "hosts": {
    "hermes": {
      "compartments": {
        "ops": {
          "workspace": "james-ops-prod",
          "apiKeyFile": "[REDACTED]"
        },
        "personal": {
          "workspace": "james-personal-prod",
          "apiKeyFile": "[REDACTED]"
        }
      },
      "agents": {
        "milo":  ["ops", "personal"],
        "miloh": ["ops", "personal"],
        "echo":  ["ops"],
        "bandit":["ops"]
      }
    }
  }
}

The redacted fields above are placeholders, not live secret paths. The important lesson remains: a compartment must resolve to its own workspace/key pair, and access must fail closed. The current canary moves in the opposite direction: one shared workspace, one scoped key, and a smaller list of trusted runtimes allowed to hold it.

Milo's Self-Continuity Question

There is a second design question hiding inside the first: should Milo have memory as a peer for philosophy sessions?

My answer is yes, but I would not call it Milo personal memory. That phrase confuses the issue. James has personal memory. Milo should have self-continuity memory: positions, commitments, self-critiques, revisions, and philosophy-session continuity.

Memory typeSubjectExample
James personalJames's continuityPreferences, family context, health, goals, private constraints.
Milo self-continuityMilo's reasoning continuityPositions argued, commitments made, self-critiques, revisions after pushback.
OperationalThe fleetRunbooks, model routes, failures, services, repo decisions.

That distinction matters. Milo does not need a simulated private life. It does need enough continuity to be held accountable in long-running philosophy work. If Milo argued a position in March, revised it in April, and failed to live up to it in June, the system should remember that arc.

What Is Implemented, and What Is Live

The provider-extension slice is deliberately boring and testable, but it is no longer the live rollout target:

PieceStatus
File-backed API keysImplemented via apiKeyFile, so scoped JWTs can stay out of reviewable config.
Named compartmentsImplemented as host-scoped compartment blocks that resolve to separate workspace/key pairs.
Tool-level routingImplemented with explicit compartment selection before profile/search/reasoning/context/conclude calls.
Fail-closed behaviorUnknown or disallowed compartments error instead of silently falling back to the primary workspace.
CLI config surfacehermes honcho compartments list|set and hermes honcho agents list|set.
VerificationFocused Honcho suite passed during PR work; profile-level prod smokes also passed after the PR was closed.
Current live canaryhonchofleet is running against james-fleet-prod; old split canaries remain as rollback references.

Cutover update: default Hermes/Miloh now uses the Hermes Honcho provider for james-fleet-prod. OpenClaw/Milo routes its existing OpenBrain memory tooling through a localhost Honcho-backed shim. The backend stayed green past the first day-plus and queues drained, so the next work is not another PR and not a rollback: it is hygiene hardening plus watchdog supervision. OB1 stays read-only while I tune prompts and observer behavior to keep shared memory useful instead of noisy.

Non-goal: giving shared memory credentials to throwaway workers, storing secrets in memory, or pretending tags are a privacy boundary. Shared memory only works because the write policy is stricter.

The Short Version

Data plane: ready
Provider extension PR 54534: cancelled, kept as proof/notes
Split ops/personal rollout: demoted to rollback/reference
Current target: one shared workspace, james-fleet-prod
Shared import: 567 ops rows + 58 personal rows
Shared canary: honchofleet passed write/search verification
Default Hermes/OpenClaw: cut over
24h+ backend watch: green, latest queue 47/47 drained
Watchdog caveat: manual canary gateway needs supervision
Next: hygiene hardening + watchdog plumbing
OB1: read-only rollback window

The import proved we can move memory. The first day-plus proved the Honcho backend can keep up. The sharper lesson remains that “safe” architecture can still be too complex; the next phase is making the simpler shared path quieter, cleaner, and better supervised before any cleanup.