06-reference/research

phdata work agent comms surface decision

2026-07-31·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
phdata-work-agentcomms-surfacechannel-as-stateopen-threadsdecision-memo

Comms surface for the phData work-agent: terminal-direct, and port channel-as-state to a file

The question

Verbatim: "Comms-surface decision for the phData work-agent (terminal-direct vs a channel) — determines whether channel-as-state / open-threads is rebuilt or dropped entirely. Still open in the setup plan."

Context: this is follow-up #4 from [[2026-06-04-harness-patterns-ray-to-phdata-work-agent]], which put "channel-as-state / open-threads" in the NEEDS-REBUILD column with the note that the comms surface itself was undecided. This brief is a decision memo, not a survey.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

The two options, stated precisely

Option A - Terminal-direct. The founder interacts with the work-agent in the Claude Code TUI on the work box, during a session he launched. There is no persistent bidirectional messaging surface. The agent's outputs land in the terminal, on the filesystem, and in the Gmail drafts folder. Attention-getting is local (hooks to a desktop/terminal notification). Cross-session continuity is a local file, not a message history.

Option B - A channel. The agent posts into, and reads from, a persistent messaging surface, replicating Ray's channel-as-state and open-threads. Sub-variants:

The criteria that actually discriminate

  1. Is the human present while the agent works? (decisive) Ray's channel exists to reach an absent founder across an always-on daemon's lifetime. The phData agent has no lifetime outside a session the founder is sitting in. A channel that reaches someone already in the room is pure overhead.
  2. Is the channel even available under the perimeter? B1 and B2 are blocked or unevidenced. B3 is available. B4 is forbidden. The menu is thinner than "terminal vs Slack" implies.
  3. Does it add an egress path or an unverified-app footprint? Terminal-direct adds neither. Every channel option except a purely local one adds at least one.
  4. What does channel-as-state actually buy, and is a channel the only way to buy it? It buys durable open asks across a boundary the human crosses. That need is real for a session-scoped agent (a session ends; the open ask should not evaporate). But it is satisfied by a file. The channel was never the point; the durability was.
  5. Reversibility. Terminal-direct is a non-decision in cost terms: adopting it forecloses nothing, and B3 remains available later for the price of a script.

The recommendation

Terminal-direct (Option A). Drop channel-as-state as a network mechanism; port only its function to a local file. Drop the open-threads cooldown machinery entirely. Confidence: HIGH.

Confidence is HIGH on the negative half (do not build a channel) because four independent lines - founder-stated agent shape, the perimeter map, the governance posture, and the SOP's own stated precondition - all converge, and because no channel option survives availability screening except the one nobody was proposing. Confidence is MEDIUM-HIGH on the specific substitute stack below, which is a design proposal, not a founder decision.

The substitute stack, all local, all consistent with "connectors die, filesystem survives":

  1. Attention: a Notification hook. The agent_needs_input and agent_completed matchers are exactly the two moments a channel would have carried. The doc's terminalSequence example emits a desktop ping with no network surface at all. On macOS, osascript -e 'display notification' is the more portable path if the work box's terminal does not speak the OSC sequences listed (Terminal.app is not among the terminals the doc names - verify in 30 seconds, do not assume).
  2. Continuity: a local open-threads.md in the work-agent workspace, written on SessionEnd and read at session start. This is channel-as-state with the channel replaced by a file. Same function - an open ask survives the boundary and gets resurfaced - with none of the egress.
  3. The async outbox already exists and is not a chat surface: the Gmail drafts folder. The MVP is the channel. Drafts accumulate while he does other things and he reviews them on his own clock. That is precisely the asynchrony a chat channel would have been built to provide, and it is already in the plan with human-gated send intact.

Explicitly dropped, not rebuilt: the 60-minute cooldown, the 9am-9pm firing window, the 🅿️ parking marker, the anti-double-fire rule, and the morning-brief resurface. Every one of these is a wall-clock construction for an absent human. Porting them to a co-located session agent would be cargo-culting Ray's shape onto an agent that does not have Ray's problem. This is a clean confirmation of the two-layer model in [[2026-05-10-harness-moat-two-layers-portability]]: the pattern (durable open asks) ports; the mechanism (a channel plus a cooldown) does not.

What would flip this

UNVERIFIED - what he would need to check

The uncomfortable framing worth saying out loud

The reason this question sat open for two months is not that it is hard. It is that the project it belongs to stopped. The comms-surface decision is a 5-minute call that unblocks nothing, because the thing it would unblock (the email-draft MVP) has not been attempted since 2026-05-31. The honest action is to write the decision line into the setup plan so it stops surfacing as a research question, and then treat "does the phData work-agent get built at all, or was it superseded by the CAF role" as the actual live question. That second question is a founder call, not research.

Why this is in the vault

This closes follow-up #4 from [[2026-06-04-harness-patterns-ray-to-phdata-work-agent]] and supplies the missing decision line for [[2026-05-30-phdata-work-agent-setup-plan]], which currently contradicts itself on the comms surface. It also converts one row of the PORTS-CLEANLY / NEEDS-REBUILD ledger from "TBD" to "DROP the mechanism, PORT the function," which is a reusable rule for the locked-down-corporate-deployment playbook the FDE positioning work depends on: agent comms surface is chosen by operator presence, not by preference - a co-located session agent needs a notification hook and a state file, not a channel.

Open follow-ups

Related

Sources

Vault (all also linked above under Related):

Web:

Note on sourcing discipline: the Claude Code hooks page and the vault documents cited above were fetched/read directly in this run. The Slack and agent-landscape items are from search-result summaries and linked pages I did not open individually; they are cited as corroborating context, not as primary-text verification.

Follow-ups (gated candidates)

None — no researchable follow-ups survive the gates.

Rejected and why: (a) "stand up the notification hook / open-threads.md substitute" and "write the decision line into the setup plan" are build tasks, not research — they belong on the Notion board; (b) "confirm phData's Slack app-approval posture / Workspace edition / AI policy" are blocked on corporate access we do not have and are listed above as UNVERIFIED checks for the founder, not research questions; (c) the presence-based generalization is already derived in this brief's synthesis and would restate it.