How Does Engineering Capacity Planning Work With Agents?

Agent-inclusive engineering capacity planning budgets for human review and supervision as the binding constraint, because AI coding agents generate pull requests at a rate unrelated to reviewer availability.

Why Sprint Capacity Stops Predicting Delivery

Developers can watch agents open pull requests while reviewers work a separate queue, all while the sprint spreadsheet reports spare capacity. That mismatch exposes the assumption underneath traditional planning: that developer hours spent writing code are the scarce input. Headcount times available days times a focus factor yields capacity, and velocity converts it into a story-point forecast. Faros AI's 2025 telemetry across more than 10,000 developers on 1,255 teams shows what agents do to that arithmetic: 98% more pull requests merged under high adoption, with pull request size up 154% and review time up 91%, and no significant correlation with company-level improvement.

Planning for that requires knowing what the agent platform will actually expose, because a forecast can only consume what it can read. Augment Cosmos, a unified cloud agents platform, is where those inputs live for teams running fleets: fleet size, permission boundaries, run history, and cost sit in configuration, not in individual developer setups. This guide starts with traditional capacity planning, then covers forecasting fleet output, budgeting supervision bandwidth, mixed human-agent models, fleet controls, and the mistakes teams make after adopting agents whose architecture gaps separate them from autocomplete.

How Traditional Engineering Capacity Planning Works

Traditional engineering capacity planning converts headcount and available hours into a story-point forecast by combining team-local velocity with a focus factor. Story points express relative effort by combining complexity, risk, and work volume. Team velocity is the sum of story points a team completes per sprint, while capacity estimates the hours available in the sprint ahead. Velocity does not appear in the 2020 Scrum Guide at all, and capacity appears once, where the Guide notes that developers who know their past performance and upcoming capacity forecast more confidently. Neither is defined as a practice, so point estimation and capacity arithmetic are both conventions layered on top of Scrum.

How Sprint Capacity Is Calculated

Teams calculate sprint capacity by subtracting leave and overhead from gross team hours, then applying the historical delivery ratio. The arithmetic runs in one direction: gross available hours come from team size, sprint days, and hours per day; planned time off, ceremonies, administrative overhead, and support rotation come off the top; and the remainder converts to story points through a ratio derived from past sprints. Every term in that chain assumes coding hours are the scarce resource, and planned availability determines the forecast, which is exactly the link agents break.

Where Velocity-Based Planning Already Fails

Velocity-based planning becomes unreliable when team-local estimates absorb unplanned work or become performance targets, because both weaken the relationship between points and completed work.

Estimation error is persistent, not transitional. Moløkken and Jørgensen's review of ten industry estimation surveys put average cost overrun at 30% to 40%, and their later survey found estimation performance largely unchanged; teams with different practices also can't compare velocity because each defines its own points. Both limit velocity before any agent joins.

Why Story-Point Planning Breaks When Agents Write the Code

Story-point planning breaks in agent-assisted workflows because agents sever the relationship between headcount, hours, and output that gave a point its meaning, which is the assumption engineering capacity planning has rested on since Scrum. DX puts the failure plainly: if an agent can generate 100 story points in an hour, the metric becomes meaningless. What replaces it is two forecasts held separately, one for generated output and one for available review hours, because the two now scale independently.

The delivery evidence supports keeping them apart. DORA's generative AI findings found that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, driven by larger batches that are slower to review and more likely to destabilize a system. The 2025 DORA report later found a positive relationship with throughput and a continued negative one with stability, so the throughput direction has moved across report years while the stability direction has not. Traditional capacity planning asks how much a team can build. Agent-inclusive planning also asks how much fleet production that team can verify before review queues, rework, or deployment risk consume the expected gain.

Forecasting Output Across an AI Agent Fleet

Fleet forecasting in engineering capacity planning runs on three inputs that estimate deliverable output rather than activity.

Acceptance Rate Varies by Agent and Task Type

Acceptance rate is the forecast's first deflator. Across 33,596 agent-authored pull requests in the AIDev-pop dataset, 71.48% merged, from 82.59% for OpenAI Codex down to 43.04% for GitHub Copilot, per an empirical study of failed agentic pull requests, with documentation, CI, and build updates merging most often and performance and bug-fix work least. That study is accepted at the Mining Software Repositories conference, which matters because most agentic pull request figures come from unrefereed preprints.

