Problem
The Agent type of agent needs a way to delegate work into additional sessions. Today, a supervising/original agent can reason about tasks, but it cannot spin up visible first-class sessions for separate lines of work, track what those sessions are doing, or inspect their full execution and responses. Users also cannot naturally ask the original agent what a spawned session is doing or use it as the control point for those sessions.
Proposed solution
Allow an Agent agent to create child sessions with explicit task instructions, context, and names. Those spawned sessions should appear as normal sessions in the app and be automatically sent to the LLM to begin work without requiring the user to manually open and start each one.
The creating/original agent should retain awareness of every session it spawned, including status, current activity, final response, transcript, tool execution history, and any errors. Users should be able to ask the original agent about any spawned session, get progress or results, and control the session through the original agent where appropriate, such as sending follow-up instructions, pausing/canceling, or resuming.
Spawned sessions should remain first-class user-visible sessions while also preserving parent/child relationships so both the UI and runtime can answer questions like “what is this session doing?” and “which agent created it?”
When an agent spawns other sessions, that relationship should be apparent in the UI. Sessions that belong to the same parent/child group should share a visible border color. The first spawned group should use the user's currently selected primary theme color. If the user starts another agent that creates its own child sessions, that separate group should get its own random, stable border color. This grouping state should sync correctly in the cloud app as well, with complete local/cloud parity.
Success criteria
- An
Agent agent can request one or more new sessions with task instructions and optional names/context.
- Spawned sessions appear in the normal sessions UI and are automatically dispatched to the LLM.
- The original agent can list its spawned sessions and inspect each session’s status, current activity, final response, transcript, tool execution history, and errors.
- Users can ask the original agent what any spawned session is doing and receive accurate current or final information.
- Users can control spawned sessions through the original agent for supported actions such as follow-up instructions, pause/cancel, and resume.
- Parent/child session relationships persist across app restarts in the app-data project state, not legacy
.xero/ repo-local state.
- Parent/child session groups are visually apparent in the sessions UI with a shared border color on all related sessions.
- The first spawned session group uses the current selected primary theme color, and later independent spawned groups receive their own random, stable border colors.
- Session group relationships and border colors sync correctly in the cloud app with complete parity between local and cloud experiences.
- Tests cover runtime session spawning, parent-child relationship persistence, status/result retrieval, control actions, user-visible session-list behavior, visual grouping metadata, and cloud sync parity.
Area
Agent runtime
Problem
The
Agenttype of agent needs a way to delegate work into additional sessions. Today, a supervising/original agent can reason about tasks, but it cannot spin up visible first-class sessions for separate lines of work, track what those sessions are doing, or inspect their full execution and responses. Users also cannot naturally ask the original agent what a spawned session is doing or use it as the control point for those sessions.Proposed solution
Allow an
Agentagent to create child sessions with explicit task instructions, context, and names. Those spawned sessions should appear as normal sessions in the app and be automatically sent to the LLM to begin work without requiring the user to manually open and start each one.The creating/original agent should retain awareness of every session it spawned, including status, current activity, final response, transcript, tool execution history, and any errors. Users should be able to ask the original agent about any spawned session, get progress or results, and control the session through the original agent where appropriate, such as sending follow-up instructions, pausing/canceling, or resuming.
Spawned sessions should remain first-class user-visible sessions while also preserving parent/child relationships so both the UI and runtime can answer questions like “what is this session doing?” and “which agent created it?”
When an agent spawns other sessions, that relationship should be apparent in the UI. Sessions that belong to the same parent/child group should share a visible border color. The first spawned group should use the user's currently selected primary theme color. If the user starts another agent that creates its own child sessions, that separate group should get its own random, stable border color. This grouping state should sync correctly in the cloud app as well, with complete local/cloud parity.
Success criteria
Agentagent can request one or more new sessions with task instructions and optional names/context..xero/repo-local state.Area
Agent runtime