Repository navigation
[FEATURE]: Agent Activity Panel -- sidebar view for monitoring running background agents #27995
Description
Summary
When orchestrating multiple background agents in parallel (e.g., explore, librarian, oracle), there's currently no way to monitor their status without calling background_output() manually. A dedicated sidebar/panel showing live agent activity would greatly improve visibility into multi-agent workflows.
Problem
Right now, when agents are spawned with run_in_background=true, the user has zero visibility into:
- How many agents are currently running
- What each agent is doing (task description / current step)
- Their status (running / completed / failed)
- Their partial output (live progress)
The only way to check is to wait for a system notification and then call background_output(task_id="...") -- which is a pull-based, reactive model with no live visibility.
Proposed Solution
Add an Agent Activity Panel in the sidebar (similar to a CI/CD pipeline view) that shows all background agents with their real-time status.
Mockup
+- Agents ──────────────────────────────+
| |
| 🟡 explore "Find auth patterns…" | <- click to expand
| 🟡 librarian "JWT security docs…" | <- click to expand
| ✅ oracle "Architecture review" | <- click to see output
| ❌ explore "Find error handlers" | <- click to see error
| |
+───────────────────────────────────────+
Clicking an agent entry expands to show:
- Full task description / prompt
- Live streaming output (if still running)
- Final result (if completed)
- Error details (if failed)
- Start time + elapsed duration
User Story
As a power user running complex multi-agent workflows, I want to see all active background agents in the sidebar at a glance, so I can monitor their progress and click into any agent to view real-time output -- without having to wait for completion notifications.
Acceptance Criteria
- Sidebar panel lists all background agents spawned in the current session
- Each entry shows: agent type, task description snippet, status icon (running / done / failed)
- Clicking an entry opens a detail view with full output
- Running agents show live/streaming output as it arrives
- Panel updates in real-time (no manual refresh needed)
- Completed/failed agents remain visible (dismissible)
Context
This is especially valuable for workflows where 3-5 agents run in parallel (e.g., parallel codebase exploration + external docs research + architecture consultation). Currently the UX feels like "fire and forget" with no control panel.
Related to the overall goal of making multi-agent orchestration more transparent and manageable from the UI.
Activity
wusai2333 commentedon Jul 13, 2026
👍 Strongly support this feature.
When orchestrating multi-agent workflows (parallel explore + librarian + oracle), the lack of real-time visibility into background subagents is a significant UX gap. Users are essentially flying blind after
run_in_background=true— relying solely on system-reminder notifications and reactivebackground_output()polling.The proposed Agent Activity Panel design (CI/CD pipeline style sidebar) is exactly the right approach. The server-side SSE infrastructure (
session.statusevents) is already there; this is primarily a rendering concern.Would love to see this prioritized — it's a key unlock for any serious multi-agent use case.
yukihamada commentedon Jul 30, 2026
I'd like to implement this. Before I start, a quick design check with the core team (per CONTRIBUTING.md):
Proposed approach:
GET /session/:id/background-agentsendpoint (or extend the existing event stream) that lists background tasks with status, agent type, task snippet, start time — sourced from the existing background task registry rather than a new store.Scope for a first PR: read-only panel (list + status + open output). Live streaming of partial output can be a follow-up.
Does this direction match what the core team has in mind, or is someone already working on it? Happy to adjust the design before writing code.
makslanies commentedon Jul 30, 2026
One implementation detail that may prevent this panel from showing ghost agents: make it a projection of a durable execution ledger, not just the live event stream. Each row needs a stable
run_id/agent_id, parent identity, explicit lifecycle transitions, a heartbeat timestamp, and a terminal result; otherwise a disconnect can leave an agent lookingrunningforever even though its process completed or died.VOLY's A2A canvas uses this pattern: nodes are upserted from
pendingtorunning, thencompleted/failed/blocked, with route, duration, cost, files, error, and heartbeat-backed run records: https://github.com/voly-codes/voly/blob/main/docs/backend/a2a.mdFor the proposed read-only first PR, I'd include
staleas a distinct display state even if restart/cancel controls come later. It preserves honest observability without expanding the initial scope.NESTOWL commentedon Aug 14, 2026
I came across this issue after opening a separate feature request for the same general need: #42564.
I agree that the Agent Activity Panel is a great direction, especially for monitoring currently running background agents. One additional UX detail I'd like to highlight is keeping the timing information visible directly in the main conversation/task history, next to each subagent invocation.
For example, after a subagent finishes, the invocation could show something like:
This is slightly different from the purpose of the sidebar:
The latter would be particularly useful when several subagents are executed sequentially or in parallel. It would make it immediately obvious when each agent started and which agents consumed most of the total execution time, without having to open the activity panel again.
Here is a quick mockup of what I had in mind:
I think these two approaches would complement each other nicely: the Activity Panel provides the live control/monitoring surface, while the inline timestamps and durations provide a persistent execution timeline in the conversation history.
metux commentedon Sep 8, 2026
Is there a way to catch that data via a plugin ?
That would be really great for fleeting applications.