Infrastructure Cost Management in Agent-Driven Software Factories

Infrastructure cost in an agent-driven software factory behaves differently from infrastructure cost in a traditional CI/CD pipeline, for structural reasons. Traditional cost thinking fixes on what happens at build time: compute spend, runner minutes, cloud bills, all of it measurable the moment a job runs, all of it easy enough to optimize with standard FinOps tooling built for exactly that purpose. Agents break that model by changing the rate at which pull requests arrive, not the rate at which the pipeline can absorb them. PR throughput climbs sharply once agents start writing code, but the merge queue, the CI fleet, and the review gates behind them were sized for how fast a person types and reviews, not for how fast a model produces a diff. The result follows the logic of the Theory of Constraints: a bottleneck does not vanish just because the step that used to cause it got faster, it moves to wherever the next slowest step sits, which in this case is the machinery that moves finished code through to merge.

That relocation matters because it changes where cost actually accumulates. It builds downstream, in queue wait times, in CI runs repeated for no new reason, in agent configurations carrying permissions and tools that keep executing on every single cycle whether anything uses them or not. Developer time still makes up the dominant share of agentic AI development cost, infrastructure is a smaller but real portion, and LLM API spend is a variable slice underneath both, but the public conversation about cost keeps circling back to the model invocation layer almost exclusively. That fixation leaves the operational layer, where the money actually moves, largely unexamined. Build cost itself makes up only 25 to 35 percent of three-year total cost, so the bulk of what a team will spend over the life of a system accumulates after launch, inside operational categories most budgets never accounted for. If the bottleneck has moved from writing code to moving code, the cost management strategy built around the old bottleneck has to move with it.

Merge queue dynamics and compounding agent waste

The relocated bottleneck appears first in the merge queue, with unusual mathematical precision. A serialized queue that handled a human-paced team without complaint turns into a cost multiplier the moment agents push PR arrival rates higher, because queueing behavior is nonlinear: small gaps between arrival rate and service capacity produce wait times that grow out of proportion to the gap itself. Service capacity in a serial queue is fixed by how long a CI run takes end to end, so a pipeline with a long full-suite runtime has a hard ceiling on how many PRs it can process per day no matter how many agents are submitting work against it. As arrival rates close in on that ceiling, wait times don't rise gradually. They explode, a property queuing systems under load have shown reliably across decades of operations research.

Agents make this worse in a way human contributors rarely do. An agent instructed to get a PR merged does not wait quietly when blocked. It re-queues, which burns a full CI run on every retry and pushes every PR sitting behind it further back in line. Manaflow-AI's cmux project offers a concrete look at what this costs in practice. Its merge queue on main went live on September 20, 2026, and until a two-tier rollout finished, every merge ran the full macOS test suite twice: once against the PR itself, once again in the queue. Cold build times on a Warp macOS runner ran 27.9 minutes, shorter when the change touched app Swift code, and a fraction of that when it didn't. The team sequenced its follow-up work by CI-minute savings, treating queue efficiency as a budget line. That instinct scales: Shopify's engineering organization has built multiple generations of a custom merge queue to handle more than 400 daily commits across over 1,000 developers, Uber built its SubmitQueue system to process hundreds of changes per hour while cutting CI resource usage by 53 percent, and Google's TAP system processes more than 100,000 commits a day and helped establish the merge queue pattern now common across the industry. None of these organizations treat queue efficiency as secondary. Solving the problem requires queue management that agents operate and adjust continuously instead of something a human glances at when a dashboard turns red.

What bloated agent skill sets cost at runtime

A second kind of waste accumulates at the level of the agent's own configuration, and it compounds with every CI run the merge queue already burns through. Skills added during development and never removed don't sit as a one-time sunk cost. They bill on every single invocation, indefinitely, as a recurring operational tax that nobody deliberately chose to keep paying.

At human working pace, that tax is close to invisible: one developer running an agent a handful of times a day won't notice a few unused tools loaded alongside the ones that matter. At agent-driven cadences, where a single agent might run dozens or hundreds of times a day, those same unused skills turn into a real line item, multiplied across every agent in the factory and every day the configuration goes unchanged. The gap escapes audit for a structural reason: skill sets get set once at deployment time and rarely get revisited afterward, and no standard dashboard puts "skills invoked" next to "skills loaded" the way it puts token spend next to the invoice. Finding that gap requires transcript analysis, reviewing what an agent actually called during its sessions against the full list of what it had available to call. That operational discipline is one most teams have not built yet, and its absence is why the waste persists.

CI fleet sizing for human throughput and its mispricing of compute at agent scale

The third point of accumulation sits one layer further out, in the CI fleet itself. Teams size infrastructure around the arrival patterns of the workload they expect, and human-paced teams produce patterns with natural gaps: nights, weekends, the hours between one developer finishing a review and another starting one. CI fleets can idle through those gaps without real waste, because the peaks are bounded by working hours and review cadences that don't move much week to week.

