CI shared queue - everyone waits

A shared CI queue processes all build and test requests in a single pool of runners, regardless of their source or priority. A human developer's critical pre-merge PR check sits behind 20 agent-generated experimental branches. A release build competes with a batch of AI-generated refactoring candidates. When CI runners are fully occupied, everything queues. Wait times grow from seconds to minutes to tens of minutes, and the team learns to avoid pushing code during busy periods.

This was an acceptable tradeoff when CI load was predictable and primarily human-generated. Developers pushed code a few times per day, and CI capacity could be sized to keep queue times under 5 minutes. AI agents break this model entirely. A single developer running 3-5 parallel agents can generate 10-20x more CI runs per day than before. A team of 20 developers each running 3 agents can saturate a CI cluster that was sized for 20 humans.

The queue contention problem has two distinct failure modes. The first is latency: human developers wait longer for CI feedback on their PRs because agent runs are occupying the queue. The second is throughput: agent iteration loops slow down because agents can't get CI feedback quickly enough to iterate at their natural speed. Both failure modes feed each other - slower CI feedback means agents and humans pile up more work in the queue, making queue times even longer.

The shared queue is a fair resource allocation mechanism when all requestors have similar priority and frequency. AI agents change both variables: they have lower priority than release-blocking human work, and they have much higher frequency. A shared queue that treats all requests equally will systematically deprioritize the high-value work (human pre-merge checks) in favor of the high-volume work (agent iteration).

• Agent CI frequency is 10-50x human CI frequency - a shared queue that worked for humans will saturate when agents use the same pool, even with the same number of developers
• Queue wait time directly limits agent iteration speed - an agent waiting 15 minutes for CI feedback cannot iterate faster than once per 15 minutes, regardless of how capable the agent is
• Human developers bear the cost of agent queue saturation - when agents fill the CI queue, humans experience longer PR feedback times, which degrades their experience with AI tooling and creates org friction
• The problem is invisible until it's critical - CI queue times creep up gradually as agent usage increases, and teams don't notice until developers start manually canceling and re-queuing builds
• Separation is cheap relative to the cost of contention - dedicated runner pools for agent workloads cost more in infrastructure but less in developer time lost to waiting

1. Measure current queue wait time by source - Tag CI runs by origin: human push, agent-generated branch, scheduled run, etc. Calculate median and 95th percentile queue wait time for each. This establishes the baseline and quantifies how much agent runs are affecting human PR feedback times.
2. Separate runner pools - Create a dedicated runner pool for agent-generated CI runs. In GitHub Actions, this is a separate runner group. In Jenkins, it's a separate agent label. In GitLab CI, it's a separate runner tag. Route agent-triggered runs to the agent pool and human PRs to the human pool.
3. Define "agent-generated" programmatically - Branches following a naming convention (agent/, ai-, claude-) should automatically route to the agent CI pool. Add this routing rule to your CI configuration so it's automatic, not a manual step.
4. Size the agent pool for burst capacity - Agent CI load is bursty: when a batch of agents are in active iteration, they generate many CI runs simultaneously. Size the agent runner pool for peak burst capacity, not average load. Auto-scaling runner pools (GitHub Actions, GitLab, CircleCI) handle this more cost-effectively than fixed-size pools.
5. Set agent CI timeouts aggressively - Agent runs that fail should fail fast. Set lower timeouts on agent CI runs (15 minutes instead of 30) to free up runners more quickly. An agent that can't complete in 15 minutes has either encountered an infinite loop or is working on a problem that needs human intervention anyway.
6. Monitor queue depth separately - Track queue depth and wait time separately for human and agent pools. Set alerts for when human queue wait time exceeds your SLO (e.g., 5 minutes). This catches CI capacity problems before they affect developer experience.

Treating agent CI as identical to human CI. Agent CI runs have different characteristics: higher frequency, lower criticality, different test profiles (agents often want fast feedback, not the full suite). Routing them to the same queue with the same configuration misses the opportunity to optimize each independently.

Under-sizing the agent runner pool. Teams that create a separate agent pool but size it conservatively will find agents still queueing. The agent pool needs to be sized for the peak concurrent agent load your team runs, not the average. If 20 developers each have 3 agents in active iteration simultaneously, the agent pool needs to handle 60 concurrent builds.

Not defining branch naming conventions. If agent branches aren't consistently named, CI routing rules can't identify them automatically. Establish and enforce a branch naming convention for agent-generated branches before implementing queue separation. This is a convention that should be in your CLAUDE.md or equivalent agent instruction file.

Forgetting about merge queue contention. Separating build queues doesn't solve merge queue contention if agents are trying to merge PRs. A merge queue with 20 agent PRs waiting to merge will block human PRs even if the CI queues are separate. Implement separate merge queue lanes or rate-limit agent PR merges.

Making the agent pool too expensive by running full test suites. Agent CI runs during iteration don't need to run the full test suite - they need to run the tests relevant to what the agent changed. A fast feedback profile (compilation + unit tests for changed modules) costs a fraction of a full CI run and gives agents the signal they need. Save the full suite for pre-merge validation.