Babysitter goes blind after spawn: route its own PR's review/CI events into its session instead of dropping them

[khaliqgant]

Summary

The babysitter is spawned event-driven and then goes blind. It receives no events for the PR it owns, so it has to decide on its own when to go re-read the mount. Its reaction latency to a review comment or a red check is bounded by whenever it next chooses to look — not by when the event arrives.

Everything needed to fix this already exists in the orchestrator. It's a routing gap, not a missing capability.

What happens today

1. The orchestrator already receives the events. LIVE_GITHUB_ISSUE_GLOB = ${GITHUB_ISSUE_ROOT}/** where GITHUB_ISSUE_ROOT = '/github/repos' (factory.ts:138,150), subscribed at factory.ts:577. That terminal ** covers reviews, review comments, issue comments and checks. The inline comment at :571-573 says as much: "already covers the PR change events the babysitter consumes."

2. The orchestrator knows which babysitter owns which PR. #babysitterPr is keyed by issue key (factory.ts:3792).

3. And then it returns. #ensureBabysitter (factory.ts:3791-3795):

async #ensureBabysitter(record: InFlightIssue, prRef: {...}): Promise<void> {
  this.#babysitterPr.set(record.issue.key, { repo: prRef.repo, prNumber: prRef.prNumber, path: prRef.path })
  if (this.#babysitterSpawned.has(record.issue.key)) {
    return                      // <-- every post-spawn PR event dies here
  }
  ...
}

Once a babysitter exists, every subsequent PR event for that issue refreshes internal state and is dropped. The babysitter is never told.

4. So the prompt tells it to poll. templates.ts:123: "Read the PR diff, CI checks, and review threads via ${mountRoot}/github/repos." That's a pull, on the agent's own initiative, with no signal that anything changed.

Worth being precise about a nearby line, because it reads like this is already solved: templates.ts:92's "delivered to you as an <integration-event> system message injected into your session — wait for it, do not poll" applies only to the Slack dispatch-thread question flow (asking a human a question mid-task). It does not apply to PR events.

Why this matters

The babysitter is the right design — a fresh long-lived agent holding the issue spec as the definition of done, able to DM the implementers and reviewer. It's identity-scoped to exactly one PR, which is the ideal subscriber. It just has no way to be woken.

Practical consequences:

• Latency is unbounded and non-deterministic. A reviewer leaves a comment; the babysitter finds out whenever it next loops.
• It burns tokens re-reading the mount to discover that nothing changed.
• #sweepPrStateCompletions is disabled when the babysitter is enabled (factory.ts:999-1005, "Disabling it here is what makes the babysitter path webhook-driven rather than polled") — which is true of the orchestrator's completion sweep, but the babysitter's own awareness is still a pull. The polling didn't go away; it moved into the agent.

The pieces already exist

• Injection: #waitForInjectedAndSubmit → #submitInjectedTask (factory.ts:3536-3600) delivers via relay broker DM then writes \r to the PTY to submit. Retry/confirmation policy at factory.ts:169-172 (INJECTION_MAX_ATTEMPTS = 6, INJECTION_CONFIRMATION_TIMEOUT_MS = 90_000). Used today at :2920, :3495, :3531.
• Normalization: relayflow-registry.ts:19,203 already normalizes to a github.pull_request.review_submitted shape.
• Dispatch: #dispatchRelayflowEvent (factory.ts:938) exists but is opt-in via #relayflows, and no pull_request policy is registered anywhere — it's only exercised in tests (factory.test.ts:4233,4297).

Proposal

Where #ensureBabysitter currently early-returns on an already-spawned babysitter, inject the event into that babysitter's session instead of dropping it, via the existing #submitInjectedTask path.

Scope it to the events the babysitter actually acts on:

• pull_request_review.submitted (especially changes_requested)
• pull_request_review_comment.created / issue_comment.created on its PR
• check failures (red → actionable; green → probably not worth a wake)
• merge conflict / base-branch divergence

Design notes:

• Only its own PR. The orchestrator already maps PR → issue → babysitter, so no broadcast and no in-agent filtering.
• Coalesce. A review with eight inline comments shouldn't be eight injections. The per-integration spec builder already uses coalesceMs: 750 (src/subscriptions/specs.ts:245-247) while the live subscription uses coalesce: 'none' (factory.ts:577) — worth reconciling deliberately rather than by default.
• Don't interrupt destructively. Injection submits to the PTY immediately; a babysitter mid-git rebase shouldn't be derailed. Consider deferring while a critical section is in flight.
• Keep the pull as a backstop. Events can be missed (the subscription is from: 'now', so a reconnect window drops events); the babysitter should still be able to re-read the mount. Event-driven for latency, pull for correctness.
• Untrusted content. Review bodies are attacker-authorable and the babysitter holds push credentials. Whatever gets injected should be fenced rather than concatenated raw into the session (see AgentWorkforce/cloud#2671 for the same concern in personas).

Two viable shapes: register a pull_request relayflow policy and use the existing #dispatchRelayflowEvent path, or inject directly from #ensureBabysitter and leave relayflow for later. The direct path is smaller and doesn't require committing to the relayflow abstraction.

Acceptance

• A review comment on the babysitter's PR reaches its session within seconds, with no polling.
• Events for other PRs never reach it.
• A multi-comment review produces one wake, not N.
• Injection while the babysitter is mid-critical-section doesn't corrupt its work.
• The babysitter can still self-heal by re-reading the mount if an event is missed.

Related

• AgentWorkforce/cloud#2670 — the same gap as a general primitive. This issue is the concrete, highest-value instance of it.
• AgentWorkforce/cloud#2671 — fencing untrusted provider text before it enters an agent's context.

[khaliqgant]

Verified this against the code. The core claim holds — #ensureBabysitter sets #babysitterPr and then early-returns on an already-spawned babysitter, so every post-spawn PR event refreshes orchestrator state and is dropped. The babysitter is never told. Three corrections for whoever picks this up.

Confirmed on origin/main @ af1499b

• The orchestrator already receives the events. LIVE_GITHUB_ISSUE_GLOB = '/github/repos/**' (factory.ts:154), subscribed at :632 with { from: 'now', coalesce: 'none' }. The quoted comment is verbatim at :629-631.
• The drop. #ensureBabysitter at factory.ts:4141, exactly as quoted.
• The prompt tells it to pull. Read the PR diff, CI checks, and review threads via ${mountRoot}/github/repos. — src/dispatch/templates.ts:169 and :190.
• #sweepPrStateCompletions is gated on babysitter.enabled (factory.ts:1053), with the quoted "webhook-driven rather than polled" comment. The issue's sharpest point stands: the polling didn't go away, it moved into the agent.
• Injection machinery exists. #waitForInjectedAndSubmit (factory.ts:3886), INJECTION_CONFIRMATION_TIMEOUT_MS = 90_000 (:172), INJECTION_MAX_ATTEMPTS = 6 (:175).
• No pull_request policy is registered outside tests. #dispatchRelayflowEvent (:994) is opt-in (if (!relayflows) return); every .register('github.pull_request.*') lives in src/dispatch/relayflow-registry.test.ts.
• The coalesce inconsistency is real. coalesceMs: 750 at src/subscriptions/specs.ts:246 vs coalesce: 'none' at factory.ts:634.

1. Line numbers are off — this was written against a working tree, not main

The citations match a local checkout of the factory/67-reviewer-hang-fix branch (e.g. templates.ts:92 is exact there), not origin/main. main has since advanced (99611d8 → #79 → #80), so the factory.ts numbers are off by ~4-46. Current values are listed above. (specs.ts:245-247 is spot-on — that file didn't move.)

2. The templates.ts:92 caveat has been overtaken by #79

The quoted line — "delivered to you as an <integration-event> system message injected into your session — wait for it, do not poll" — was accurate when written, but #79 (7815b7e, "Release agents while awaiting human clarification") deleted it. The flow now reads:

After sending the marker, stop work and finish your session normally. Do not wait or poll: Factory will release the whole team and resume it from session memory only after the first human reply.

The paragraph's conclusion is unaffected — integration-event delivery still doesn't cover PR events, and the babysitter is still blind — but the evidence for it no longer exists on main. Worth striking so it doesn't read as a live quote.

3. The proposal should reconcile with #79's model

This is the substantive one. The proposal is to wake a live babysitter session via PTY injection. #79 just moved the clarification flow the other way: release the team, resume from session memory when the human replies. If release/resume is the emerging pattern for "agent is waiting on a human", then "keep a long-lived session alive and inject into it" is the model #79 is retreating from — and PR review comments are the same shape of problem (agent idle, waiting on a human-authored event that may be minutes or hours away).

That doesn't sink the issue; latency still matters and the babysitter is still the right subscriber. But the design choice is now three-way, not two:

1. register a pull_request relayflow policy and use #dispatchRelayflowEvent;
2. inject directly from #ensureBabysitter; or
3. release the babysitter on PR-open and resume it from session memory on the first actionable PR event — reusing Release agents while awaiting human clarification #79's machinery instead of standing up a parallel wake path.

(3) also sidesteps two of the design notes: a released agent can't be interrupted mid-git rebase, and there's no long-idle session burning context waiting for a review that may never come. The cost is resume latency and the cold-start path #79 already had to build.

Related: this breaks entirely under placement (#85)

Worth flagging since it constrains the design. With --backend relay, factory dispatch exits immediately after placing the agents — no owned broker, no exit watcher, so there is no orchestrator process alive to route or inject anything (#85). Any wake design that assumes a live orchestrator holding a PTY handle works locally and silently no-ops hosted — the same failure shape as #84. Options (1) and (2) both assume that live process; option (3) is the only one that survives an orchestrator that isn't there, provided the resume is driven by something durable.

Refs: #79, #80, #84, #85, AgentWorkforce/cloud#2670, AgentWorkforce/cloud#2671.