Agent View: Manage Multiple Claude Code Sessions from One Screen

Agent View exposes an API to spawn, monitor, and kill agent sessions. You POST a job (agent name, input, worktree path) to the dispatcher; it queues the job, executes it, and streams updates to the dashboard. You can cancel a running agent, see its real-time output, and mark a job as approved/rejected before execution.

The dispatcher maintains a job queue. When you submit 100 jobs, they don't all run at once. Instead, they wait for a free slot (based on max_concurrent_agents setting). This prevents resource exhaustion and lets you manage throughput.

The dashboard is a web UI (or API endpoint) that shows all active jobs, their status (running, queued, completed, failed), elapsed time, token usage, and output tail. You can click on a job to see full output or kill it mid-execution.

The backend maintains a job store (in-memory or database) that tracks state. Every state change (queued → running → done) broadcasts to WebSocket clients. This means the dashboard updates in real-time without polling.

For critical workflows, you might want human approval before an agent runs. Agent View supports approval gates. When you POST a job with requires_approval: true, it enters the queue but doesn't execute. An approver reviews the input (and optionally the agent's plan), then approves or rejects via the dashboard.

Once approved, the job moves to execution. Once rejected, it's marked as skipped. This pattern is essential for infrastructure changes, financial transactions, or any high-stakes automation.

Every API call costs tokens. With 50 agents running, your bill multiplies fast. Agent View logs token usage per session and aggregates it. At the end of each job, it records input_tokens and output_tokens. The dashboard shows total tokens (and cost estimate) across all sessions.

You can set a hard budget cap: if cumulative cost exceeds $X, stop accepting new jobs and alert the team. This prevents runaway spending if an agent gets stuck in a loop.

At 10 concurrent agents, Agent View runs on a single machine. At 100, you need horizontal scaling: multiple dispatcher instances, a shared job store (database), and a message broker (Redis/Kafka) for job distribution.

The pattern: agents submit jobs to a queue (e.g., Redis list). Dispatcher instances pop jobs, execute them, and post results back to a results queue. The dashboard subscribes to the results queue and updates in real-time. This decouples job submission from execution, letting you scale execution independently.

With many agents, bugs compound. An agent that retries indefinitely can drain your budget in hours. Observability is how you catch it. Log every state transition (queued → running → done), every API call, every error. Expose metrics: job throughput (jobs/min), avg latency (seconds), error rate (%), token efficiency (tokens/job).

Key metrics to watch: job queue depth (if growing, dispatcher is too slow), max concurrent jobs (if stuck at limit, increase capacity), error rate (if spiking, agents are hitting bad state).

Agent View is most powerful when integrated into your team's workflow. Slack bot that posts job results into a channel. GitHub Actions that dispatch jobs and report status. Jira tickets auto-updated with agent output.

Example: A GitHub Actions workflow for pull requests. On PR open: dispatch a code-review agent to review the PR. Results posted as a GitHub comment. Approver checks the comment; if satisfied, approves the agent job, which can then auto-merge or notify the team.

This closes the loop: developer pushes PR → agent reviews → team approves → merge. All automatic, all tracked.