System Overview

Grid View

A magnetic tile canvas holding two kinds of occupant on one lattice: agent tiles (one per agent, with avatar, runtime badge, live status chips including subscription pressure, and inline Running and Autonomy toggles) and info tiles. Four info tiles ship today, all on by default: Fleet summary, Recent failures, Executions (24 hourly columns split by trigger, with failures on their own rail), and Subscription pressure (admins only).

• •Drag a tile to move it, or drop it onto another to swap positions — tile positions, your info-tile selection, and the Zones/Lines toggles are saved to your user account on the server, so the same board follows you to any browser
• •Tidy up re-packs tiles compactly; Reset restores the default auto-generated layout and clears your server record
• •Pan by dragging the background and zoom with scroll, pinch, or the Zoom in / Zoom out / Fit view controls bottom-left; tile metrics hydrate lazily so large fleets stay responsive
• •An optional org overlay draws departments (dept-* tags) as labelled zones and reporting lines (reports-to-* tags) as arrows between tiles; Group by dept arranges the fleet into department blocks once, and tiles stay hand-editable afterwards

Timeline View (Default)

The default mode. Timeline shows execution boxes per agent, arranged chronologically.

• •Color-coded by trigger type: Manual (green), MCP (pink), Scheduled (purple), Agent-Triggered (cyan), Paid (yellow), Public (teal)
• •Each row shows the agent's completion rate, total cost, and parallel slot count
• •Live streaming: running executions show progress in real-time with a “Live” indicator
• •Time range filter: 1h, 6h, 24h, 3d, or 7d
• •Active only toggle hides agents with no recent activity
• •Jump to Now snaps the view to the current time

Agent-to-agent collaboration is surfaced here — in the Timeline replay via the Agent-Triggered trigger type — rather than as a live node graph.

List View

The former standalone Agents page, folded into the Dashboard as a third mode (/agents now redirects here).

• •One row per agent. Columns: Name, Status, Controls, Success, Exec / Sched, plus a capacity meter — with inline Run and Autonomy toggles
• •The name cell carries only exception markers — SYSTEM, GHOST, Shared; a labelled agent shows its display label with the slug, subscription pressure badge, runtime badge, and tags on the secondary line
• •Sort by Newest First, Oldest First, Name (A-Z), Name (Z-A), Running First, or Success Rate; filter by name and status (All / Running / Stopped); select multiple rows for bulk tag operations
• •System agents pin to the top and hide the Run toggle

Fleet Stats Bar

The header's left side carries live fleet telemetry: n/total agents, N working now, N messagesfor the selected time range, and the host's CPU, memory, and disk meters. On narrow viewports it degrades gracefully — dropping the least important readouts first — rather than clipping; the agent count always survives.

Dashboard API Endpoints

Health Levels

Agent health is reported at five severity levels:

Three Monitoring Layers

Alert Cooldowns: Repeated alerts for the same condition are throttled to prevent notification spam.

Health Tab (Operations Page)

Fleet health lives on the admin-only Health tab of the Operations page (/operations?tab=health). It shows summary cards, active alerts, and a per-agent health list with a status filter; admins can trigger a fleet-wide check with Check All. The periodic health-check loop is disabled by default and can be enabled via the API. Real-time WebSocket updates push health state changes as they occur. Individual agent health is visible in both the agent header and the Agents listing page.

Cleanup Service

A background service that automatically recovers stuck resources:

• •Orphaned executions — The watchdog asks each running agent which executions it knows about. A running row the agent does not know is orphaned only if no live backend dispatcher owns it either; rows withheld this way are reported as dispatch_inflight_skipped, not as recoveries
• •Stale executions — Any execution with status='running' past its per-slot timeout is marked failed
• •Stale activities — Any activity with activity_state='started' past the configured threshold is marked failed
• •Stale Redis slots — Orphaned slot reservations are released
• •Run frequency — Every 5 minutes, plus a one-shot sweep on backend restart
• •Startup recovery — Orphaned executions (container down, not in process registry, and not owned by a dispatcher in another worker) are marked failed immediately and their slots are released

A close the cleanup service fabricates records no duration — duration_ms is NULL, not a number computed from started_at. Earlier versions wrote a made-up duration, and on PostgreSQL a row older than about 25 days overflowed the column and rolled back the whole sweep. If you upgrade an instance in that state, the restart's startup recovery closes those rows; no manual SQL is needed.

Monitoring MCP Tools

Monitoring API Endpoints

Needs Response Tab

Shows items from agents' operator queues that are waiting on a human: questions, approval requests, and alerts.

• •Agents write to ~/.trinity/operator-queue.json inside their container
• •A background sync service polls running agents every 5 seconds and persists items to the backend database
• •Operators respond to items directly; responses are written back to the originating agent
• •The first open item auto-expands once when items arrive. A card you collapse stays collapsed through refreshes and new arrivals; the auto-expand re-arms only after the queue empties
• •Each card carries a type pill and a matching control — Needs approval (pick one of the agent's own options, optional note; a free-text decision is refused), Question (type an answer), Heads up (click Got it). If the item stopped being pending while you were answering, your response is not recorded and the page says so
• •The platform files its own alerts here too: git sync failures, weekly-limit subscription alerts, and a notice after a push whose .gitignore sweep changed which files are tracked
• •WebSocket events: operator_queue_new, operator_queue_responded, operator_queue_acknowledged, operator_queue_cleared

Notifications Tab

Consolidated view of agent notifications (replaces the former standalone Events page).

• •Filter by agent, type, priority, or status; optionally show dismissed items
• •Stats cards display pending, acknowledged, total, and per-agent counts
• •Bulk selection and bulk actions
• •Real-time updates via WebSocket

Sync Service

Restart-resilient sync between agent containers and the backend database, with a manual refresh button on the operator tabs. Cancelled and expired statuses are written back into agent queue files, so agents stop waiting on cleared items.

Operator Queue API

MCP Tool: send_notification(agent_name, message, priority) — sends a notification to the Operations page from within an agent.

A typical request flows through the system as follows:

All services run on a single Docker bridge network (trinity-agent-network, subnet 172.28.0.0/16). Agent containers are dynamically attached to this network when created.