Skip to main content

Fleet Instant Comms: Deploying Agent-to-Agent Messaging to a New VPS

Audience: Lady Mac (and any future fleet agent). Owner: Lady Mac post-retirement. Purpose: stand up the SSH instant-messaging pipeline between any two fleet boxes with one command, and PROVE it works with measured evidence.

The standard (non-negotiable)​

A directed test (deposit + ask the peer to reply) proves the pipe works. Only an unattended canary proves the channel works — the peer's own loop picks up mail with no prompt, no nudge, no human. Never report "verified working" without canary latency numbers. (PICKUP-LATE > 15 min = degraded.)

The two one-liners​

1. Angus's line (unavoidable, ~10 seconds, at VPS creation)​

Nobody can bootstrap access to a machine that has no access path. When creating a new VPS, seed Lady Mac's public key:

echo '<ladys-pubkey>' >> ~/.ssh/authorized_keys   # run on the NEW VPS as its admin user

(Lady's current pubkey: ~/.ssh/id_ed25519.pub on vmi1539125 — key: fleet seed category in her .read notes; Angus holds a copy in his password manager.)

2. Lady's line (everything else, fully autonomous)​

~/.hermes/scripts/fleet_comms_deploy.sh <label> <user>@<host> [ssh-opts]
# e.g.
~/.hermes/scripts/fleet_comms_deploy.sh worker2 root@203.0.113.7 -i ~/.ssh/seed_key

The script does BOTH sides end-to-end:

  • generates a dedicated keypair, installs pubkeys both directions
  • creates ~/.hermes/verify/fleet-inbox/ (+ .read markers) on the new node
  • deploys fleet_inbox_monitor.py (change-detector) + FLEET_COMMS_PROTOCOL.txt
  • registers the hermes cron "Fleet Inbox Pickup" (--monitor-script, */5, agent wakes ONLY on new mail) and issues a detached gateway restart so the job loads (required — CLI-created cron jobs are not picked up by a running gateway)
  • installs an initiator-side canary + system cron (every 15 min)
  • runs the tests:
    • T1 transport (scp round-trip) — must PASS
    • T2 pickup — unattended canary, polls up to 12 min, reports measured latency
  • writes ~/.hermes/verify/fleet-inbox/fleet-inbox-setup-report-<label>.txt

Exit criteria printed at the end: SETUP COMPLETE - channel operationally verified only if T2 shows PICKUP-OK.

Architecture (what runs where)​

ComponentWhereMechanismWhy
Message inboxboth nodes~/.hermes/verify/fleet-inbox/*.msgscp-depositable, per-turn checked
Change-detectornew nodefleet_inbox_monitor.pymarks read via .read/ markers, outputs digest
Agent wake-upnew nodehermes cron --monitor-script */5wakes agent only on output change; system-cron log files are NOT read by any agent (learned 2026-10-11 the hard way)
Gateway restartnew nodedetached systemctl --user restartCLI-created cron jobs load only at gateway start
Canaryinitiatorsystem cron */15measures true pickup latency, logs PICKUP-OK/LATE
Secretsnever via inboxpassword.linksplit-channel delivery

Failure modes seen in the field (do not re-learn these)​

  1. Log-file monitor — a system cron that writes a digest to a file nobody's agent reads. Bookkeeping ≠ wake-up.
  2. Two consumers — if both a system cron and the hermes cron run the same monitor, one marks mail read before the other sees it. Exactly one mechanism may consume the inbox: the hermes cron.
  3. Job not loaded — hermes cron create on a running gateway writes jobs.json but the scheduler doesn't see it until restart. Verify via executions.db rows appearing for the new job id.
  4. Directed test overclaim — a reply to "please reply" only proves transport. The canary is the proof.

Verification commands (after any change)​

# initiator side: canary log with real latencies
tail ~/.hermes/logs/fleet-comms-canary-<label>.log
# new node side: job actually executing?
python3 - <<'EOF'
import sqlite3
c = sqlite3.connect('/home/<user>/.hermes/cron/executions.db')
for r in c.execute("select job_id,status,started_at from executions order by started_at desc limit 3"): print(r)
EOF
  • FLEET_COMMS_PROTOCOL.txt (deployed to every node's ~/.hermes/verify/)
  • fleet_comms_canary.sh (single-peer reference implementation, Sleeper + Lady Mac)
  • Operations: fleet-email-verification.md (dual-channel verification protocol)