[Feature] Composer cannot steer subagent sessions (queue-only) — please expose a steer channel for subagents

[alex04130]

Problem

Opening a subagent session in the Web GUI, the composer can only QUEUE input — there is no way to steer (interrupt the running turn with fresh input). For a long-running child, a human must wait for the current turn to finish before their message is even seen.

Root cause (source-verified)

1. dsh-client-ui-conversation lib/client.js (line ~3503): keyboard.submit(resolveSubmitMode(running, gesture, subagent === null)) — steeringAvailable is hard-coded to subagent === null, so every subagent session resolves to queue-only.
2. The ordinary API prompt path does NOT reject subagent sessions: prompt -> turnAgentFor -> agentFor carries no subagent-ownership check (that check lives in ensureSession, which other endpoints use). So agent.steer on a live child is reachable through the API — only the UI entry is closed.

Evidence that the agent loop itself supports it

A host-side plugin CAN steer a live subagent: calling agent.steer(message) on a running child works (we use it from a cross-session messaging plugin today, and the child observes it mid-turn). The blocking point is purely the composer UI gate.

Suggestion

Drop the subagent === null gate (or expose an explicit steer option) so the composer can steer when the target child is live, falling back to queue when it is not running. This matters for interactive supervision: humans opening a child session mid-run should be able to redirect it immediately, the same way they can for top-level sessions.

[zoahdev]

Good gap. The composer today routes to the main agent; subagents are queue-only by design (they run in their own loop). A steer channel is feasible without touching the scheduler:

1. Define a subagent/steer session event (or reuse request/header-style events with a subagent scope) carrying a steering message + optional turn budget.
2. The subagent loop already consumes session events; a steer message becomes a normal user-turn injection into that session, so no new execution model is needed.
3. UI surface: the composer can stay single, with a subagent selector that targets the steer event at the selected child session - the pattern used by our dsh-subagent tooling and by Codex-style delegation UIs.

The risk to design around: interleaving steer messages with an in-flight subagent turn must be explicit (queue vs immediate), and the parent session needs a read-only view of child progress so steer targets exist before the child finishes. Happy to write this up as an RFC draft in the community docs if useful.

[alex04130]

Thanks — this matches what we've observed empirically. We have a host-side cross-session plugin that calls agent.steer(message) on a live subagent today, and the child picks it up mid-turn, so "steer = ordinary user-turn injection into that session's loop" aligns exactly with runtime behavior. The gap is purely that the composer has no entry point.

A few notes on the design risks you flagged, from our usage:

queue vs immediate must be explicit. We'd prefer the existing composer semantics: default queue, explicit gesture for immediate (steer), mirroring the top-level queue/steer modes — that keeps interleaving predictable and matches what top-level sessions already expose.

Parent-side progress view. Agreed — today a parent only learns about a child at settlement, and the "read-only view of child progress" you describe is the missing piece that would make steer targets discoverable before the child finishes. A minimal projection (status + last few assistant/tool events, summary-level) into the parent session would already cover most supervision needs.

Happy to help with the RFC draft: we can contribute the empirical details (steer-on-live-child works today, the exact UI gate at dsh-client-ui-conversation line ~3503, the ownership-check locations) and we're actively building a client-side steer-button prototype against the existing API, which can serve as a reference implementation for the UX you described.

One question for the RFC: should subagent/steer carry turn-budget semantics (one-shot injection) or be a plain message admission? Our usage suggests plain admission with an explicit delivery mode (queue/steer) is sufficient — budgets can stay a scheduler concern.

[alex04130]

Thanks @zoahdev — both ideas (a subagent/steer session event and a subagent picker UI) match the shape we were heading toward. We went ahead and implemented a zero-hack client plugin against the CURRENT API, and it works — but the experiment surfaced two layers of limitation worth capturing here.

What works today

• The API layer does not reject subagent steering, but the shipped InputBar gates it (steeringAvailable = subagent === null).
• A client plugin can restore the parent-composer semantics on subagent sessions without patching the bundle: we capture Ctrl/Cmd+Enter on the official textarea and route it to agent.steer on the host. The official InputBar stays fully intact (context meter, attachments, model select, hard-stop button).
• Verified end-to-end: the steer message arrives within the SAME turn — the subagent sees it the moment its current tool returns and changes course accordingly.

Layer 1: Session.prompt drops mode for subagent sessions

Client-side, Session.prompt(content, mode) routes continuable subagent sessions through api.subagents.prompt and discards the mode argument entirely — every prompt on a subagent session becomes followup/queue semantics. So the public session API literally cannot steer a subagent today; we had to bypass it with a private host-side agent.steer call. Suggest passing mode through (or exposing a dedicated steer primitive) for subagent continuations.

