Command Center

Every agent platform can tell you how many runs succeeded. That is not the question a business asks. The question is whether the work is getting done, how quickly, and at what cost — in the words your business already uses.

Command Center is a KPI board your agency designs for itself, from the work it has been observed actually doing.

Nothing is pre-built

There is no template of standard metrics waiting to be switched on. A claims agency ends up measuring claims settled, time to settle, and cases waiting on a decision. A quoting agency measures quotes issued and win rate. Neither list was written by us — both were derived from what those agents produced.

That matters because a board built from your config would only ever measure what the config claimed would happen. This one is built from outcomes.

How the board gets built

At startup, a provisional board appears immediately, derived from the agency you configured. It gives you something to look at on day one.

After a few real runs, the agency has evidence: what agents produced, which tools they used, what the outcomes were called. It then designs the real board and replaces the provisional one.

Nothing is lost in between. Runs that complete while the agency is still learning are counted anyway, at the time they really happened — so the first real board opens with history in it rather than a row of zeros.

Command Center is off until you turn it on:

manager:
  command_center:
    enabled: true
    design_after_runs: 3     # real runs to watch before designing (default 3)
    max_metrics: 24          # most metrics on the board (default 24)

It uses the Manager's model to design the board unless you name another with model.

Business language, not machinery

Command Center talks about invoices, tickets, quotes and cases. It does not talk about agents, prompts, tokens, queues or retries — those belong in the operational dashboards, and duplicating them here would bury the business picture under the plumbing.

Each metric is a precise recipe evaluated against what really happened. No sampling, no model estimating a number, and no ongoing model spend to keep the board current. Numbers move as work completes, and every metric carries its own day, week, month and all-time view.

What changed

Above the board, Command Center reports which numbers moved since the previous period and by how much. It is computed, not written — so it never pads a real shift with commentary, and it stays silent when nothing moved.

Targets

A metric can carry a target and a direction, so a figure reads as on track or off track rather than as a bare number:

target: 24
target_direction: below   # 24 hours to resolve, and lower is better

target_direction is below (stay under the target — resolution time, cost per case) or above (stay over it — first-contact resolution rate). Targets are yours to set; the agency designs the metrics but never invents the goals.

Status at a glance

Above the metrics, Command Center states where the work stands — computed from the board and the metrics, with no model involved:

State	When
`on_track`	Nothing below applies.
`at_risk`	A follow-up is overdue, something failed today, or a request is waiting on a person.
`off_track`	Work is blocked, a target was missed, or the mesh gave up retrying something and a person is needed.

With it come the reasons, the few things a senior person should act on — what is stuck and since when, what needs a person, what is due — and today's numbers: requests opened, resolved, backlog and time to resolve.

When a board is in use, its own numbers — requests opened and resolved, time to resolve, stalled tickets — are always on Command Center, alongside the metrics designed for your mission.

Waiting on a person

Work paused for a human decision is surfaced on its own. A queue that has stopped moving is a business problem before it is an operational one, and it is easy to miss when it is averaged into a throughput number.

Editing the board

Every metric is editable from Studio or the API — titles, targets, thresholds, and how a number is drawn.

Export the whole board as a document.
Upload it into another environment, so staging and production share one definition.
Redesign at any time, optionally in your own words: "focus on turnaround time, not volume" — the board is rebuilt against what matters now.

How far back it reaches

From 2.4.497, every figure the board shows follows one rule:

Summaries are kept for a year. These are the counts, daily and weekly totals, and usage tallies.
Records follow your own retention setting. These are sessions, runs and activity.
Every read answers the range you asked for and says how far back it goes. A daily series can be up to 365 days. series_kept_days says how many days the board keeps, and series_complete says whether that covers your whole range. The activity feed's covered_from is when its oldest kept entry was written.

When a range is longer than what is kept, the page says so instead of cutting it off silently.

Honest empty states

A metric with no evidence behind it yet says so, rather than showing a confident zero. A zero and "not seen yet" mean very different things to someone deciding whether the pipeline is broken.

Next Steps

Observability Overview — the operational view that sits underneath this one
Yield Monitoring — what agents produce, per run
Agent Studio — where the board lives

LeafMesh — the business view, derived from the work itself