Interactive agent as a critical-path step owner never completes (missed 'owner completion decision')

[khaliqgant]

Summary

When an interactive agent OWNS a critical-path step, it does the work and is "released", but the engine never registers the step as completed — the step stays `running` indefinitely, no timeout/retry fires, the workflow hangs. Workers (`interactive: false`) do NOT have this problem. Goal: an interactive agent in a relayflow should complete reliably, like a worker does.

Evidence (factory build-out, 2026-06-16)

• codex owner of an `implement` step (pipeline shape): target files written + `self-reflection.md` present (verification target satisfied), agent "released worker via relaycast", but step stuck `running` 15–30min, no live agent process, zero further activity. Reproduced across 4-wide, 2-wide, and solo runs.
• opencode owner: hard-failed with `owner completion decision missing`.
• Same family surfaced in the conversation shape as a lead↔worker idle stall (see sibling issue).

Root cause (suspected)

The "owner completion decision" is delivered over the broker PTY / relaycast and silently drops (delivered≠flushed). No fallback to completion exists, so the step never advances. Broker auto-restart (#10) does NOT fire — it's not a transport error (self-heal events = 0).

Proposed fix (any/all)

1. Treat a PASSED step `verification` (file_exists / exit_code) as completion evidence even when the channel decision didn't arrive.
2. Honor the underlying process exit as a completion signal for owner steps (workers already do this).
3. Per-step inactivity watchdog (sibling issue) so a missed decision retries instead of hanging.
4. Ack + redeliver the owner-completion message over relaycast.

Workaround in use

`wf.agent(name, { interactive: false })` → spawnAgent, completes on process exit. Reliable, but loses channel coordination — which defeats the point of interactive agents.

[khaliqgant]

Enabling fix shipped: AgentWorkforce/relay#1129 — "feat(spawn): add task-exit mode" (merged 2026-06-16).

This is the broker-side primitive that fixes the root cause here. It adds a task-exit spawn mode (--spawn-mode task-exit / --exit-after-task, plus an MCP add_agent task-exit option that appends a post-task /exit), so an interactive (PTY-backed) agent exits when its task completes → the broker/engine gets a deterministic process-exit completion instead of the flaky "owner completion decision" message that silently drops.

This is exactly the reliable signal the interactive: false worker workaround already relies on (spawnAgent → process exit), but task-exit keeps the agent on the channel during the task. So it's the proper fix: interactive owners stay interactive AND complete reliably.

To close this issue, relayflows must ADOPT it:

1. Have spawnInteractive (the broker spawn relayflows issues for interactive step owners) pass --spawn-mode task-exit / --exit-after-task (or the MCP add_agent task-exit option).
2. Bump to the @agent-relay/broker release that contains #1129.

Pairs with #14 (unify spawnInteractive/spawnAgent completion semantics) and #12 (inactivity watchdog as the backstop if a /exit is ever missed).

[khaliqgant]

The broker already EMITS the completion signal — relayflows just isn't consuming it. (relay/crates/broker)

• protocol.rs:525 AgentExit / :529 AgentExited
• pty_worker.rs:730,943,1225 send agent_exit frames with an exit payload
• swarm.rs:888 handles "agent_exited" | "agent_exit" | "agent_released"

So even for an interactive (PTY-backed) step owner, the broker reports a clean agent_exit/agent_released event when the agent's process ends. The fix for this issue is largely: relayflows' spawnInteractive path should treat the broker's agent_exit/agent_released frame as step completion (instead of waiting only for the "owner completion decision" that drops). That works today without task-exit mode; #1129 (task-exit) makes the agent end deterministically after its task so the agent_exit fires at the right moment. Much cheaper than net-new broker work.