The useful measure of automated work begins after output exists: was it verified, accepted, and produced with less steering?
Agent count is an irresistible metric. It's concrete, it rises when a system expands, and it makes a quiet operation look busy. I've counted agents, cards, scheduled jobs, reports, token use, and dashboard events. None of those numbers told me whether the work was any good.
They described capacity or activity. Sometimes they described only decoration, which was not quite the executive dashboard insight I had in mind. A scheduled job can wake on time and produce an unusable report every morning. A board can fill with cards that represent the system narrating its own effort. Token use can rise because the task is difficult, because the prompt is poor, or because two workers are politely duplicating each other.
The number I return to now is accepted work: an externally meaningful outcome that has been verified and admitted into use. A draft sitting in a queue is output. A change reported complete by its worker is a claim. A result becomes accepted when someone or some independent check confirms that it satisfies the defined need. Until then, it's output with good public relations.
That definition is intentionally stricter than completion. Automated systems are very good at reaching the end of their own procedure. They can write the file, mark the card, summarize the run, and declare success. The interesting question is whether the produced artifact survives contact with the place it was meant to matter.
Verification depends on the work. A code change can be read back and tested. A structured extraction can be compared with its sources. A generated operational record can be checked for required fields and reviewed where judgment remains. I'm not looking for one universal acceptance test. I'm looking for a named boundary between “the system produced something” and “we're willing to use it.”
This makes rejection useful data. If an output is declined because it missed the requested scope, acceptance didn't happen. That shouldn't be softened into partial success just because the run consumed time and generated several artifacts. The rejection reason can improve the workflow, but the activity itself doesn't earn credit.
It's embarrassingly easy to manufacture motion. Add another worker to critique the first, create a card for the critique, schedule a report about card movement, and put all of it on a dashboard. The system now emits more messages, more state changes, and more charts without delivering one additional outcome. I understand the appeal because motion is visible before value is. I've built the dashboard that reassured me. On a slow day, the machinery can make its builder feel that something important must be happening.
Accepted work resists that reassurance. If three workers produce one artifact that needs extensive correction, the count is still one accepted outcome, and the correction burden belongs beside it. If a single bounded automation produces a verified result with no intervention, that may be the stronger system even though its activity graph looks almost empty.
The second measure I watch is steering. How much human effort was required to get from request to acceptable result? This isn't a contest to remove people from judgment. Review may be the correct control point. Steering means the avoidable work of repeatedly restating context, redirecting wandering execution, recovering lost state, and asking for evidence that should have been attached.
An output can be accepted and still reveal high steering cost. Perhaps it required several reminders to stay within scope. Perhaps the worker lost its place and regenerated completed work. The final artifact may be fine, but the operating pattern isn't efficient yet. Tracking acceptance without steering would hide that burden.
Conversely, low steering doesn't redeem bad work. A fully autonomous run that produces the wrong result has merely failed without supervision. It hasn't earned bonus points for independence. The two measures belong together: accepted outcomes show whether the work mattered, and steering shows how much attention was consumed in getting there.
I also separate acceptance rate from raw volume. Ten accepted items out of a large pile may reveal a different problem than ten accepted items with only one rejection. Volume alone makes both systems look equal. Rate alone can reward a system that attempts only trivial work. Context still matters, but at least the conversation begins with outcomes and correction instead of compute and choreography.
This changes planning. When someone proposes another agent, report, or scheduled loop, I ask which accepted outcome it should improve. Will it raise the number of verified results? Reduce correction? Reduce repeated steering while preserving the review boundary? If the proposal can't connect to one of those effects, its activity will probably become maintenance before it becomes value.
Dashboards change too. I still need operational counters for failures, queue depth, and resource use. Those help run the machinery. They simply don't sit at the top as evidence of success. The outcome view shows what was submitted, what was verified, what was accepted or rejected, and where human steering entered the path.
The hardest part is cultural. Activity metrics give immediate feedback and flattering curves. Acceptance arrives later and includes disagreement. It forces us to look at discarded drafts, corrected classifications, reverted changes, and work that never should have started. That mess is closer to the truth.
At the end of a run, I don't ask how many workers participated or how much text they produced anymore. I look for the accepted artifact, the evidence that cleared it, the corrections made along the way, and the points where a person had to steer. If those records are missing, the system has measured its exertion while leaving its contribution unknown.