[Feature] Treat subagents as first-class observable sessions: attach, monitor, manage individually

[kaile9]

What feature would you like to see?

Make subagents first-class observable sessions: while a subagent (or swarm member) runs, the user should be able to attach to it like a session — watch its live event stream, and manage it individually (stop / steer / resume) — instead of it being an opaque one-shot call that only reports back at the end.

Today:

• A background Agent task exposes only its output buffer. (feat(agent-core): stream live subagent events into background task output buffer #667 and PR feat(agent-core): stream live subagent events into background task output #2130 add a live text transcript to that buffer — but it is still a log you poll, not a session you can attach to.)
• Foreground subagents render progress only as a transient grouped card; once it scrolls away there is no way back to the subagent's own timeline.
• Swarm members (AgentSwarm) are worse: they never register background tasks at all, so there is no per-member output, no per-member status, and no per-member stop — see Swarm无法查看进度 #1957 ("Swarm无法查看进度").
• Management is all-or-nothing: interrupting cancels every sibling; you cannot stop or steer one subagent.

Related existing work: #667 (live task output), #1957 (swarm progress), PR #1139 (/agents status command), PR #1210 (session debugging timeline), PR #1645 (stop individual swarm members from web UI). None of them offers attach-to-session semantics; this request is for the missing primitive underneath all of them.

Implementation sketch (from reading the source)

The pieces mostly exist; what is missing is exposing them per-subagent:

1. Event source — every subagent already emits AgentEvents (turn.started, thinking.delta, tool.call.started, …). In-process subscription exists (Agent.onEvent, added by the feat(agent-core): stream live subagent events into background task output buffer #667 fix); on the wire, kap-server's sessionEventBroadcaster already fans out session events, and every subagent has a stable agentId (session metadata, subagent.spawned events). Add an agent-scoped subscription (transcript subscribe_v2 recently landed for sessions — the same channel filtered by agentId gives a live subagent transcript for free).
2. Roster — the live subagent roster is already carried in session snapshots (fix(kap-server): carry the live subagent roster in the session snapshot #1623) and the web agents dock (fix(web): dedupe background subagent rows in the agents dock #1754). Promote it to a first-class list in the TUI (the direction PR feat(tui): add agents status command #1139 takes with /agents) where each entry opens the attach view.
3. Attach view — render the agent's AgentEvent stream with the same components the TUI already uses for the main agent (the redesigned subagent card, feat: redesign the subagent card #1345, and the vis timeline, feat(vis): full session debugging — tasks/cron, execution timeline, retries & tool progress #1210, are prior art). Attach/detach is a pure view operation; the subagent keeps running either way.
4. Management — steer = Agent(resume=agentId, ...) (exists today); stop = the same abort path TaskStop uses for agent tasks, extended to swarm members by wiring each SubagentBatch attempt controller to a member id (PR fix: stop individual swarm members from the web UI #1645 does this for the web UI).

Suggested first increment: (1) + (2) read-only — a /agents panel where selecting a running subagent shows its live transcript. That alone closes #1957's "did it hang?" problem and needs no new control surface.

Additional information

Filed after a source read of packages/agent-core (v1) and kap-server — I'm not a regular contributor, so the sketch above may miss a simpler seam (for example, reusing the background-task output streaming from #667 instead of a new subscription channel). Very happy to adjust the proposal around whatever shape maintainers prefer.

[kwadraten]

Support this proposal. The immediate need is better observability and per-agent control, but I think the underlying problem may be architectural: Kimi Code might eventually need an Akka/Akka.NET-like agent control model with stable AgentRefs, per-agent mailboxes, explicit parent-child relationships, independent lifecycle management and supervision. Now, agent identity and control are fragmented across agentId, task IDs, tool-call IDs, swarm batches and UI projections, which is why attach, stop, resume, failure handling and reconnect logic keep being reimplemented separately.

The main benefit would be true asynchronous coordination. A coordinator Agent should be able to keep supervising multiple child Agents, receive their progress and completion messages, and dynamically route new user requirements to selected children without interrupting unrelated work. Codex has adopted a similar actor-like approach with stable agent identities, hierarchical relationships, FIFO mailboxes and parent-child completion messaging, and this enables the root Agent to remain active while other Agents continue working. Kimi Code already has much of the substrate in v2—independent Agent scopes, event buses, stable IDs and persisted wire logs—so this does not require introducing Akka itself, but these semantics should become a shared primitive underneath Agent, AgentSwarm, background tasks, ACP and kap-server.

Some context on why I’m bringing this up: Today, while working on my codebase with Codex (v26.727.51351) and Kimi Code (v0.31.1), I noticed a stark difference in how they handle task dispatching. When Kimi Code was assigned parallel tasks using the kimi-k2.7 model, it initially only spawned a single subagent, failing to trigger the expected Agent Swarm. In contrast, Codex seamlessly controlled each subagent individually and dynamically dispatched targeted prompts to them on the fly. Curious about this behavior, I dug into the source code for both platforms. Seeing how Codex handles subagent orchestration reminded me of the Actor model in the .NET ecosystem—specifically Akka.NET and F#'s MailboxProcessor.