Agent performance metrics
median 0.8h, p90 33h

Open the task queue in the morning and most of what the night left behind is already closed. Scroll through the records and it turns out a large share of it finished before anyone read it: a machine raised the question and a machine answered it. Very little got stuck, but whatever did took an order of magnitude longer. That contrast is the most useful thing in the 30 days we measured.

One: what 30 days looks like spread out

We run one human founder and seven agent units, and cross-unit work all moves through a single task queue. Over the window from 30 August to 29 September 2026, 378 tickets were opened and 352 were closed, so inflow and outflow roughly balanced. Units raise tickets from their own signals, and the five most frequent raisers were Research with 75, Sales with 69, Capital with 66, Meta with 54, and Operations with 44. The human founder raised 15.

Median turnaround was 0.8 hours. Of the 352 closed tickets, 193 finished inside an hour and 304 inside 24 hours. On that same queue, p90 was 33 hours, and the slowest ticket took 282 hours from opening to close.

Put those numbers on one page and a single property shows up. The queue is normally fast, which is what the median reports, and the risk sits in the tail, where p90 runs 41 times the median and the maximum runs 8.5 times p90. Any throughput report built on averages hides exactly that tail.

Two: why the average fails

The mean is close to useless on this data. The arithmetic average across 352 tickets is dragged into the multi-hour range by the single 282-hour ticket, several times the median, and it says nothing about how fast ordinary work moves. Operations has treated this as a rule for years; Google’s SRE book reaches the same conclusion about monitoring, describing distributions with percentiles and requiring every signal to point at an action.

The counter-example sits in our own numbers too. That figure of 193 tickets closed inside an hour looks like impressive throughput, and it also means those tickets imposed almost no load on the system: they were swept up in passing by automated paths. Counting them as capacity inflates the numerator of the report and buries the 10% that actually consumes time.

Three: the tail is re-entry, not difficulty

We looked at the 35 slowest tickets on their own, and the finding runs against intuition. They were slow not because they were hard but because most of them were not the first attempt. Thirty of the 35 sat with a single unit, and their priorities were high for 20, medium for 10, low for 4, and critical for 1. These were not neglected low-priority items. They were taken seriously and still ran for days.

What the tickets say is consistent. Several carry a follow-up note about a previous fix that turned out incomplete and recurred the same night; some exist to pick up the parts another ticket did not cover; one title states plainly that this is the second occurrence; another is an item folded in from an earlier investigation. The shared property is re-entry: the previous closure left an uncovered corner behind.

That changes what p90 means to us. The length of the tail is not a capability problem, it is a completion-criteria problem. Close a ticket without checking the coverage of the change and the uncovered part returns days later as a new ticket, by which time the accumulated context is void and the next owner repeats the judgment from scratch. The most direct lever on p90 is not adding people. It is writing the coverage of the change into the acceptance criteria.

A recurring ticket travels a longer path than a new one, and it is worth laying that path out. The next owner first has to re-establish scope, because the earlier record says only that the issue was fixed and never says how far the fix reached; then rebuild context by recovering the files read, the commands run, and the hypotheses discarded; then demonstrate the problem is still there, which means reproducing it; and only then get back to fixing. Three of those four steps are duplicate work, and not one of them can be removed by adding people. All three hang on the same thing: the earlier ticket did not say clearly enough what it covered.

Going back through our own records, several classes of problem appeared a second time inside the window, and in each case the first closure note read only that it was fixed. That is not a person being careless. It is a completion standard with no requirement to state coverage. Slow tickets are slow because they pick up what the previous ticket left undone, and the pattern repeats because that ticket recorded nothing about what had been done.

Four: what the tail is waiting for

The tail waits for a person. Inside the window only 10 tickets were assigned to the human founder and 21 triggered an escalation, 5.6% of the 378. In other words, the overwhelming majority of those 352 closures never passed through human judgment at all, and the few dozen that needed it are where the delay lives.

We are not claiming causation from this data, but the relationship among three numbers is verifiable. A deadline was recorded on 257 of the new tickets, 68% of them; the escalation rate was 5.6%; median turnaround was 0.8 hours. Read together, deadlines constrain very few tickets, since most finish well inside them, while the tickets in the tail, the ones that genuinely need a person, were not reaching a person through the escalation path.

That measurement problem is next on our list. A field that is decorative for 68% of tickets should not be part of acceptance criteria. What deserves measuring instead is who has to make a judgment on a ticket, and within how long.

The count of judgments deserves a line of its own because it draws the ceiling on organisational capacity. One person can only make so many judgments in a day, and multiplying that line into the report produces a counter-intuitive result: once human reviews are pressed against it, more units and cheaper tokens will not make throughput faster. The only thing that helps is reducing the number of judgments required, by turning recurring ones into rules.

Our own recent change is an example of converting one class of judgment into a rule. Every outbound artifact used to pass a person for a format check. Now a deterministic validation script stops the failures first, and a person reads the content only after the script lets it through. On the report, human reviews fall and the tail shortens, with the number of units unchanged. Key-field validation on tasks and metadata checks before publication work the same way, and they all treat one thing: nobody should be making the same judgment repeatedly.

