During a flash sale, your multi-agent support system tries to spawn a new specialist agent per concurrent user message, exhausting model rate limits and budget. Which implementation control is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
You need controlled concurrency: queues, worker pools, batching, rate-limit-aware throttles, and backpressure so spawning doesn't melt quotas. The unlimited quota approach doubles down on the failure mode, the single-agent-thread approach over-corrects into a bottleneck, and hiding rate-limit errors lies to users. Multi-agent systems need explicit concurrency governance tied to rate limits and cost.
Full Explanation
Implementing scaling controls for multi-agent spawning, batching, and concurrent execution, including queues, worker pools, rate-limit aware throttles, and backpressure, is correct because developers must control spawning, batching, and concurrent execution. Rate-limit-aware throttling and queues protect platform stability during spikes. Buying unlimited quota without instrumentation is incorrect: unlimited concurrency without control risks outages and cost overruns. Serializing the entire global workload to a single agent thread forever is incorrect: total serialization may miss latency SLOs under load. Hiding rate-limit errors from the orchestrator is incorrect: masking failures prevents remediation and harms trust. Expose metrics on queue depth, spawn rate, 429s, and rejected work.