Operating Metrics

Capture latency — the conversation-to-task loop

Capture latency is the median time between an in-conversation commitment and the task appearing on the board. It is the metric that tells you whether the capture pipeline is functioning end-to-end.

A healthy workspace runs at under 10 minutes for chat-originated commitments (the agent's scan cadence) and near-zero for commitments made directly to the AI agent. Email-originated commitments are slower (the integration sync cadence applies), usually under an hour. Anything substantially slower is a sign the agent's scan is not running, an integration is broken, or member ACLs are blocking the agent from seeing the surface.

The action when capture latency climbs: check the agent's scan logs and the integration health on /settings. The most common cause is an integration whose OAuth token has expired silently. The metric catches it before the team notices the missed commitments.

Negation reuse rate — operating discipline

Module 5.4 introduced negation hits. The operating-layer view of the same metric is rate-of-reuse — how often per week, on average, do the workspace's Negations get cited?

A workspace running a healthy operating cadence will produce dozens of negation reuses per quarter. The number itself is not the goal; the trend is. Falling reuse means either the team is hitting fewer boundary-adjacent situations (possible but rare) or the discipline of citing has degraded (more common).

The action when reuse falls without an obvious cause: surface it in the quarterly retrospective. The team has probably started accepting work that the Negation was supposed to deflect, and the slippage is invisible because the dismissals stopped happening.

AI Employee contribution — what fraction of capacity comes from personas

As personas become first-class assignees, the question 'how much of the team's capacity is coming from AI Employees vs. humans' becomes a real operating metric.

The metric: total estimated hours of completed work assigned to AI Employees divided by total estimated hours across all assignees, per sprint.

There is no established benchmark for what fraction of a team's capacity 'should' come from AI Employees — it depends entirely on your work mix and how you've scoped personas. We'd expect a well-run team's fraction to rise and then level off, but the level is yours to discover; any specific plateau is a Kavanah illustration, not a measured norm. What the current evidence does say is that AI tends to raise throughput while also correlating with increased delivery instability — more change failures and rework (DORA 2025) — so track this fraction alongside your rework and cycle-time signals, and judge AI Employees on net delivered value, not raw absorbed hours. Higher fractions mean the team has scoped personas to take real load; lower fractions, while not unhealthy, mean the personas you've stood up are not yet absorbing the work they were intended to.

This is also the metric that justifies the cost. Persona usage shows up in usage-events with token + active-CPU breakdowns. The operating question is: are the hours absorbed worth the inference cost? At a workspace level, AI Employees are earning their keep when their absorbed-hours-per-dollar is comparable to human capacity at the same skill level.

Time-to-first-real-task per member

An underappreciated operating metric: how long does it take, from invite, for a new member to ship their first real task in the workspace?

We suggest under a week as a healthy onboarding target. Slower onboarding means the workspace's KVN is opaque enough that the new member spends days figuring out what 'good' looks like, or the assignment system isn't routing appropriate work to them (no declared skills yet, no learned history). Both are fixable.

The metric is also a plausible customer-acquisition signal for the workspace itself. If you bring a new client team into a multi-tenant workspace, their time-to-first-task is a reasonable leading indicator of whether they'll engage long-term — but validate the link against your own account history rather than assuming it. We're not aware of published data establishing specific one-week/two-week renewal thresholds, so treat those as Kavanah starting guidance.

Project Vision hit rate — outcomes finally

All of the above is internal. The single most important outcome metric is the project Vision hit rate: across recently closed projects, what fraction shipped what their charter V said they would ship?

Completing a project records a Vision outcome — met, partially met, or dropped — with an optional memo (the agent's complete_project takes a vision_outcome, so you can close a project and confirm its V in one step). The aggregate of that across closed projects is the hit rate, computed on the Operating tab.

We suggest treating a substantial-V-met rate above roughly 70% as healthy, with the misses concentrated in clear categories (scope cut by stakeholder, requirement learned mid-project, technical infeasibility discovered), and a sustained rate below ~50% as a sign V's are being written aspirationally — the team isn't honestly stating what they intend to ship. These cutoffs are Kavanah recommendations to calibrate against your own close-out history, not measured benchmarks.

The action when hit rate drops: tighten V-writing at kickoff. The agent's KVN generator can be set to bias V's toward what historical projects of similar shape actually shipped, not what the leadership wished for.

Customer-outcome ties — the link to revenue

The last metric is the link between work metrics and customer metrics. Whatever your team's customer-side outcome is — retention, ARR per seat, NPS, support resolution time — tie it to the projects that were meant to move it.

A project can be tagged with the customer-outcome it is meant to move (set_project_outcome_target), and after it closes the team records whether that outcome actually moved in the following quarter (record_project_outcome). Over many projects, this produces the team's project-to-outcome conversion rate: of projects you committed to as outcome-moving, what fraction actually moved the outcome. It is computed on the Operating tab once results are recorded.

This is the meta-metric. It is slower than every other metric in the dashboard (outcomes lag); it is the most subject to confounds (other things move outcomes); and it is the only metric whose answer ultimately decides whether the team's work was worth doing.