Capability proposal: agent-initiated sub-sessions (client-rendered agent threads) #2444

Proposal. A capability for agents to spawn sub-sessions that the CLIENT renders as native threads/todos — e.g. session/new { parentSessionId, title } invoked agent→client (or a session/child_created notification the client acknowledges), with the child's updates riding the existing session/update stream.

Why. Multi-agent workflows (planner + parallel workers) are a growing agent shape. Today the wire only lets the human initiate sessions, so an agent's parallel lanes can only surface as text/tool-call content inside ONE thread — the client's native parallel-agents UI (e.g. Zed's https://zed.dev/docs/ai/parallel-agents) cannot represent work the agent itself parallelizes, because the UI's unit (a thread) can only be created by the user.

Evidence. devflow (a deterministic workflow engine running as an extension on the pi agent) fans out fenced worker sessions per task — exactly the shape Zed's parallel-agents page describes (own context, own progress, stoppable) — but over ACP the lanes are invisible as threads. Adapters currently work around it by listing persisted worker session files in session/list (inspectable, not live) and mapping step states onto the plan rail; live native threads with per-thread stop controls need protocol support.

Scope note. This is deliberately file-and-forget: the ask is capability discussion, not a specific schema. Happy to iterate here if there's interest.