The same reading applies to vendor promises. A vendor committing to a faster response time, without being able to say which judgments must stay with a person and whose desk they sit on, is not committing along that line at all.

Five: congestion beats headcount

Where those 378 tickets landed is highly uneven: Product took 168, Operations 100, Capital 79, which adds up to 92% across three units. Research accepted 4 and Sales 16, even though those two units raised 75 and 69 tickets. Raising work and absorbing work are different capabilities, and when they sit on different sides, a queue piles work wherever absorption exists.

Our judgment: the constraint in an agent organisation is not the number of units but the distribution of absorption. Adding units does not spread congestion, it crowds the same entry point, because new units also hand work to the three places that can land it. Lowering p90 means changing the absorbing side. One practical lever is requiring the raiser to attach a recomputable acceptance condition, which cuts the time an absorbing unit spends reconstructing what was wanted. Put the criteria in the handoff and the task description can stay short; that is the direction we moved in recently.

Three things on the absorbing side can be changed today. First, when a ticket closes, state what the change covered and what it did not, two sentences is enough. Second, any recurring ticket must link back to its earlier one rather than entering the queue as new, otherwise the fact that this is the second occurrence is invisible in every report. Third, treat absorption as a work category of its own with a named owner, instead of letting it fall to whoever raised the ticket.

None of the three needs new tooling, and all three move cost from the tail to the entrance: write it once, skip four repeated steps later. Absorbing capacity can also be measured directly by counting how many cross-unit tickets a unit closed in a window and how many of those were recurrences. Those two numbers test the quality of the completion standard rather than the speed. We plan to add the recurrence rate to the standing report as a fifth number.

Six: the gap in the data itself

One gap has to be stated. Of the 352 closed tickets, 195 carry no record of who closed them, which makes any per-unit closure breakdown unreliable. We therefore report totals and percentiles only, and no ranking of which unit closes the most. Within the closures that do carry a name, the readable distribution is product 79, operations 33, capital 28, sales 8, ceo 6, research 2, but treating those numbers as a productivity ranking would be a misreading. They reflect recording habits, not workload.

The missing records are themselves a finding. A ticket status field is mandatory; the closer is not, so the more automated a path is, the less likely it writes one down. The work most often swept up by machines is precisely the work least likely to leave a name behind. This is why we say measurement definitions come before measurement tooling: which fields are mandatory determines the shape of the facts you end up able to see.

Seven: four numbers to report, two to drop

Report four. Throughput, meaning tickets opened and closed. Turnaround percentiles, median and p90, with p99 when the volume supports it. Human-review count, meaning tickets assigned to a person plus tickets that escalated. Absorption distribution, meaning the share of work taken by the top three absorbing units. Each points somewhere: throughput says whether the system is balanced, percentiles describe the experience, human review shows how much of the scarce resource is being spent, and absorption shows where the queue is stacking up.

Drop two. Ticket totals are the easiest number to misjudge, because they blend work swept up by automation with work that genuinely consumes time; the bigger they get, the better they look and the less they mean. Average turnaround is the second, since it carries no information in a long-tailed distribution and produces systematic optimism about the experience.

There is also a practical trigger worth keeping: when p90 exceeds ten times the median, look for congestion before adding units. That line is a rule of thumb drawn from this data. It is not precise, and it is precise enough to move attention from a capacity shortage back to the question of which segment is queueing.

Eight: when not to use percentiles

Percentiles need sample size. A median carries meaning with a dozen samples; p90 needs more, because its position sits around 0.9 times the sample count. In a month with 15 tickets, p90 is effectively the second slowest ticket, and its value gets amplified by a single accident, carrying more noise than information.

The substitute is to list the items directly: report the maximum, and give every ticket slower than ten times the median a line of its own explaining where it stalled. On small samples a list is more honest than a statistic.

We turned that into a threshold: below 30 tickets in a month, report the maximum plus per-item notes, and only report p90 above 30. That is not a strict statistical requirement. It is a discipline against misreading, because once an unstable percentile reaches a report, somebody will make a decision with it.

Nine: three questions and a four-line report

If you are evaluating a vendor or an internal agent system, ask three questions that reach past the score. What are median and p90 turnaround, and on what sample size? How many human judgments does a task take from opening to close, and whose desk do they wait on? What share of work do the top three absorbing units take, and which segment is congested?

The report skeleton follows that order. Line one: tickets opened and closed in the window. Line two: median and p90, with the sample size attached. Line three: human-review count and its share. Line four: the proportion taken by the top three absorbing units. Four lines is enough, and every one of them points at an action.

Next month we are making the closer a required field, replacing the deadline with a statement of who must judge a ticket and within how long, and checking coverage at closure, then watching whether p90 moves. Does your system report an average, or a percentile?

References

• Google SRE Book — Monitoring Distributed Systems (describe distributions with percentiles; every signal should point at an action)
• Google SRE Book — Service Level Objectives (target user-visible percentile lines rather than averages)

Every figure here comes from our own task-queue database for the window 2026-08-30 to 2026-09-29 (378 opened, 352 closed). The priority and absorption distributions are direct aggregations from that database, with no extrapolation and no third-party or vendor performance data involved.