Agents don't produce those gaps. A fleet of agents can submit PRs around the clock, collapsing the off-peak windows a human-sized fleet depended on to stay cheap. A fleet provisioned for peak human load can end up chronically underprovisioned during the hours agents work hardest, but it still carries idle capacity during the narrow windows when no agent happens to be active. Autoscaling addresses the raw capacity problem; a qualitative problem sits beneath it and produces it: agents generate a larger share of marginal PRs, incremental refactors and speculative changes that still consume a full CI budget even though their value is lower than a human-authored change addressing a real need. Cost per merged change rises even as total volume climbs. Runner choice adds its own variance on top of that, because identical workloads can cost materially different amounts depending on which runner executes them, and that gap gets large enough to matter once volume reaches agent-driven scale. Separately, GitHub had announced a platform charge for self-hosted runner execution routed through its cloud, then postponed it to re-evaluate the approach; as of mid-to-late 2026, that $0.002-per-minute charge has not shipped, and self-hosted runners remain free of any such fee. Enterprise AI agent deployments commonly carry monthly infrastructure costs that nobody budgeted for at the project's start, because those budgets were built against human-scale usage assumptions that agent adoption has since made obsolete. Fleet sizing decisions made 12 to 18 months ago, in other words, may already be priced against a workload that no longer exists.

Treating the operational layer as a first-class infrastructure concern

Build-time infrastructure gets purpose-built tooling, FinOps guardrails, and cost visibility before a single deployment happens. The operational layer typically gets attention only once the invoice arrives, and then someone asks why it costs more than expected.

Mature platform engineering organizations handle this differently: cost visibility gets embedded at provisioning time, and cloud cost per engineer drops measurably in teams that apply FinOps discipline to the operational layer from the start. For a software factory specifically, that discipline breaks into several distinct shifts.

Agents need to operate merge queue management continuously, not just have a human check it periodically. Humans should step in for high-judgment calls, a conflict that needs real interpretation, a decision about priority between two competing changes, not for the routine mechanics of sequencing and retry that an agent-operated queue can handle on its own. CI fleet sizing decisions need to be made against models of agent-driven arrival rates, built from how agents actually submit work around the clock, rather than against historical baselines that describe a team of humans who worked in bursts during business hours. And skill sets need scheduled review against actual usage, closing the audit gap that the previous section described, so that configuration doesn't silently drift away from what agents actually need.

A fair objection follows from all three: assembling a factory out of composable pieces, a queue system here, a fleet-sizing model there, a skill-audit process alongside it, increases integration surface area and creates dependencies that aren't always obvious at the outset. That concern is legitimate. But the alternative, a single monolithic platform sized for general use, consistently fails to match the specific cost profile of agentic workloads, which vary sharply from one team's factory to the next. Composability costs something in complexity. A one-size-fits-all platform costs more in mispriced capacity, and that cost compounds the same way queue waste and skill waste compound: quietly, on every cycle, until someone finally goes looking for it.

What agent transcript analysis reveals about operational cost

Transcript analysis is the mechanism that makes the skill-audit shift possible, and it deserves a closer look on its own terms. Reviewing the full record of what an agent called, in what order, and at what cost is the only reliable way to find the gap between the skill set an agent carries and the skill set it actually uses session by session.

Tools built for this purpose, AgentOps among them, record complete session transcripts covering tool calls, model invocations, costs, and latency data, and that record supports session replay, which lets a forensic reconstruction of a single cost spike or failure down to the individual invocation that caused it. The discipline remains underused for a practical reason rather than a conceptual one: most teams haven't deployed the tooling that makes it possible, and the cost signals transcript analysis reveals are distributed across thousands of individual invocations rather than concentrated in one line a finance team can point to on an invoice. That distribution makes the case for investing in the tooling harder to build, even though the underlying waste is real and, once measured, often substantial.

Feeding production signals into agent cost optimization

The operational layer gains a third lever once you wire production feedback directly into it, and that completes the picture alongside queue management and skill auditing. The standard pattern today runs through a long chain: a production failure fires an alert, a human reviews a dashboard, root cause gets identified, a ticket gets filed, and eventually an agent or a developer addresses it. Each handoff in that chain adds latency, and the failure pattern keeps burning CI and retry budget the entire time it waits for a human to close the loop.

The alternative routes production signals directly into agent workflows, so an observed failure pattern can update agent priorities, skill configurations, or retry policies without waiting on a human review cycle to catch up. The cost implication is straightforward: a failure pattern that repeats across dozens of agent-driven PRs before a human notices represents waste that a closed loop would cut short or eliminate. AgentOps feeds session cost data back into fine-tuning prioritization, and that shows the pattern concretely, because cost spikes in production sessions can identify which agent behaviors most need correction. The broader principle holds beyond any one tool: software factories generate richer operational telemetry than human-paced pipelines do, because agent behavior is more consistently instrumented than human behavior ever was, and teams that route that telemetry back into the factory treat it as an asset that reduces cost.

Post-Launch Operational Costs for Teams That Don't Make These Changes

For teams that keep running human-centered operational practices underneath an agent-driven factory, the costs described across this piece compound over time. They escalate after launch, often past the size of the original build budget, as queue waste compounds with every retry, skill bloat bills on every invocation across a growing agent fleet, and CI capacity stays mismatched to a submission pattern it was never sized for. Build cost already accounts for only 25 to 35 percent of three-year total cost, and for teams that never bring the operational layer under the same discipline applied to build-time infrastructure, the remaining share keeps climbing. Enterprise deployments already carry monthly infrastructure costs most teams never budgeted for, and IDC's own estimate puts the underestimation of AI infrastructure costs at up to 30 percent, so for a meaningful share of these projects the operational layer accumulates costs severe enough to cause cancellation, ending the project.