Problem / motivation

Hermes is growing beyond a single assistant loop: users can delegate work, run long-lived role/team workflows, invoke named profiles, schedule agents, and connect via CLI/ACP/API server. The WebUI/dashboard should make those actors visible as first-class runtime entities rather than only showing generic sessions or raw sources such as cli, acp, or cron.

Without first-class dashboard visibility it is hard to answer operational questions such as:

• Which roles or standalone agents actually ran for this task?
• Did the Lead delegate to Developer / Validator / Auditor, or do the work inline?
• Which child session belongs to which parent Lead session?
• Which execution mode was used: persistent_role_instance, delegated_subagent, scheduled run, or inline exception?
• Is a role/agent active, idle, stale, completed, blocked, or crashed?
• Where are the role packet, output, validation evidence, and findings artifacts?
• How much token/cost usage belongs to each role/agent?

This is distinct from a generic WebUI/dashboard request: the focus here is observable multi-agent / role-team runtime identity.

Proposed solution

Add first-class WebUI/dashboard support for role-team and standalone agent activity.

Suggested backend/runtime shape:

1. Persist a standard role/agent metadata envelope on sessions and/or session trace records:

   • agent_name / canonical_role
   • agent_kind: lead, role, delegated_child, profile_agent, cron_agent, etc.
   • execution_mode: persistent_role_instance, delegated_subagent, scheduled_role_run, standalone_profile, inline_lead_exception
   • policy_default_execution_mode where applicable
   • parent_session_id
   • role_session_id / stable agent session ID
   • plan_id / work-item ID
   • status: planned, active, idle, completed, blocked, failed, stale, retired
   • profile, source, model, toolsets where safe to expose
   • artifact links: packet, output, evidence, findings ledger
   • last activity / heartbeat timestamps

2. Provide a dashboard API endpoint such as /api/dashboard/agents or an enriched sessions endpoint that returns:

   • active role/agent list
   • parent/child lineage
   • status and last activity
   • token/cost counters
   • artifact pointers
   • role utilization summaries
   • stale/heartbeat warnings

3. Add a WebUI view or dashboard section for Agent / Role Activity:

   • one row/card per canonical role or standalone agent
   • current status, profile/source/model, parent task, last activity
   • links to the session transcript and role artifacts
   • badges for observed role execution vs no observed pass
   • token in/out and cost aggregates
   • open findings / validation status where available

4. Treat the org chart / role registry as descriptive policy, not proof of execution:

   • the org chart says which roles exist and their default policy
   • session metadata/traces prove which roles actually ran
   • the dashboard should visually distinguish “configured role” from “observed role execution”

5. Support standalone/named profile agents as well as role invocations:

   • a process launched as a named profile or standalone agent should be able to register an identity and heartbeat
   • if no metadata is provided, it can fall back to generic source labels without breaking old sessions

Acceptance criteria

• invoke_role / persistent role executions produce WebUI-visible session metadata including canonical role, execution mode, plan ID, parent session, role session ID, status, and artifact links.
• delegate_task child sessions expose parent/child linkage and optional delegated role metadata.
• Named profile / standalone agents can be shown as distinct agents when launched with an explicit identity or profile mapping.
• Dashboard sessions and analytics can group by role/agent without replacing real telemetry with static org-chart data.
• The UI can show active/stale/completed/blocked status using explicit timestamps/heartbeats rather than guessing from source labels alone.
• CLI, ACP/VS Code, API server/Open WebUI-compatible, cron, and gateway sessions all preserve the same metadata fields where applicable.
• Historical sessions without metadata remain readable and appear as generic/unknown rather than causing errors.
• No secrets, raw environment variables, credentials, or private file contents are exposed through the dashboard API.

Non-goals

• This issue does not require implementing the orchestration engine itself.
• This issue does not require an agent-to-agent message bus.
• This issue does not require every user to adopt role-team workflows.
• This issue does not require exposing private prompts or hidden chain-of-thought.

Related issues

• Persistent canonical role sessions with governed skill policy #15153 — Persistent canonical role sessions with governed skill policy
• [Feature]: Multi-agent orchestration pipeline #18420 — Multi-agent orchestration pipeline
• [Feature]: Profile-specific dashboard branding, themes, and org-chart registries #15966 — Profile-specific dashboard branding, themes, and org-chart registries
• feat(observability): structured session tracing with start/end timestamps #6741 — Structured session tracing with start/end timestamps
• 🚀 [Feature Request]: WebUI Dashboard — Can't Wait for This! #8118 — General WebUI Dashboard request
• Feature: automatic fresh-session handoff when compression becomes risky #20372 — Automatic fresh-session handoff when compression becomes risky

This feature can be implemented incrementally: first persist metadata, then expose API aggregates, then add the dashboard activity view and stale/heartbeat affordances.