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.

·Build uses default tool configuration (Maven/Gradle defaults, npm scripts without optimization)
·Full rebuild runs on every change (no incremental build support)

·Build completes (even if slowly)
·CI runs builds on a shared queue (even if everyone waits)

Evidence

·Build configuration file with default/untuned settings
·CI logs showing full rebuild on every PR

What It Is

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).

Why It Matters

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

Getting Started

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.
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.
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.
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.
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.
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.

Tip

GitHub Actions supports runner groups with concurrency limits. Create a "human-prs" group with no concurrency limit and an "agent-iterations" group with a concurrency limit sized to your available capacity. Runs in "human-prs" will never wait behind agent work.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team leads are reporting that PR review cycles have gotten longer. Developers push a PR, wait for CI, and the wait has gone from 5 minutes to 20 minutes. Bob initially assumes CI capacity is insufficient and considers adding more runners. He doesn't realize that agent runs from his AI-enabled developers are filling the shared queue.

What Bob should do: Bob should pull a CI utilization report segmented by branch source. He'll find that agent-generated branches represent 40-70% of CI runs but have lower urgency than human pre-merge PR checks. Bob should implement runner pool separation as a one-day infrastructure task: create a separate runner pool for agent branches, route agent runs there, and restore human PR CI to its original performance. Bob should also set a CI SLO for human PR feedback time (e.g., 95th percentile under 8 minutes) and monitor it as a team health metric. The runner separation pays for itself in developer experience within days.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has added CI wait time to her DevEx dashboard and is seeing it trend upward as agent adoption increases. Developers are starting to associate "AI tooling" with "slower CI" - the opposite of the intended outcome. She needs to address this perception before it becomes a barrier to agent adoption.

What Sarah should do: Sarah should present the CI queue data to the infrastructure team and frame it as a capacity planning problem created by success: agent adoption is working, but CI infrastructure hasn't scaled with it. She should push for runner pool separation and separate queue monitoring. Once separated, Sarah should communicate the change clearly: "we now have dedicated CI capacity for agent workflows, human PRs are no longer competing with agent iterations." This reframes the narrative from "AI slows down CI" to "AI has its own CI lane" - an important perception shift for continued adoption.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor runs 5 parallel agents and generates more CI runs in a day than the rest of his team combined. He's already noticed the queue problem and worked around it by scheduling his agent sessions for off-peak hours. This works but limits when he can effectively use agents.

What Victor should do: Victor should build the business case for auto-scaling agent CI infrastructure. Fixed-size runner pools are expensive to size for peak load. Auto-scaling pools (ephemeral runners that spin up on demand and terminate when idle) can handle Victor's peak burst while costing near-zero during off-peak hours. Victor should pull a week of CI run data, model the cost of a fixed-size pool versus an auto-scaling pool at current agent load, and project costs at 3x current agent adoption. The auto-scaling option will be cheaper at scale. Victor should present this to Bob as infrastructure that enables the team to increase agent adoption without a proportional increase in CI cost.

What Victor should do - role-specific action plan