A multi-agent system has 15 specialized agents that all call the GitHub API independently. During peak hours, the system triggers GitHub's secondary rate limits and multiple agents begin failing simultaneously. Which architectural change MOST effectively prevents this rate-limit cascade?
Select an answer to reveal the explanation.
Short Explanation and Infographic
When 15 people try to use the same garden hose at full blast, individual timers on each person don't fix the problem — you need someone at the tap managing flow. Per-agent exponential backoff and per-agent circuit breakers are local solutions to a global constraint. The centralized budget manager is the global solution: it enforces system-wide quota awareness before requests are sent, preventing cascades rather than recovering from them.
Full explanation below image
Full Explanation
Rate-limit cascades in multi-agent systems are a coordination problem, not a per-agent retry problem. Each agent acting in isolation cannot see the system's global API consumption — so local solutions (backoff, circuit breakers) address symptoms, not causes.
Option A (exponential backoff per agent) is a recovery strategy, not a prevention strategy. When 15 agents all hit the rate limit simultaneously, they all back off, then they all retry simultaneously, causing another wave of failures. Coordinated wave patterns are a known failure mode of uncoordinated backoff without jitter and without global budget visibility.
Option B is correct because a centralized budget manager solves the coordination problem at the right level: (1) It maintains a real-time view of the system's total remaining rate-limit budget. (2) It enforces per-agent quotas, preventing any single agent from monopolizing the budget. (3) It queues or rejects requests proactively before the limit is hit, rather than recovering after. (4) It can implement intelligent prioritization — letting high-priority agents consume more budget during peak periods while throttling low-priority agents. This transforms a reactive per-agent problem into a proactive system-level control.
Option C (multiple GitHub App credentials) spreads the problem but does not solve it. If agents are partitioned across credentials, you now have multiple smaller rate-limit pools that each agent can independently exhaust. The fundamental coordination problem remains within each credential group. Additionally, this adds credential management complexity and may violate GitHub's terms of service if credential splitting is done to circumvent rate limits.
Option D (per-agent circuit breaker) is better than pure backoff but still a local solution. A circuit breaker on each agent prevents that agent from hammering the API after repeated failures, but it does not coordinate with other agents. Agent A's circuit breaker opening does not inform Agent B to slow down — Agent B continues consuming budget until its own circuit breaker also opens.