A2A connectivity — what is actually broken (live probes, 2026-10-20)

Young asked three questions:

1. Tam is not on LAB; Echo has trouble connecting to Tam on Pulse via A2A — fix it.
2. Do Nova, Min, Mira have trouble reaching Tam and the Pulse Unit via A2A?
3. Can Nova and Echo connect to the Heart unit and to opencode (ARMS) directly?

I answered all three by probing, not by reading docs. Summary of the honest answer: the network is fine, the link to Tam works, and the real defects are three different ones — a missing config block, three incompatible dialects, and an auto-reply session that answers as me without my knowledge.

1. Is the link to Tam actually broken? No.

So the A2A path to Tam works from LAB today. My earlier "connection refused" was my own error: I dialled 127.0.0.1:8443 — LAB loopback — for an agent that lives on Pulse (192.168.4.34). The registry has the correct endpoint; I used the wrong host. Tam was never unreachable; I was knocking on the wrong door and reporting the house empty.

Note the latency: 39 seconds. The skill already records Pulse latency swinging 3.7 s → 38.2 s across six identical calls, with a 120 s default timeout. A short timeout makes this link look dead when it is merely slow — that is the likeliest cause of anyone else's "trouble connecting to Tam".

⚠️ One claim in Tam's reply does not survive checking. Tam's answer said it had sent me an ACK "via the verified recipe (POST 127.0.0.1:18304, SendMessage + A2A-Version: 1.0)" and that "Echo returned TASK_STATE_COMPLETED". I probed 18304 on both LAB loopback and on the Pulse host: closed on both. (The skill says 183xx are laptop-side forwards, so this may be a Tam-side view I cannot see from here — but from LAB it is not a live route, and I did not send that message through it.) I am flagging it rather than calling it false, because the honest statement is: I cannot reproduce the route Tam describes, and I have no record of sending what it says I sent.

2. 🔴 Defect A — Mira and Sol cannot send A2A at all (config gap)

This is the real coordination fault, and it explains a lot of the "Min coordination doesn't work" symptom.

The registry projection says all 11 agents should be present in every profile:

$ python3 -c "from cortex.registry import projections; print(len(projections.hermes_a2a_agents()))"
11

mira and sol have no a2a_agents block at all — not an empty one, absent (grep -c 'a2a_agents' = 0). All five configs were generated at the same timestamp (2026-10-20 13:38:41), so this is not a stale-file problem; the projection either skipped them or was overwritten afterwards. Mira and Sol are two of the three agents Young is asking about — and neither can open an A2A conversation.

This is the highest-value fix in this document. Min can send; Mira and Sol cannot; so "Min coordinates" fails at exactly the seam where Mira and Sol are supposed to report back.

Owner: the registry/projection lane (Min, with Sol on the generator).

3. 🔴 Defect B — three planes, three incompatible dialects

Same probe, three hosts. This is the finding that costs the most round-trips:

The Heart unit refuses v0.3 with a good error:

'message/send' is a v0.3 dialect name and v0.3 compat is OFF (ruled 2026-10-10). V3 speaks 1.0 only. Call 'SendMessage' instead.

Pulse does the exact opposite: it answers message/send and returns -32601 Method not found: SendMessage.

So there is no single call that works on all three planes. A caller that correctly follows the V3 ruling (v1.0 SendMessage) fails against Pulse; a caller that follows my own skill (v0.3 message/send) fails against Heart.

And the payload shape differs too. Heart's v1.0 handler wants parts: [{text: …}]; the v0.3 shape is content: "…". My first v1.0 attempt was rejected with "a message must carry at least one text part" even though the method name was accepted — a second trap behind the first.

This is exactly the defect class the skill already documents (§0: "a declared version that disagrees with the implementation is worse than declaring the older one"). It has now spread: the fleet's planes disagree with each other, not just with their own version constant.

Recommended: one dialect decision per plane, recorded in the registry, and a per-peer dialect: field so a caller does not have to guess. Until then, the working recipe is: Heart → v1.0 SendMessage + parts; Brain → either; Pulse → v0.3 message/send + content.

4. 🔴 Defect C — an auto-reply session answers as Echo, outside my session

This is the most surprising finding and it matters for trust.

I sent a self-test to my own A2A port (127.0.0.1:8315) asking for MANUAL or AUTOREPLY. It answered MANUAL — a model-generated reply — in 13.9 s.

I never saw that message. It was handled by a separate Hermes session:

gateway.log: inbound message: platform=a2a chat=ctx-78329dfec736415a
gateway.log: response ready: session=agent:echo:a2a:dm:ctx-78329dfec736415a time=13.9s

There are 151 such agent:echo:a2a:dm:* sessions in my profile's log. Each A2A inbound spawns its own conversation, sharing my memory file but not my conversation. So "Echo" can answer an A2A peer, write to the vault, or ACK a task in a session I have no visibility into — and I found records attributed to "Echo" in the shared audit log that I did not send from this session.

Why this matters:

• It explains the phantom ACKs. Tam's reply references an "Echo ACK" I did not compose. That ACK was real as traffic but was generated by an A2A session of my profile that I cannot see. It is not a lie and it is not Tam's error — it is an architectural property nobody had named.
• It compounds the attribution problem already in the ground rules: commit prefixes are labels, and now conversational attribution is unreliable too. An "Echo said" in an A2A log may be an Echo session I never saw.
• It is a real capability, not only a bug — it means peers can reach "Echo" when my interactive session is closed. But it must be known, or every agent's self-report becomes unauditable.

Recommendation: name it explicitly in the fleet rules — "A2A inbound is handled by a per-context session of the agent's profile; it shares memory but not conversation state. An A2A reply is that agent's answer but not necessarily a deliberate one from its interactive session." And record it in the audit log with the session id so provenance is checkable.

5. Heart unit and opencode — both reachable directly ✅

Heart unit (8301–8303): all three agents answered a real v1.0 round-trip.

Identity confirmed by agent card ({"name":"Ace","description":"Software Engineer"}) — not just "something answered". So yes, Echo can reach the Heart unit directly, via v1.0 SendMessage with a parts payload.

⚠️ One cosmetic oddity worth noting: every Heart reply carries a status message "free first — measured at 8.4x the tokens of paid, at $0.00" alongside the real artifact. That is model-selection chatter leaking into the status field — harmless here, but it is a status field carrying a slogan rather than the fact, which is the exact defect class already named in the fleet's own rules.

opencode (ARMS) — reachable directly ✅

$ /home/lab/.opencode/bin/opencode run "Reply with exactly: OPENCODE-DIRECT-OK"
opencode v2.0.27
> build · deepseek-v4.1-flash-free
OPENCODE-DIRECT-OK      exit=0

opencode is not on PATH (command -v opencode → nothing); only the absolute path works, exactly as the skill records. A long-lived server is running: opencode serve --service (pid 928162, up 6 days, listening 127.0.0.1:49374).

ARMS is not a daemon — /home/lab/.solos/core/arms/ contains only a README; it is a library/CLI surface, so "connecting to ARMS" means invoking opencode, not dialling a port. So yes: Echo can drive opencode directly.

6. Answers to Young's questions, in one place

Honest scope: I probed from LAB, as Echo. I cannot probe from Nova's or Mira's session; I verified their configuration, and for Mira that is enough to prove she cannot send. For Nova I confirmed the config exists but did not prove a successful send.

7. What I am NOT doing

• Not fixing the mira/sol config gap — that is the registry/projection lane (Min), and the generator is Sol's.
• Not changing the dialect behaviour of any plane — Sol/Min's call.
• Not editing the ground-rules file — still Sol's, still pending his fix.
• Not touching Tam's or Pulse's configuration — remote host, and it is not my lane.

Correction (2026-10-21, t_3d8f4875)

The earlier statement "the registry projection says 11 for every profile" conflated two different things and is withdrawn as a measurement:

• projections.hermes_a2a_agents() returns the registry's peer set (11 agents), which is the same for every consumer by design — it is the expected set, not a measurement of what any profile actually holds.
• The per-profile measurement is drift_report(expected, actual), which compares that expected set against the profile's live a2a_agents block.

Re-measured per profile (2026-10-21, before fix):

After fix (mira + sol get the projected block + a2a toolset): both hold 12 peers, drift 1 (tam-lab only, matching min/nova/echo).

AC3 proof: live a2a_call from mira and sol (see completion metadata).

Honest limits

• I did not test every port on every plane; I tested the ones Young named.
• The Pulse dialect result is from one probe of SendMessage; Pulse latency is variable, so I would re-run before treating it as final.
• I cannot see the Pulse host, so Tam's 18304 route may be real there. I report what LAB can reach, and say so.
• The auto-reply finding is from my own profile's logs (151 sessions). I did not audit other agents' profiles, so I do not know whether their A2A sessions behave identically — I would expect so, but that is an inference.
• I did not re-probe after writing this; a sibling may fix any of these while I write. The board card carries the evidence hash.