Layer 2: steer is a step-boundary injection

agent.steer(msg) → inbox next-step; the only claim point is agent/pre-step, reached after the current step (including tool execution) completes. Verified from logs: a steer sent mid-bash sleep 240 was appended to the session log at the exact millisecond the tool returned — it sat in the inbox the whole time. Between tools / while thinking, steer takes effect on the very next step (seconds); during a long tool call it waits for the tool. Only cancel() (hard stop, discards turn progress) cuts a tool short.

Request: a soft way to inject into a turn whose tool call is still running would make human-in-the-loop steering complete — either an interruptible-tool contract (cancel({ keepInbox: true })-style soft abort that re-enters the loop with the pending steer), or the subagent/steer event you proposed wired to the same primitive the parent composer uses, instead of the hardcoded gate.

[Electricitysheep]

Composer 只能 queue 子代理会话，不能 steer——子代理控制通道缺失（能排队不能指挥），和 #1442/#2006（子代理模型选择/继承）一起看，子代理交互体系还在补。

第 9 章子代理章节有相关记录：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/09-mcp-subagent-workflow.md

[alex04130]

感谢您的回话，我的插件https://github.com/alex04130/dsh-forge
实现了ctrl+enter的劫持并通过底层插件api发送跨回话消息实现打断发送

[Electricitysheep]

这个实现很实用——Ctrl+Enter 劫持 + 底层插件 API 跨会话消息打断发送，正好补上「Composer 只能 queue 不能 steer」的缺口（社区方案先行，官方 #1517 的 managed jobs 也在这方向）。

已收录进手册生态章节（子代理交互家族）：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/07-ecosystem.md

[alex04130]

我的team和bridge插件给了一个有趣的研究
https://github.com/alex04130/dsh-forge/blob/master/docs/EMERGENCE.md
他们自动涌现出阶段效果和合作效果

[Electricitysheep]

EMERGENCE.md 这个研究有意思——多 agent 协作自动涌现出阶段效果和合作效果，这正是第 9 章"Agent 系统化"的进阶命题（单 agent → +MCP → +子代理 → +工作流 之后，多 agent 涌现是下一步）。

如果方便，可以把涌现观察整理成可复现实验（几个 agent/什么任务/观察到的阶段），我们手册第 9 章 + 第 15 章生态报告可以作为"多 agent 协作"案例收录，社区也能复现验证。

[zoahdev]

@alex04130 实现得利落——"API 层不拒绝子代理 steering、只是 InputBar 门禁挡住"这个结论很有价值，说明缺口在 UI 门禁和事件通道，不在调度器。

如果走官方通道，建议把这条整理成 RFC：subagent/steer 会话事件（steer 消息 + 可选 turn budget，注入子代理会话后按普通 user-turn 处理，不需要新执行模型）+ 移除 InputBar 的 steeringAvailable 门禁。方向和 #1517 managed jobs、#1473/#2006 子代理模型选择/继承一致，可以一起对齐。

我可以按官方 RFC 格式起草一版（事件 schema + UI 行为 + 兼容性说明），需要的话说一声，我们来来回回把细节磨干净再挂 RFC 编号。

[zoahdev]

RFC 草稿来了，兑现承诺：https://github.com/zoahdev/dsh-docs/blob/main/docs/rfc/subagent-steer-channel.md

核心三点：

1. subagent/steer 会话事件（sessionId + steer + 可选 budget），按普通 user-turn 注入子代理会话，不动调度器；
2. InputBar 门禁改成运行时查询"当前 parent 的活子代理会话"，queue 仍是默认，steer 是显式动作（多个子代理时出 picker）；
3. 与 Run workflows as managed jobs with progress and cancellation #1517 managed jobs / [Bug] A single corrupted session log prevents the whole workspace from booting (loader entry "workspace" fails to apply) #1473/Bug Report: Subagent 未正确继承父 Agent 的模型配置 #2006 模型选择继承对齐，不冲突。

兼容性：不改 session-log 格式，老客户端忽略未知事件；你那个 client plugin 已经证明消息路径在现有 API 上存在——这个 RFC 只是把它标准化。验证计划写了三级（e2e 注入落位 / API 级 typed error / UI picker），open questions 也列了（是否持久化、工具调用中的 budget 语义、要不要 ack 事件）。

有问题直接在这个 thread 拍，我们磨到能挂 RFC 编号为止。