AI agent operations dashboards and goal maps

AR Labs supervises its AI agents (language models run in a loop with tools, so they can act, not only reply) through a small set of visual views, each answering one question: how the period is going, what this week is for, which agents are working on what, how the systems fit together, and where a piece of work stands. This page is for anyone designing an AI agent operations dashboard. It sets out what a person needs to see to supervise agents doing real work, then describes each of our views. Every view is generated from the files and task records that own the facts, because plans held only in documents go unseen and drift. None is a place where decisions are made or state is stored.

What a person needs to see

A dashboard for supervising agents has to show more than whether runs succeeded. The table lists what we think a person needs, and where our views show it today.

What the person needs to see	Where our views show it
The goal or outcome the work serves	The centre of the goal map; the monthly goals on the cadence dashboard
Projects and the graph of work under them	The goal map's spiral of projects; task-graph maps of one branch of tracked work
Which agents are working, on what, and how recently	Moons on the goal map, coloured by last activity
Blockers and decisions waiting for a person	Project status on the goal map; the waiting markers on task-graph maps; tracked escalations
Acceptance criteria and evidence of completion	What "done" means for each week-page outcome; yes-or-no evidence items on the cadence dashboard
Handoffs between agents	Not drawn as a view of its own; the week page reads the agent mailbox, and the mailbox is the record
Cost and latency, kept apart from outcomes	Not shown in these views today
History and a safe route back into work	Frozen closed periods, struck-through revised targets, and task-graph maps showing where finished code landed; a session is resumed from the task it is linked to
One source of truth	Every view is rendered from source files and task records and never written to, so it cannot become a second task store

How the views fit together

flowchart LR
    S["Strategy and goal files"] --> D["Cadence dashboard"]
    S --> W["Week page"]
    T["Task tracker"] --> W
    T --> TG["Task-graph maps"]
    A["Agent session sweep"] --> G["Goal map"]
    S --> G
    P["Project docs"] --> M["System maps"]
    D --> I["Surface index"]
    W --> I
    G --> I
    M --> I
    TG --> I

The surface index is a single page with one card per view, so there is one entry point for all of them.

The cadence dashboard

A review page that the strategy agent puts on screen during its weekly, monthly and quarterly cadences. It has pages for the current check-in, the current month and the current quarter, plus closed periods. Closed periods are frozen once the cadence that closes them finishes; only the current period changes.

The renderer and the data are separate files. The strategy agent emits the data; a separate building agent, called for each change and remembering nothing between calls, edits the page. Several rules keep the page honest:

• Freshness is computed. The page compares the date of its newest fact to today and labels itself current, ageing or stale. Cadence warnings, such as a missed weekly review, appear under that banner and may not be removed to make the page look clean.
• Every value carries its source. A figure that could not be checked this session is flagged unverified with a reason.
• Status colours follow rules, not judgement. On track, at risk and off track are defined against pace and floors, and dormant (a recorded decision to pause) is drawn differently from off track. Colour is never the only signal.
• Outcomes need evidence. Each monthly goal has yes-or-no evidence items. An item with no recorded outcome or source is drawn red and hatched, even if its claimed state is "met", because an unbacked claim of success is the worst case.
• A month close records three things: the goals and their evidence, work that shipped without being planned, and work deliberately parked with the reason.
• Changed targets keep their history. When a target is formally revised, the old value is shown struck through beside the new one, with the reason, the trigger and who approved it.

Three guardrails govern its use. The dashboard never writes company state. A correction made on screen is not real until it reaches the source document, and the building agent must name which source now disagrees. And the strategy agent never reads the dashboard as input, since that would mean reading a summary of a summary it wrote itself.

The week page

One picture of the week. It shows at most four ranked outcomes, each with what "done" means; a grid of half-days showing where past days actually went (from commits, the agent mailbox, project records and the calendar log) beside where planned half-days will go; and the year, quarter and month the week sits inside. A row labelled "everything else" collects work outside the outcomes, which is how drift becomes visible. A daily check updates the grid and republishes the page.

flowchart TD
    H["Header: week, summary, as-of time"] --> O["Outcome cards: ranked, with done-means"]
    O --> G["Grid: days by half-day, actual and planned"]
    G --> E["Everything-else row"]
    G --> B["Back burner and waiting cards"]
    B --> FR["Frames: year, quarter, month"]

The goal map

A fleet view answering two questions at once: what the company is pursuing this month, and which agents are on it. The month's central goal sits at the centre. Projects that serve a numbered priority lie on a spiral in priority order, so distance from the centre reads as distance from the month's goal. Projects that serve no priority sit on a dashed outer belt, which makes drift visible by construction. Planet colour shows project status (working, waiting on a person's decision, idle, parked). Moons are agents, lettered by the agent program they run in (Claude Code, Codex or a server-side agent runtime), coloured by how recently they were active measured against the viewer's clock, so a map opened days later shows nothing as current. Semantic zoom shows names far out, each project's outcome at mid range and agent labels close in. Nodes cannot be dragged, because a moved planet would misstate its priority.

The map is rebuilt from a sweep of agent sessions, not from the task tracker: a background agent inventories the running and recent sessions across our agent programs and writes them to a data file. The goal map skill builds it, and the Goal Map project page covers how it was made. A build script validates the data and refuses what the page cannot show, and a check script renders light and dark screenshots that are inspected before the map is used. A small local helper can bring a selected agent's terminal tab to the front. The build also has a public mode that rewrites every description for an outside reader and drops internal identifiers.

System maps and task-graph maps

Three pages describe our own systems. A component atlas places every part in the plane it belongs to (presentation, intelligence, governance, data, substrate) with lenses by plane or build state, named end-to-end flows that animate in order, and a detail drawer for each part. Relationships are hidden until a part is selected, because drawing every edge at once produces noise. A wiring diagram shows only the load-bearing parts, with solid lines for connections that carry traffic today and dashed lines for those specified but not built. A long-range timeline separates completed evidence from projections, and a projection card turns solid only when the milestone actually lands.

Task-graph maps (internally, constellations) draw one branch of the task tracker as a status map (see Taskgraph): what is finished and where its code landed, what is in flight, what happens next and in what order, and where work waits for a human decision.

What exists today

All of the views above exist and are used internally. They share one visual language, a paper-and-ink theme with fixed status colours. They are private working tools; this page describes their design, and their live contents are not published.