Is this just another KPI CRUD dashboard?

No. Definition management is kept in a separate workspace. The primary screen is a ranked triage queue that combines current evidence, verdict, ownership, and the response already in progress.

What evidence sources can Fleet use?

A KPI can use a numeric metric published by a connected integration or a manual observation recorded in Fleet. Available integration metrics appear in the mapping flow with their required dimensions.

Does a breached KPI automatically run an agent?

No. The evidence produces a decision-ready queue. An authorized operator starts the bound intervention workflow from that evidence, preserving human control over which response should run.

What if the source stops reporting?

Fleet moves the KPI into Evidence problems and explains whether samples are missing, stale, invalid, below coverage, unreadable, or overdue. It does not keep showing an old verdict as current.

KPI Control Tower for AI Agent Work

Name: Fleet
Author: Fleet

Product teams do not suffer from a shortage of dashboards. They suffer from the gap after the chart: traffic is down, signed-in users are not installing, or activated users are not returning — and the response still depends on one person noticing, interpreting, and translating the signal into work.

That makes KPI management a memory test. Analytics, errors, delivery signals, and manual observations live in different systems. Healthy-looking stale data can be worse than no data, and a generic CRUD table gives every metric the same visual weight even when only two need a decision today.

How it works with an agent fleet

Fleet's KPI Control Tower maps numeric evidence from connected integrations — or a manual observation — to a durable KPI definition. Each definition combines a target condition, evidence window, ownership scope, priority, and optional intervention workflow.

The daily screen is an ordered triage queue rather than a KPI spreadsheet. Evidence problems are separated from real outcome misses. Breached and at-risk KPIs rise into Needs attention. Healthy KPIs stay available but collapsed. Select a row to see the current value, target, trend, freshness, evaluation history, and response status in one evidence rail.

When a trustworthy KPI needs attention, an operator can start its bound workflow directly from that evidence. If the response does not exist yet, Fleet opens the visual workflow builder with the KPI context attached. The resulting run stays linked to the evidence that caused it.

The fleet pattern

Integration metric or manual observation → evaluated KPI condition → ordered decision queue → evidence-bound workflow intervention → visible run history. The KPI identifies what needs a decision; the workflow carries out the response.

Guardrails that matter here

Preview evaluates the real current evidence before activation; missing, stale, invalid, insufficient, or changed evidence blocks activation
Evidence problems are their own queue instead of preserving a stale verdict or pretending the KPI is healthy
Editing an active KPI creates a draft revision; the current definition keeps evaluating until the replacement is previewed and activated
Viewer access is read-only; mapping changes, lifecycle actions, manual observations, and interventions require operator permission
An active intervention is surfaced in the evidence rail so the same response is not launched twice

Who this is for

Founders, heads of product, engineering leaders, growth owners, and reliability teams who already inspect metrics and then manually create the work those metrics imply. It is most valuable when the right next move changes with the evidence: write acquisition pages when traffic is low, improve onboarding when installation stalls, or start a retention workflow when activated users stop returning.