[New Design] Agent Coordination Task Flow

[dauglyon]

Motivation

Multi-agent AI systems are becoming standard infrastructure in scientific computing. An orchestrator agent spawns specialized sub-agents — code generators, data processors, testers, reviewers — and delegates tasks across the fleet. This creates a coordination problem: the human operator needs to understand what work is happening, who is doing it, and what needs their attention — three fundamentally different questions about the same system.

Existing monitoring tools (dashboards, log viewers) collapse these concerns into a single view, forcing operators to mentally reconstruct context. Agent Coordination separates them into purpose-built views connected by bidirectional cross-links, so the operator can fluidly move between perspectives without losing context.

Why three tabs? Each tab answers a distinct question:

• Tasks ("What?") — a kanban board showing work items flowing through their lifecycle. This is the view for tracking progress and spotting bottlenecks.
• Agents ("Who?") — a spawn hierarchy tree showing which agents exist, who launched them, and their current state. This is the view for understanding system topology and agent health.
• Action Required ("What's blocked?") — an urgent queue of items that need human input before agents can proceed. This is the operator's inbox — approvals, questions, errors, resource requests.

These views are not independent pages. They share a persistent status summary bar and side detail panels that stay open and update context when switching tabs. Clicking an agent name in a task detail opens that agent's detail on the Agents tab; clicking a task name in an agent detail opens that task on the Tasks tab. The operator navigates by following relationships, not by memorizing IDs.

Users: Researchers or engineers operating multi-agent AI systems who need to monitor agent activity, track task progress, and respond to agent requests for human intervention.

---

Tab 1: Tasks (Kanban Board)

A kanban board with six columns representing the task lifecycle:

Queued → Blocked → In Progress → Review → Done → Failed

Each task card shows the task title, currently assigned agent (clickable cross-link to agent detail), and elapsed time. No status dots on cards — column position already conveys status.

• One agent per task at a time (sequential hand-offs), but multiple agents can work on a task over its lifetime
• Agents leave comments/state behind on tasks as an activity log
• Clicking a card opens the Task Detail Panel (slide-in from right) showing status, current agent, elapsed time, activity log, state timeline, and any blocking action items

---

Tab 2: Agents (Spawn Hierarchy Tree)

An SVG tree visualization showing the agent spawn hierarchy — who launched who. The root is typically an orchestrator.

Each tree node shows: agent ID, role label (user-defined free-form string), status-colored ring (Idle=gray, Running=blue, Awaiting=orange, Error=red, Complete=green), and a small colored dot badge indicating current task status.

Clicking a node opens the Agent Detail Panel showing status, model, role, current task (clickable cross-link), parent agent, effort metrics (tasks completed + time spent), I/O stream (messages, artifacts, tool calls, errors), child agents list, and pending action items.

---

Tab 3: Action Required (Human Intervention Queue)

A vertical queue of items blocking agent work that require human input — the operator's urgent inbox.

Each item has a type badge with distinct colors:

• Approval (blue) — agent needs permission to proceed
• Question (purple) — agent needs clarification
• Error (red) — agent hit a blocker it can't resolve
• Request (amber) — agent needs a resource or access

Cards show type badge, title, agent/task cross-links, timestamp, description, and an action area with Approve/Reject buttons + text input. Resolved items sink to a muted "Resolved" section. The tab button has a red count badge for urgency.

---

Cross-Linking & Navigation

Bidirectional cross-links connect all three views:

• Task → Agent: current agent link switches to Agents tab and opens that agent
• Agent → Task: current task link switches to Tasks tab and highlights that task
• Action → Agent/Task: agent and task names in action items are clickable
• Task → Action: blocked tasks link to the blocking action item

The side panel persists across tab switches and updates its context automatically.

Status Summary Bar

A single compact row above the tabs with three sections (AGENTS, TASKS, ACTIONS). Each state is a colored dot with count. Tooltips on hover show state names. Red/problem states listed first so issues are immediately visible.

Data Model

• Agents: id, label, role (free-form), status, model, parentId, children, tasksCompleted, timeSpent, I/O stream
• Tasks: id, title, status, currentAgentId, elapsed, activity log (comments per hand-off), state timeline
• Action Items: id, agentId, taskId (nullable), type, title, description, timestamp, status (pending/approved/rejected), response

Constraints: One agent per task at a time. Agents work on at most one task at a time. Agent hierarchy is a spawn tree.

[dauglyon]

Design Directions Under Consideration

Task granularity & the 1:1 constraint — The one-agent-per-task model is intentional. Complex work that involves multiple agents concurrently should be
decomposed into separate task cards. This keeps kanban semantics clean (column = status, card = one assignee) and avoids multi-assign UI complexity. Task
granularity is driven by the agent architecture, not human mental models of "a unit of work."

Subtask grouping — As a future extension, an optional parentTaskId on tasks would let operators group related cards (e.g. all subtasks of "Run Experiment
X"). Parent cards could show a progress chip ("3/7 done") and a focus toggle to filter all views to just that subtree. Deferred from v1 to keep the data
model flat and simple until real usage reveals grouping needs.

Priority scoring for the Action Required queue — Rather than purely chronological ordering, action items should be auto-scored by: type weight (Error >
Approval > Request > Question), number of downstream agents/tasks blocked, and time waiting. The queue should support sort toggles (by priority, time,
agent, task) and pin/snooze so operators can surface what matters and defer what doesn't.

Telemetry in the status bar — Add a fourth SYSTEM section to the status summary bar showing total token usage, estimated cost, and wall-clock time for the
current run. Per-agent token count and cost should also appear in the agent detail panel alongside existing effort metrics. This keeps lightweight
observability inside the coordination view without turning it into a full telemetry platform.

System timeline & replay — A filterable slide-out timeline panel (not a fourth tab) showing all events across agents, tasks, and actions chronologically.
Filters by entity type, agent, task, and event kind (spawn, assign, hand-off, approval, error, completion). Each event cross-links to its entity.
Completed runs should be persistable and loadable for post-hoc analysis — critical for scientific reproducibility.

Agent tree scaling — The SVG spawn tree is appropriate for v1 where most practical agent systems are well under 15 nodes. Collapsible subtrees, a compact
list-view toggle, and zoom/minimap for larger deployments are tracked as future work.

Framework integration & event protocol — Defining how agent systems emit events into this dashboard is critical for adoption but is an engineering concern
separate from the UI/UX design. Should be addressed in a dedicated ticket once the design is finalized.