An architect plans to cut median latency of a six-agent research workflow by running independent retrieval specialists in parallel. During a pilot, total wall-clock time barely improves and 429 rate-limit errors surge against a shared Azure OpenAI deployment and a shared search service. What should the team do to optimize task duration realistically?
Select an answer to reveal the explanation.
Short Explanation
The correct answer is D. Parallelism only helps when the shared bottlenecks can absorb the fan-out. Cap concurrency, use backoff on 429s, and consider dedicated or partitioned model and search capacity so independent specialists actually run together without stampeding one deployment. Tight infinite retries make storms worse. Giving up on parallel forever throws away real wins when work is independent and capacity is sized. Cloning the whole data lake to every agent is not how you fix Foundry rate limits.
Full Explanation
Option D is correct. Optimizing multi-agent task duration includes parallelism and rate-limit awareness. Independent specialists can run concurrently, but shared Azure OpenAI and search quotas require concurrency controls, exponential backoff, and sometimes capacity isolation. That combination addresses the pilot's flat latency and 429 spike without abandoning parallelism.
Option A is incorrect because aggressive immediate retries amplify rate-limit storms and can lengthen total time while harming other workloads on the same deployment.
Option B is incorrect because parallel orchestration is often beneficial for independent subtasks; the failure mode here is resource contention, not an inherent flaw of parallelism.
Option C is incorrect because wholesale local copies of enterprise data are operationally unrealistic, create security and freshness problems, and do not resolve model inference rate limits.