Pre-Merge Rework Applies to Work That Already Succeeded

Rework is the second deflator, and it lands on output that already cleared the first. In a study of 567 Claude Code pull requests across 157 open-source projects, 83.8% merged, and 45.1% of those merged needed further changes before they landed, most often for bug fixes, documentation, and project-specific standards. A separate study of 1,664 agent-authored pull requests found that in the 397 carrying revisions, 9.9% of added methods were deleted before merge, against 2.6% across all 12,343 methods added. A forecast that counts merged pull requests without discounting revision counts or reviewer hours as free.

Utilization, Impact, and Cost Turn Output Into a Budget

DX's framework tracks all three: utilization covers active users and the AI-assisted share of pull requests; impact covers time saved, delivery metrics, and human-equivalent hours; cost covers AI spend, net time gain per developer, and an agent hourly rate of human-equivalent hours divided by AI spend. The pricing structure determines how legible that last figure is. Augment Code's Business plan, which includes Cosmos, is a flat $100 per month for up to 50 seats with $100 of pooled usage included, and usage is billed at provider list price with a flat 40% service fee on model inference and none on compute, which makes the fixed and variable halves of agent spend separable in a model. Pair utilization with code quality metrics so adoption and quality land in one report.

Benchmarks Bound the Forecast Without Supplying It

Augment Agent v1 scored 70.4% on SWE-bench Verified, and Augment reports 51.80% for Auggie on SWE-bench Pro in February 2026. SWE-Bench Pro is partitioned into public, held-out, and commercial repository sets so results resist training-data contamination, a design property rather than a measured effect. A leaderboard is not production capacity, so forecast from representative tasks in the team's own repositories.

Supervision Bandwidth Becomes the New Capacity Constraint

Human review capacity replaces coding hours as the cap on team output when agent generation and reviewer availability scale independently.

DORA names the mechanism and prices it. Its verification tax is that time saved on writing gets re-spent on auditing, because engineers who don't trust generated code will not approve it without inspection, and 30% report little or no trust in AI-generated code. DX puts a ratio on the shift: in organizations with mature AI-native operations, the ratio of review time to coding time has moved from 1:4 to 3:1. A capacity model built on the old ratio understates the reviewer requirement by the largest term in the equation.

Five inputs make the supervision workload measurable, and each carries a figure, not a variable name:

Two mechanisms change where that ceiling sits: what a forecast can act on. Review quality is the first: Augment Code Review now runs on Cosmos as a set of specialized Experts, and Augment reports 59% F-score review quality for it, at 65% precision and 55% recall, on a company-run benchmark of 50 pull requests, and precision is what decides how much reviewer attention goes to noise instead of defects. Ranking is the second: Augment Code's Context Engine maps relationships across hundreds of thousands of files, which lets a reviewer work a queue ordered by blast radius, not arrival time. Both move the constraint without removing it, which is why the supervision budget stays in the model.

A Mixed Human-Agent Capacity Model

A mixed human-agent capacity model combines human and fleet inputs through an explicit supervision budget. The table below maps each traditional input to what replaces or extends it once agents are in the system:

One focus factor cannot carry both occupancy types: human availability needs utilization headroom, agent execution is bounded by platform throughput limits, and a blended factor hides which is binding.

Anthropic's own organizational data supplies both an input and a boundary. As of May 2026, more than 80% of the lines merged into Anthropic's codebase were Claude-authored, and in the second quarter of 2026 the typical engineer merged eight times as much code per day as in 2024. In a survey of 132 Anthropic engineers and researchers run in August 2025, more than half said they could fully delegate only 0 to 20% of their work to Claude. The second finding is a ceiling, and a coupled model built on the first without the second overstates what a fleet absorbs.

No validated developer-to-agent ratio exists across repositories, task types, and review standards, so engineering capacity planning has to measure it rather than adopt it. Set it from observed review time, task mix, and backlog growth locally, and read it against how much autonomy the team actually grants: in a Stack Overflow pulse survey of 1,100 developers and working professionals fielded in late April 2026, 63% said they rarely or never let agents run entirely on autopilot and 60% block agents from making unapproved system changes. Anthropic researcher Nicholas Carlini, describing a C compiler built by parallel Claude Code agents in February 2026, named the failure mode behind those limits: with autonomous systems it is easy to see tests pass and assume the job is done, when it rarely is.

What Is Agent Fleet Management?

