06-reference/research

cross session messaging phdata fde delivery

2026-08-21·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
cross-session-messagingphdatafde-deliveryharnessgoverned-perimeter

Cross-session messaging on a client engagement: a coordination tax cut, an egress question, and a playbook chapter

The question

Verbatim: "How would native cross-session messaging (Claude Code v2.1.224+) apply to phData FDE delivery work — parallel backend/test/migration sessions on a client engagement — beyond the internal support-agent-fleet use already implemented?"

Raised as an unfollowed thread in [[2026-08-10-alphasignal-claude-code-cross-session-auto-mode]], which flagged the feature as "worth a look for the phData harness work (parallel backend/test/migration sessions)" and then never came back to it. The founder's phData role is DSA + TAL; FDE is the delivery framing used in that orbit.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

First, the answer to the question as asked, and it is narrower than the question implies. Cross-session messaging is a coordination-tax cut on parallelism the founder can already get from worktrees and agent view. It removes the human as the relay wire between terminals. On a code-shaped engagement the three shapes where it earns its keep are, in descending order of value: (1) long-running job to watcher — a migration validation, dbt full-refresh, backfill, or test suite reports completion via notify_when_idle, one shot, no polling, and critically no token spend in the watched session; (2) contract-drift warning across worktrees — the "schema migration landed, column is tenant_id, rebase is safe" message, aimed at the single failure mode practitioners name most often; (3) decision hand-off — one session settles a question another is blocked on. Shapes (1) and (2) are worth wiring. What it does not do is raise the number of workstreams one accountable human can stand behind, which the vault already settled at 2-4 foreground. Anyone reading "sessions talk to each other" as a capacity unlock is reading it wrong.

Second, and more useful: the feature's availability is an environment fact, not a version fact, and that reframes it from a productivity tip into a delivery-risk item. The setup plan already recorded the shape of this surprise once — Claude Code installed, auto mode absent. Cross-session messaging has strictly more ways to be silently off: managed-settings deny rules that produce no visible change in /status; a privacy-hardened corporate image setting DISABLE_TELEMETRY or DO_NOT_TRACK, which turns the feature off as a side effect nobody intended; native Windows; a devcontainer that isolates the session from the host; and — the one most likely to bite in a Snowflake/AWS-heavy consultancy — Bedrock or Claude Platform on AWS as the provider, where the feature does not exist at all. Assumption, not established fact: I do not know phData's or any client's provider routing, managed-settings posture, or OS image, and nothing in the vault records them. The actionable version is a single line: on any new box, run /list-agents (alias /peers) before designing anything that assumes it, and if a send doesn't arrive, read the settings files rather than the status pane. That check costs ten seconds and it is exactly the class of finding the perimeter playbook is made of.

Third, the one thing to explicitly rule out before someone reaches for it. Cross-machine messaging is technically supported and would let the personal-box Ray and a phData work-box session talk to each other in one step. That is a direct breach of the founder-decided air-gap, it routes client-adjacent content through Anthropic servers, and it is the kind of convenience that gets adopted before it gets adjudicated. If a work-box session is ever stood up, isolatePeerMachines: true belongs in its settings on day one — not as a governance gesture but because the setting is one-way (any scope can turn it on, no lower scope can turn it off), which makes it a control the founder can also hand a client as a deliverable-grade recommendation. That last point is the interesting one: isolatePeerMachines, crossSessionInbound: refuse, and the SendMessage/ListAgents deny pair are three concrete, checkable knobs an architect can put in a client's agent-governance section. Very few people are writing that section yet.

Fourth, where the actual leverage is, which is not the founder's keystrokes. [[2026-06-04-harness-patterns-ray-to-phdata-work-agent]] already named the product: a locked-down-corporate-deployment playbook, extracted upstream from the field work. Cross-session messaging under managed settings is a new chapter of that playbook, and it is a chapter with unusually good timing — a DSA/TAL whose job is telling enterprises how to operationalize agent fleets now has a primary-source-grounded answer to "how do we govern agents that talk to each other," complete with the exact settings keys, the silent-failure modes, and a working reference implementation on his own machine. The fleet architecture already built (manifest, per-agent handoffs, fleet-status/ files, accept-inbound, traffic rules, deliberate exclusion of a standing critic) is the demo. That is a positioning asset with a much longer half-life than saved keystrokes on a migration, and it maps directly onto the Organizational Intelligence framing rather than onto billable delivery hours. Housekeeping that falls out of this: the fleet manifest still carries a caf-architect line, and the CAF name was retired 2026-08-10 — the rename to an OI-aligned name is a one-line change worth making before the label ossifies.

Why this is in the vault

Closes the "worth a look for the phData harness work" thread left open in the 2026-08-10 AlphaSignal note, and supplies the two inputs the stalled [[2026-05-30-phdata-work-agent-setup-plan]] needs before it can move: a pre-build availability check for the work box, and a decided position on cross-machine messaging (rule it out; set isolatePeerMachines: true) that keeps the founder-decided air-gap from being eroded by a one-line convenience.

Open follow-ups

Related

Sources

Vault

Web