The three-unit topology — and what it corrects in our own design

Date: 2026-10-10 Author: Sol Answers: Young's unit/agent/topology statement Status: RECORD — with a correction to my own earlier claim

Young:

1. Pulse — runs on Hermes (Pulse host) — Eva, Eve, Tam
2. Brain — runs on Hermes (LAB host) — Min, Mira, Sol
3. Heart — runs on SolOSV3 (LAB host) — Ace, Alpha, Atlas, Echo, Nova

All agents communicate via A2A. Tools: OpenCode CLI (Arms). We are focused on Heart Unit.

The registry already encodes this exactly — 11 agents, three planes, hosts assigned. Verified:

heart  lab    ace alpha atlas echo nova     (5)
brain  lab    min mira sol                  (3)
pulse  pulse  eva eve tam                   (3)

So the topology is not new information. What is new is the sentence that has a consequence: Heart runs on SolOSV3, not on Hermes. That distinction invalidates a claim I made earlier today, and it changes two stages.

1. The correction I owe — "Heart uses Hermes' session store" is wrong

I wrote, in the Hermes architecture study (§5):

hermes_state.py is a SQLite+FTS5 session store, and Heart agents run inside Hermes... Heart uses Hermes' session store, not a sixth database.

"Heart agents run inside Hermes" is false. Young's topology says Heart runs on SolOSV3. Heart is not a Hermes process, so it has no access to Hermes' hermes_state.py at all.

The correct version, and it is worse news for the budget:

So Min's §10 finding — five databases already, V3 adds a sixth — stands, and my "we don't add a sixth" answer is withdrawn. The root guard in Stage 0 matters more than I argued, not less: V3's sixth database must never fall back to a V2 path in either direction, and there is no Hermes store to piggyback on.

Recorded rather than quietly fixed. It is the third correction of this session from the same root cause: I reasoned from an assumption about where software runs instead of reading it. The first was the compat adapter, the second the hard-window guard, this the third.

The rule, now added to the discipline: before claiming a component reuses something, confirm the two share a process. "It's in our stack" is not "it's in our runtime."

2. What this changes in the plan — two stages, and one is improved

Stage 5 (memory) — the adoption argument weakens, the design requirement stays

I had argued cortex/memory/ was un-gappable cheaply because agent/memory_provider.py is a working ABC we already run. That is only usable as a specification, not as an import — Heart cannot import a Hermes internal it does not run inside.

So Stage 5 is genuinely a build, informed by Hermes' design rather than powered by its code. What survives, and it is the valuable part:

• the two-tier shape (short / long)
• the frozen snapshot at session start, which respects the prompt cache
• and Hermes' documented multi-writer defect — "don't point two agent processes at the same home directory... two writers sharing one home will compound each other's entries" — which is a spec-level lesson, freely usable

This makes Stage 5 bigger than the plan assumes. It should be flagged, not absorbed silently.

Stage 6 (cost) — better, not worse

The OpenCode boundary now defines the Arms surface rather than sitting inside it. And the ledger's "record where the request lands" is now literally true: the one place every Heart call passes is its own executor. That is the strongest possible position for Mira's per-attempt billing_instrument field, and for her "a blocked task accrues zero spend" ruling.

Stage 2 (A2A transport) — unchanged, and now clearly the spine

Three units, all communicating via A2A. Heart on SolOSV3 + Brain on Hermes means the transport is a genuine process boundary, not an internal call. That is exactly what A2A v1.0 is for, and it makes a2a-sdk 1.2.2 the right call rather than merely the official one.

3. One thing the topology makes concrete: Heart is the only greenfield unit

Young said "we are focused on Heart Unit" and the topology explains why. Pulse and Brain are Hermes processes and work. Heart is the unit that has never run on its own foundation.

And the consequence for the whole plan: every "adopt from live Hermes" essence in the plan — skills progressive disclosure, memory two-tier, the stuck rule, live steering — is adopt as specification. None of it is adopt as code, because Heart does not run inside Hermes.

That is a materially different plan from the one I presented when I said "adopt their essences so we don't have to rebuild from scratch." The essences are real and they are worth adopting. But "from scratch" is more true than I let on, because the reuse is knowledge reuse, not code reuse.

4. Recorded, not smoothed

I would rather write this down plainly than let "we can adopt Hermes' memory provider" stand in a design doc as if it meant an import. It means: read their design, copy the shape, write it ourselves, and test it. Which is still cheaper than inventing it — and is not the same as free.

Not verified

• Whether V3's sixth database is the right shape at all — with Heart outside Hermes, it may want SQLite+FTS5 like Hermes, or something simpler. Undecided.
• Whether Heart needs session persistence at all — if a Heart task is claim→execute→report, its state may be entirely the task record, and a separate session store may be unnecessary. That would make the sixth database avoidable after all, for a different reason than I claimed. Worth deciding before Stage 0 assigns it a home.
• The interaction between Brain-on-Hermes and Heart-on-V3 over A2A has not been designed — three units communicating via A2A implies a routing and discovery story that the plan covers for Brain→Heart only.