[FEATURE] View-level meta-agent in the Agents View — conversational oversight across running sessions

Title: [FEATURE] View-level meta-agent in the Agents View — conversational oversight across running sessions

---

Problem Statement

The new Agents View makes it easy to run many background agents in parallel. It does not give me a counterpart for overseeing them.

As soon as I have 5–10 agents in flight, I'm the bottleneck: scanning statuses, opening each session to read what it's actually doing, noticing two agents working on overlapping files, deciding which to kill, remembering which I last messaged and what I asked. Existing surfaces (status pills, "Ready for Review" buckets, the per-session chat) help inside one agent, but the across-agents layer is just my eyes.

What's missing is a counterpart at the Agents View itself — an agent I can talk to whose job is the view, not the work.

Proposed Solution

A first-class view-level meta-agent that lives in the Agents View (not inside any single session), with:

1. Read access across sessions — the running agents' charters, recent assistant messages, last tool calls, status, idle time, branch, cwd. (Same data the view already renders, plus enough transcript context to summarize.)
2. View-level tools — list_agents, focus(id), send_message(id, text), kill(id), restart(id), diff(idA, idB) (e.g. file overlap, charter overlap), route_permission_request(id, allow/deny).
3. An oversight-tuned system prompt and skills — not a coding agent. It's a manager: triage, conflict detection, "who's stuck on what", "draft a status update for me", "this one and that one are touching the same file — recommend".

Conversation surface lives at the view itself — not behind a session. Opening the Agents View opens a chat with this meta-agent.

Why this has to be view-level (not a sub-agent or a skill)

• A sub-agent spawned from inside session X can only see session X. The whole point is cross-session.
• A skill in one session can't drive view-chrome affordances (focus another agent's pane, route its permission prompts, kill it).
• Wiring this by hand per-team via shared filesystem and tmux is what we (and others, judging from related issues) already do — it works, but every team rebuilds it.

Alternative Solutions

• Manual scanning — current state. Doesn't scale past ~5 agents.
• Per-team orchestrator agents (we have Mark/Zisser; #42721 describes a similar pattern) — works inside one session as a pipeline driver, but doesn't see across the view.
• Read-only dashboards (#24537) — surfaces state, no conversational layer to act on it.
• Unified inbox (#45609) — solves cross-agent permission queueing, which is one slice of oversight; doesn't generalize to "summarize what all my agents are doing" or "are any of these stepping on each other".
• Custom sublists (#58390) — better organization of the existing view; still leaves the human as the summarizer/router.

This FR is the conversational/agentic layer that complements all of the above.

Use Case Examples

• "What's everyone doing right now?" → one-paragraph summary per running agent, sourced from each session's recent assistant messages.
• "Anything blocked?" → list of idle-but-not-done agents with the reason (waiting on permission / asked a question / hit an error / silent).
• "Are any two agents working on the same files?" → diff cwd/branch/touched-paths and call out overlaps.
• "Kill anything working on the slack-poc branch." → enumerates matches, asks once, kills.
• "Tell agent X that the new spec is in docs/foo.md and have it re-read." → routes a message into X's session without me focusing the pane.
• "Draft a status update for my team from what the agents shipped today." → reads commit messages across worktrees, drafts.

Additional Context

• Related issues (adjacent, none in this framing): #45609 (FM-style permission inbox), #42721 (built-in dev orchestrator pipeline), #24537 (agent hierarchy dashboard), #58390 (customizable sublists), #57603 (resume idle agents from picker).
• Preview-feature gating notes: #58284, #58383 apply equally to this surface if shipped.
• I currently approximate this with a per-team "manager" persona spawned ad-hoc inside one session; it can't see across sessions, can't route permissions, and can't drive the view — which is exactly what makes the Agents View itself the right home.