Single-host fleet? — measured trade-offs (2026-10-17)

Min's question (via Young): "move all agents onto a single host — save infrastructure cost, better control?" Short answer as the ops lane: yes for 8-9 of our 11 agents today; keep Pulse (me, Eva, Eve) where the user-facing=g traffic is; keep prod's headroom ready for tenant stacks. The measured numbers follow.

1. What consolidation actually saves (measured)

Our agent runtime footprint (measured 2026-10-13, live ps):

• Hermes agent core ≈ 173 MB; A2A server ≈ 23–38 MB → ~0.2–0.25 GB per idle agent
• 8 agents (Brain 3 + Heart 5) ≈ ~1.6–2 GB RAM total

Host costs today:

Honest saving: LAB VM is Likely already paid (existing box) — moving agents doesn't remove a lease unless we retire a host. The real saving of "one host" = one gateway process, one upgrade lane, one set of keys, one dashboard surface — operational, not infra. Where it genuinely saves: avoid running a THIRD host for agents when prod has room.

2. The control argument (Min's second point) — fragmentation IS our current disease

Evidence from today's own ops:

• LAB gateway binds 3 of 8应有的 agent ports; nova/ace/echo absent → peers get HTTP 000 (the outage Young hit).
• Agents are dark differently per host; the tunnels registry is the only full map.
• One host = one place where fleet health is readable, keys live, updates land, logs aggregate.

So Min's instinct is right: fewer hosts = fewer failure domains. The 3-4 site the failure domains come from isn't hardware, it's process spread — gateway versions, key copies, tunnel configs. Consolidation fixes exactly that.

3. The counter-pressures (why not 100% single-host)

1. User-facing Pulse stays with the user: Eva's Telegram reflection + session state + Moomoo feeds + my crons live on the laptop by Young's own design (Pulse-owned daily brief + podcast). Moving them = correctness risk, not cost saving.
2. Tenant stacks need headroom: the commerce product's plan puts Medusa tenants on prod. Compute there is measured: ~4-6 tenant stacks + solos-docs + pulse-site. Adding 8 idle agents (-2 GB) is fine; adding 8 BUSY agents risks the 4-vCPU ceiling during builds.
3. Blast radius: one host dies, every agent dies. Mitigation exists (agents-anywhere packs + dashboard), but consolidation RAISES the value of the dashboard + backup discipline rather than removing the need.
4. Single host egress: all A2A and fleet ops ride the one host's tunnel; if that tunnel dies, fleet is dark — versus today's laptop↔LAB↔prod chain that degrades partially.

4. Recommendation (ops lane)

• Phase 1 (this week): consolidate Heart agents onto LAB (they should already be there — restart nova/ace/echo from the gateway; that's the fix, not migration). Prod stays the tenant/commerce host.
• Phase 2 (with V3 Stage 1/2): registry decides placement — agents become registry entries with a hosts: list; default = all Brain+Heart on LAB; Pulse stays split (user-surface).
• Phase 3 (product-era): if tenant load grows, we add ONE host for tenant stacks (per-tenant compose, as designed); agents stay single-host. Infra cost stays at N=1 for agents regardless of tenant count.
• The dashboard (collectors lane) is the safety net: it shows agent RED when a host dies, wherever they live.

5. Net answer to Min

Yes to consolidation for control and operational cost, with two carve-outs that are about correctness, not sentiment: Pulse agents stay with the laptop (they serve the human's daily surface and work rides local data) and tenant stacks get their own compute when commerce grows. The saved infra = not needing a third agent host; the control win = one gateway, one keys dir, one health surface, one dashboard row per agent.

Open for Min/Young: pick the consolidation host (LAB vs prod) — LAB is already the identity/cortex center so my ops default says LAB; prod keeps the door open for bursts and tenants.