The labels on the agent work-flow dashboard read like literal window or message counts.
I read them that way, and I went looking for windows the number said should exist.
What the number actually counted
Some of the run records from that day:
Two runs, one laying out a zones count and one resolving a stash conflict, both ended as (timeout after 900s).
A third run, an identity fix, committed the fix, but its last line says git stash pop hit a conflict in lib/chrome_pool.py and it stopped there.
All three count as dispatched. A count of dispatches is not a count of what is running.
The change I shipped that day was clearer labeling, so the numbers explain what they actually count.
The same drift, earlier that day
That same day, the hub session I was running shipped infrastructure fixes I had never asked for. Three of them:
A browser cleanup that was destroying windows I had just been told to sign into.
A gate that duplicated every corrected reply.
A live session being silently marked closed.
I read those as the same kind of failure as the dashboard label: some part of the system held a belief about what a window was, and the belief and the real window had drifted apart.
desk identity now shows the owning identity and sid for each window the chrome pool leases, in both text and JSON mode.
Then the browser layer went down
The entire agent browser layer had gone down mid-session. I filed a ticket for the next session.
A count labeled as dispatched can’t be mistaken for a count of what is alive.
If you run agents behind a dashboard, take each figure and write down the exact event that increments it. If that event is not what the label says, rename the label until the two match, and put the plain-words explanation next to the number.
AI Skills
Use this lesson with the AI assistant you already use
On the 23rd, a dashboard's window count was correct for dispatched work but was read as a count of live browser windows. Timeout and conflicted runs remained in the total even though none was an open window.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Label Operational Metrics By What They Actually Count
SOURCE: dxdev.com/blog/2026-09-26_honest-workflow-dashboard-metrics
WHAT HAPPENED: The dashboard counted session records written for dispatched `claude -p` and `codex exec` runs, but labeled those totals as windows and messages. Two runs timed out after 900 seconds, and another stopped at a `git stash pop` conflict, yet all three still counted as dispatched work. The fix changed the labels and added plain-language explanations instead of adding new counting. A related identity change made `desk identity` show each leased Chrome window's owner and session ID.
THE RULE: Label each metric with the exact state or event it measures, especially when a historical dispatch total can be mistaken for a current live-state count. Preserve a correct query when the failure is interpretation, then expose the ownership or state details needed to verify the metric.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Does every dashboard figure explicitly state whether it counts dispatched work, completed work, or currently live resources?
2. Can timed-out, failed, or conflicted runs remain in a dispatched total without being presented as active windows or messages?
3. Can each leased browser window be traced to a named owner and session ID in both human-readable and machine-readable output?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.