A pattern keeps repeating in the agent corner of the internet. A post lays out a nine-agent system with six specialized roles, an orchestrator, and a state-sharing YAML. The diagram lands. Upvotes accumulate.

A few weeks later the same author publishes a "lessons learned" follow-up. The numbers, if there are numbers, are about agent count. How many we ran. How many roles we split. How thick the YAML got.

Nobody publishes their production failure rate.

Meanwhile r/artificial spent the week on a different kind of post: a measured study found roughly an eight-percent productivity gain on workloads where AI had been promoted as a ten-times improvement. The argument over the percentage missed the more interesting fact: someone had actually measured. The number is not the story. The story is what got measured, and what got skipped.

What gets skipped is the throughput metric. Agent count is a vanity input. Latency per correct output — LPCO — is the engineering KPI.

Define LPCO precisely

LPCO is wall-clock time from a request to a verified-correct completion, divided by the number of tasks completed correctly in the window.

Two things make that definition usable.

A task is "verified-correct" if and only if it passed an explicit success criterion and survived its verification gate. Without an explicit criterion you cannot define what counts as correct. Without a gate you cannot count it.

Failed tasks count toward the numerator (the wall-clock clock keeps running) but not toward the denominator. The asymmetry is the point. Incorrect-but-fast does not improve the metric. Adding agents only improves LPCO if each agent reliably grows the denominator faster than the numerator.

That second sentence is what makes the metric inconvenient. A nine-agent system whose extra hops mostly increase coordination overhead can move LPCO in the wrong direction even though the architecture diagram got bigger.

Where the metric comes from

The honest part: LPCO is measurable from artifacts you already have, if you have already built the harness pieces from earlier posts. It does not require a new database, a new dashboard, or a vendor.

The task state machine is the latency stopwatch. Each task in our work queue moves through pending → ready → claimed → in_progress → review → complete. Every transition is timestamped and stored. Subtract one timestamp from another and you have per-stage latency. Sum across the chain and you have wall-clock per task. We have written about this surface as a transaction log — the same row that tells you what success meant also tells you when each step finished.

The verification gate exit is the denominator filter. A QA chain that runs after the work — written about under contract tests for agents — emits a deterministic pass or fail at the role boundary. Only the passes survive into the denominator. Completed-but-rejected tasks are noise dressed up as completion.

The retry counter is the wasted-work cap. The fail-three-times-and-stop pattern keeps a single broken task from inflating the numerator with retries that never reach correct. A task that exhausts its budget enters a failed terminal state, not complete, and adds to neither side of the ratio.

The QA chain artifact is the second-pair-of-eyes record. A coder task chains to a QA task. A product task chains to a QA task. The chain records who approved what, which is also the record of which tasks crossed from "agent claimed it was done" to "verifier agreed."

Joined together: a small Ruby query against the work-queue state-transition timestamps plus the QA chain outcomes gives you weekly LPCO. We have run twenty-five hundred tasks through this harness shape. At any week-of-data scale the trend is legible without extra instrumentation.

The architecture-theater failure mode

A system can have nine agents, six specialized roles, a beautiful state-sharing YAML, and an LPCO worse than a single agent with a contract test.

The reason is mechanical. More agents add coordination overhead. More handoffs add verification overhead. More chain hops add places where edge-case information drops between roles. Every additional role is a place where the numerator can grow without the denominator growing with it. Coordination is overhead. Verification is overhead. Both are necessary. Both have to earn their place in the latency budget.

The practical heuristic is small. For every agent role in the system, run the workload class with and without that role for a week. If LPCO does not improve when the role is present, the role is theater. Keep the diagram if you want. Stop calling it throughput.

This is the connective tissue back to the verification gap we wrote about in agentic coding without the trap. The gap widens as you add roles, because each role generates more output that needs to be checked. LPCO is the metric that surfaces the widening. It does not close the gap; it refuses to look away from it.

The honest seam

LPCO has limits worth naming before anyone treats it as a destination.

It does not tell you which axis to fix when it is bad. A high LPCO can come from slow agents, broken gates, or a chain that is too long. The metric is a scoreboard, not a debugger. You still have to inspect per-stage transition times to find which stage is bleeding.

It sits on top of two layers we have written about separately. Without an explicit criterion, "correct" is a vibe. Without a verification gate, "correct" cannot be counted. LPCO is a measurement layer, not a substitute for the definitional layer or the verification layer underneath it.

It can be gamed by workload mix. A week heavy on trivial tasks will improve LPCO for reasons that have nothing to do with the system getting better. The right move is to bucket by workload class — coder, marketing, product — and read each bucket on its own trend.

And the hardest case: a task that fails silently. A silent failure can look complete to the gate and contribute to the denominator while the underlying work was wrong. Silent-failure detection lives upstream of LPCO. If you measure throughput without first hunting the silent failures, your denominator will be slightly too high in a way that is hard to feel.

What it changes

LPCO does not tell you to ship fewer agents. It tells you to count whether each one is paying its way. A two-agent system with sharp gates can beat a nine-agent system whose roles were chosen by aesthetic. Architecture is not the throughput story. Measurement is.

The next argument worth having: even an LPCO-optimized chain bleeds correctness on edge cases as it gets longer. Measurement tells you it is bleeding. Measurement does not tell you why.

Next time: edge cases vanish faster than obvious errors when work moves through delegation chains — and why corruption compounds in a direction that scoreboards alone will not reveal.