You Need an Agent Dashboard Now

The promised shape of AI-assisted development was simple: tell an agent what to do, receive code, become mysteriously available for hobbies. The shape that arrived is more operational. One agent is editing a branch in the cloud, another is waiting for permission in a terminal tab with the emotional posture of a stalled printer, CI is failing on a pull request you forgot it opened, and somebody has asked the agent to “keep going” without defining what “going” means. Congratulations: you do not need another agent first. You need a dashboard.

The dashboard is not a command center

Do not build a miniature air-traffic-control display because you own a second monitor and recently learned a charting library. An agent dashboard has one job: answer three questions before you open Slack. What is running? What is blocked? What is now my problem?

GitHub’s agents panel is already a decent version of this for Copilot cloud-agent work: it exposes sessions across repositories and lets you inspect progress, token usage, session length, logs, follow-up prompts, and stop/archive controls. GitHub’s personal dashboard can also surface recent agent sessions, their logs, tasks, and resulting pull requests. That is a useful product direction, even if the phrase “personal dashboard” makes it sound as though your agents will soon ask how your weekend was.

The important bit is not that the screen exists. It is that the unit of work is visible and interruptible. A session without its issue, branch, pull request, CI result, and next human decision is not observable work. It is a very articulate background process.

Use the pull request as the receipt

Make every agent that changes code produce, or eventually produce, a pull request. The PR is where the organization already knows how to ask useful questions: what changed, what tests ran, what failed, who approves it, and whether it is still attached to reality. An agent transcript is useful for diagnosis; it is not a delivery artifact. Reading 400 lines of tool calls to discover that an agent changed three files is how an otherwise healthy engineer starts thinking fondly about fax machines.

For cloud agents, start tasks from a tracked issue and require a short completion note in the PR description: scope completed, tests run, known omissions, and any decision it made that was not explicitly in the task. GitHub permits assigning an issue to Copilot; when it finishes, it creates a pull request and requests review. That gives the work a durable owner, a visible queue, and a review point instead of another browser tab with an optimistic spinner.

Make one small terminal view for the work that escapes the web UI

Not every agent will report to the same place. Claude Code sessions are local and resumable by session ID, which is excellent when you want to return to a particular line of reasoning and less excellent when six terminals are all called “main.” Keep local work deliberately boring: one terminal pane per active task, a branch named for the issue, and a text file or task tracker containing the session ID and the intended outcome.

# Watch required checks on the current PR every 10 seconds
gh pr checks --required --watch --interval 10

# List the most recent workflow runs with enough information to spot trouble
gh run list --limit 10 \
  --json status,conclusion,displayTitle,url \
  --jq '.[] | "\(.status)\t\(.conclusion // "-")\t\(.displayTitle)\t\(.url)"'

This is not glamorous, which is why it works. GitHub CLI supports JSON output for recent workflow runs, and its PR-check watcher accepts an interval in seconds; the documented default is 10 seconds. Ten seconds is frequent enough to notice a failed check, and infrequent enough that you do not spend the entire afternoon observing automation like it is a rare bird.

Put hard limits on parallelism

Your dashboard needs a number called “active agents,” and for an individual developer that number should usually be small. Start with two code-changing agents at once: one task you actively expect to review soon, plus one genuinely independent background task. This is not a benchmark or a moral truth. It is a defense against opening five pull requests that all touch the same auth helper and discovering that parallelism has invented a new kind of merge conflict.

Some products make large concurrency technically possible. Cursor’s Background Agents API documents support for up to 256 active agents per API key, while charging background work at the selected model’s API rates. Treat that as capacity, not an invitation. A commercial kitchen can own 256 knives; it still does not assign all of them to a single onion.

Track states, not vibes

Use five states and make them mutually understandable: queued, running, needs input, needs review, done. “Thinking,” “working hard,” and “almost there” are not states. They are the linguistic equivalent of a loading bar that pauses at 97 percent and begins to negotiate.

• Queued: the task exists, has acceptance criteria, and has not started.
• Running: the agent has a branch or session and a bounded objective.
• Needs input: it cannot safely proceed without a decision, credential, reproduction detail, or scope change.
• Needs review: code and evidence exist; a human must evaluate the diff and checks.
• Done: merged, closed, or explicitly abandoned with a reason.

If an agent remains in running for longer than the attention you intend to give it, inspect it or stop it. “Running” is not evidence of progress. It is evidence that billing, compute, or both have discovered a new place to be.

What an agent dashboard is bad at

A dashboard can show that work exists. It cannot make vague work less vague. It cannot tell you whether an agent chose the right abstraction, whether a passing test proves the behavior you care about, or whether five apparently independent tickets are actually one product decision wearing a trench coat. GitHub’s enterprise controls can filter sessions and retain audit events, which helps with visibility and compliance; it does not turn the audit log into engineering judgment.

Use the dashboard to reduce context switching, not to outsource ownership. The useful morning view is short: two active agents, one PR awaiting review, one red CI run, zero mysteries. Anything more ambitious is how the tool that was meant to simplify your developer dashboard earns a dashboard of its own.