Agent fleet management is what turns task state and resource use into inputs engineering capacity planning can consume. Each control surface below produces a number a planner needs, and a fleet missing one has capacity that can only be guessed at:

• Task assignment and orchestration: GitHub's Copilot cloud agent takes an assigned issue, plans the work, opens a pull request, runs tests, and requests review, and automations start it on a schedule or on repository events. Devin sessions are created programmatically with a prompt and a maximum ACU limit, and a coordinating session delegates to managed Devins in parallel. Google Jules runs each task in a secure Cloud VM, so tasks execute concurrently.
• Isolation and guardrails: Claude Code's sandbox runtime limits which directories an agent can read and write and which hosts it can reach, and git worktrees give each parallel session its own checkout.
• Observability: Claude Code exports metrics, events, and optional traces through OpenTelemetry, and Microsoft Foundry traces agent runs, capturing inputs, outputs, tool calls, token consumption, and latency. Augment Code's analytics API supplies the same class of input directly, exposing daily active users, per-user usage, and per-user credit usage with model breakdowns.
• Cost management: Each Copilot cloud agent session consumes one premium request, and its workflow run also consumes GitHub Actions minutes. Devin Enterprise bills in Agent Compute Units, and Cognition recommends keeping sessions under 10 ACUs because performance degrades in long sessions.
• Governance: Copilot cloud agent is disabled by default for Business and Enterprise subscribers until an administrator enables it. Microsoft Foundry provisions Entra agent identities: unpublished agents share one default identity, and publishing creates a dedicated one.

GitHub, Devin, and Jules all document a human reviewing the pull request before it merges. Claude Code documents permission approval for individual commands rather than a merge gate, so the boundary comes from branch protection, which any model assuming a human gate should encode.

Cosmos exposes those same controls as reusable objects, not per-developer configuration. An Environment is a reusable virtual machine bundling a base image, repositories, variables, and visibility, which fixes where an agent runs and what it can touch, and an Expert is a reusable template holding an agent's instructions, model, capabilities, and the triggers it reacts to. Standardizing that layer across squads replaces individual setups with unified workflow management, and it makes fleet size a number a planner can trust.

What Capacity-Planning Mistakes Do Teams Make With Agents?

Five mistakes account for most bad agent capacity forecasts, and all five share a shape: an easy number standing in for a hard one.

1. Trusting self-reported speedups: A METR randomized controlled trial of 16 experienced developers on 246 real issues found they took 19% longer with AI tools, yet afterward believed AI had sped them up by 20%. METR has since run a second experiment with a larger pool, so treat the 19% as one measured population and not a constant.
2. Not budgeting review as a line item: With DX describing a review-to-coding ratio shifting from 1:4 to 3:1 in mature AI-native operations, and review time up 91% under high adoption, a plan with no review line overstates capacity by the model's largest single term.
3. Mistaking individual gains for team gains: Individual output and delivery outcomes operate at different levels of analysis, which is why capacity models should read autonomous development metrics at the team level, not as aggregated individual perceptions.
4. Ignoring rework in the forecast: With 45.1% of merged pull requests in the Claude Code study requiring further changes, repository-level forecasts should discount generated output by observed revision, rejection, and rollback rates.
5. Cutting headcount prematurely: Establish measured review and delivery gains in the team's own environment first, because the delegation ceiling measured inside an AI lab was 0 to 20%.

Build Your Capacity Model Around Review Bandwidth This Quarter

Agent-inclusive engineering capacity planning starts with one measurement: the current verification ceiling, read through review time, queue depth, and decisions completed per reviewer. Size agent workload against that observed ceiling, not a model benchmark, since the leaderboard number and the repository number differ by construction. Add repository-specific churn and revision rates as forecast deflators, then recalculate at the cadence once used for sprint capacity. In that order, supervision demand becomes visible before the next agent is assigned, not later as an unplanned review queue.

Frequently Asked Questions About Engineering Capacity Planning

These are the questions engineering leaders ask when they are rebuilding a capacity model around agents and have to defend the numbers to finance.

Related Guides

• 6 AI-Human Development Collaboration Models That Work
• Top 5 AI Workflow Orchestration Platforms for DevOps
• AI Agent Quality: 7 Frameworks to Go Beyond Vibe Coding
• 5 Hybrid AI Coding Workflows for Production
• Engineering Velocity Metrics: 7 AI-Enhanced Frameworks