Agents window: group delegated sessions across connected AHP hosts
- Dominant language
- TypeScript
- Stars
- 193k
- Forks
- 42.4k
- PR merge metrics
- PR metrics pending
Description
## Feature request
When an agent session delegates work by creating a session on another connected Agent Host Protocol (AHP) host, show that downstream session as part of the originating workflow in the Agents window.
## Scenario
I want to run an always-on cloud agent host as a coordinating ("quarterback") development machine. It delegates platform-specific work to other AHP hosts, for example Windows, Linux, and macOS runners. My client VS Code connects directly to all of these hosts so it can observe each authoritative session live.
Today the Agents window can show the coordinating session and the downstream sessions under their respective hosts, but the delegation relationship is lost:
```text
Quarterback host
Orchestration session
Windows host
Windows validation session
Linux host
Linux implementation session
```
The orchestrator knows that each downstream session belongs to a particular task/tool call, but VS Code presents those sessions independently. This makes a distributed workflow difficult to navigate even though all of its sessions are already available to the client.
## Desired experience
Represent a cross-host parent/child or delegation relationship in the Agents window:
```text
Quarterback host
Orchestration session
Windows validation
Remote session on windows-runner
Linux implementation
Remote session on linux-runner
```
The Agents window would project the dashed delegation relationships into its hierarchy while continuing to observe each session directly from its authoritative host:
```mermaid
flowchart LR
C["Client VS Code
Agents window"]
Q["Quarterback AHP host
Parent session"]
O["External orchestration service
MCP server + AHP client"]
W["Windows AHP host
Worker session"]
L["Linux AHP host
Worker session"]
C -->|"AHP: live observation"| Q
C -->|"AHP: live observation"| W
C -->|"AHP: live observation"| L
Q -->|"MCP tool call"| O
O -.->|"AHP: create and drive session"| W
O -.->|"AHP: create and drive session"| L
```
### Delegation mechanism in this scenario
AHP does not perform the agent-to-agent delegation. In this example:
1. The quarterback agent invokes an external orchestration MCP tool.
2. The MCP service acts as an AHP client to select a worker host, create its session, send the task, and monitor it.
3. The service returns the downstream host/session identity to the quarterback.
4. The client VS Code, independently connected to every host over AHP, renders each authoritative session live.
This request does not ask AHP to standardize MCP or orchestration semantics. It asks for an implementation-neutral way to publish or register the resulting relationship so the Agents window can group and navigate sessions it already receives from connected hosts.
Selecting a downstream node should open the native session supplied by its authoritative host. The parent should not need to proxy or duplicate the remote transcript. Live state, tool calls, terminal activity, changesets, approvals, and reconnect/replay should continue to come directly from the downstream host.
When one host is offline, preserve the relationship and show an appropriate disconnected state. When it reconnects, resume the normal AHP session view.
## Possible relationship data
The exact representation is open for design, but the relationship may need enough information to identify:
- originating host and session/chat
- downstream host and session
- originating tool call or orchestration task ID
- optional display label or relationship kind
This is intended as display and navigation metadata, not a definition of agent-to-agent coordination semantics. MCP, custom orchestrators, or other implementations could create the relationship, while the Agents window renders it consistently.
## Why this belongs in the Agents window
A custom tree view could correlate task IDs and deep-link to sessions, but it would duplicate the session navigation experience. The Agents window already connects to multiple AHP hosts and renders their authoritative sessions; it is the natural place to present their workflow relationship.
## Related but distinct requests
- #277568 asks to surface a delegated cloud/background session inline inside the originating local chat. This request instead concerns the Agents window hierarchy when both the parent and downstream AHP hosts are connected directly: selecting the child should open the downstream host's authoritative native session rather than embedding or proxying it in the parent transcript.
- #326533 asks for richer live status for native subagents of a session. This request concerns separately hosted AHP sessions that are not native child chats and therefore currently lose their orchestration relationship in the multi-host session list.
- microsoft/agent-host-protocol#353 models alternate turn-history branches within one chat. This request needs a relationship between separate sessions on separate hosts; it does not concern branching or restoring a chat's history.
These ideas could share UI affordances, but the identifying scope here is: **cross-host relationship metadata plus Agents window grouping/navigation, while each downstream host remains the source of truth for its session.**
Contributor guide
Research direction
Start by tracing the Agents window's multi-host session list and the AHP session identity flows described in the issue. Define how relationship metadata is registered and rendered, then verify that selecting a child opens its authoritative host session and that offline and reconnect states preserve the grouping.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100