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
When 15 agents share one GitHub API budget, you don't fix it with 15 independent timers. You need a central gatekeeper that tracks the remaining limit, enforces per-agent quotas, and queues or rejects requests before the limit is hit. That stops the cascade before it starts.
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 such as per-agent exponential backoff and per-agent circuit breakers address symptoms rather than causes. The per-agent exponential-backoff approach is a recovery strategy, not a prevention strategy. When many agents 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. The centralized API budget manager service is correct because it solves the coordination problem at the right level. It maintains a real-time view of the system's total remaining rate-limit budget. It enforces per-agent quotas, preventing any single agent from monopolizing the budget. It queues or rejects requests proactively before the limit is hit, rather than recovering after. 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. The multiple-GitHub-App-credentials approach 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. The per-agent circuit-breaker approach is better than pure backoff but still a local solution. The circuit breaker on each agent prevents that agent from hammering the API after repeated failures, but it does not coordinate with other agents. One agent's circuit breaker opening does not inform another agent to slow down, so the other agent continues consuming budget until its own circuit breaker also opens.