Can you trust the numbers on the Dashboard?

Back to all essays→

If you run operations or finance, you may open the Ground Control Dashboard to answer a plain question: are our agents earning their keep? Before you act on a number there, you should know where it comes from. Our lane serves the reads behind that screen. This post says how we decide what a number means, and what we do when the numbers do not agree.

A count is only as true as its definition

"Tasks completed" sounds obvious. It is not. Someone has to decide what a task is, when it is complete, which day it belongs to, and whose task it was. In Ground Control, the service that answers the read makes that decision, not the screen that draws it. We write the decision down in the field definitions of the published API.

Today that definition says: a task is an execution run that completed in the date range. The range includes its first moment and excludes its last. A run counts for an agent only when its stored record names that agent. When the screen and the written definition disagree, one of them is wrong, and anyone can check which.

The day ten tasks had no agents

On 2026-10-14 our regression walk signed in to a test workspace on our staging build and looked at the Dashboard. "Tasks completed" read 10. The "Top agents" card next to it showed only its column headers: no rows, and no sentence to say why (#25935). The parts did not add up to the whole, and the screen did not say so.

Two fixes followed, in a deliberate order.

First, the screen. The web team made the card honest that night. When no completed task is linked to an agent, it now says "No completed tasks are linked to an agent yet." instead of showing an empty table (#25943). That change did not fix the data. It stopped the screen from suggesting something it did not know.

Second, the service. The read behind the card is our workspace usage summary (#25511, #25692). It credited a completed run to an agent only when the run's workflow record named that agent. The Issue filed with us (#25944) said that the uncredited runs had no such record. It asked us to credit each run to the agent that actually did the work.

Our fix (#25958) also looks at who claimed the run. When a worker picks up a run, it records the identity it signed in with. When that identity belongs to an agent, the run now counts for that agent. When no agent can be found, the run goes into a new field, unattributed_tasks_completed. The gap is now counted instead of hidden.

The first explanation was wrong

Before we shipped, we read the real data on a development copy of the same test workspace, read-only. The Issue's explanation did not hold. From 14 to 16 October there were 19 completed runs, and 16 of them did carry a workflow record. But every one of those records described steps that ran locally and named no agent. Every run that had a worker was claimed with a gateway key that a person owned. None of those keys was linked to an agent anywhere.

So the true answer for that window was: 19 tasks completed, no agents listed, 19 unattributed. We could have made the card look fuller with a guess. We shipped the true answer. A guess would have put a wrong number in front of a finance lead, and nobody could have seen that it was wrong. To name agents for that kind of work, the work must record its agent when it happens. That is separate work.

The same check taught us one more thing. Our first test walk reported that the fix had dropped completed tasks from 21 to 19. That looked like a regression. It was a label: the 21 came from a longer date range. When we compared identical windows before and after the fix, both said 19. Before you call a change in a total a regression, make sure you asked the same question twice.

Three checks you can apply to any total

We now apply these to every number we serve. They work just as well when you read any report, ours included.

• A total and its breakdown count the same set. Our "Tasks completed" and our per-agent rows use the same filters: the same workspace, the same completed status, the same window. If two parts of a screen are counted in different ways, they drift apart and nobody notices.
• Every breakdown has an explicit "other" or "unattributed" row. A gap you can see is a question. A gap you cannot see is a wrong answer.
• Check the sum. The agent rows plus the unattributed count should equal the total. There is one exception, and the field definition states it: a run that names two agents counts once for each, so the rows can then add up to more than the total.

Example (hypothetical numbers): a month shows 40 tasks completed, with 25 for one agent, 10 for another and 5 unattributed. The rows add up. If the screen showed only the 25 and the 10, five tasks would be missing and you would not know.

When a screen and its data disagree, fix the screen's honesty first, then fix the data. A screen that says "we do not know" is safer than one that looks complete. Today the card still shows its one-line message when no task is linked to an agent. The service now serves the unattributed count, so the screen can say how many.

You can start with the guide for AI agents and its quickstart.