In short: Once verification keeps pace with agents, the constraint moves to integration: the main branch, the environments and the test data. A pipeline that survives agent volume maps each environment to one purpose, keeps iteration ephemeral, releases on a daily train gated by tests or feature flags, runs its neighbours like production, and treats test data as a product.
Where does verified change go next?
CircleCI's 2026 State of Software Delivery, based on more than 28 million workflows, found that average throughput rose 59% year on year. For the median team, feature branch throughput rose 15% while main branch throughput fell 7%, and the main branch success rate dropped to 70.8%, its lowest in five years and well below CircleCI's recommended 90%.
The July 2026 pulse report showed a modest recovery, with main branch success at 76.7%, and main branch throughput flat year on year while feature branches kept growing. CircleCI sells continuous integration, so the figures are best read as directional, although they come from pipeline telemetry rather than opinion.
The pattern is consistent across both reports. More code reaches the pipeline, and a smaller share of it lands cleanly on the branch that ships.
Why is integration the next constraint?
Constraint Migration predicts this sequence. When the Verification System raises verification capacity, more proven change arrives at the next stop, and that stop is integration: merging, building, deploying to shared environments and testing against real dependencies and real data.
This piece calls the limit at that stop integration capacity: the volume of verified change an organisation can merge, integrate and release in a given period while the main branch stays healthy. It sits beside verification capacity, and both measure the Absorption Gap at a specific stop rather than in general.
Agents stress integration in ways human teams rarely did. They open more branches in parallel, so merges collide more often. They multiply demand for environments, so shared environments queue. They multiply demand for test data, so data sets drift, collide or run out.
Every unreliable environment then produces false failures, which consume integration capacity without revealing a single real defect.
What does a pipeline that survives agent volume look like?
Five design choices tend to decide whether a pipeline absorbs a rise in change volume or breaks under it. None of them is new, and each becomes more valuable as volume grows.
Figure 1. The agent ready delivery pipeline. One environment per purpose, ephemeral iteration, a daily release train, neighbours run like production, and test data served as a product.
One environment per purpose. Logical and physical environments are mapped one to one to the main use cases: development, integration, UAT and regression, performance and production. Every test then knows where it runs and why, and a failure in one environment means something specific, instead of meaning that two kinds of test competed for the same space.
Ephemeral environments for iteration. Development runs on environments created for a change and discarded after it. Developers, and now agents, iterate without queuing for a shared environment, and an experiment that goes wrong disappears with its environment.
A daily release train. Changes move from integration to production on a fixed daily departure, and the entry rule is explicit: a change boards with strong tests, or it boards behind a feature flag. The train makes release a routine event, and the entry rule keeps the routine safe as volume grows.
Neighbours run like production. The applications around the core platform are kept up and monitored from UAT onward as if they were production, under release management, with backward compatible changes as the norm. Integration then stops depending on the weakest neighbour, and a change in one application does not break the tests of another.
Test data as a product. Key referential applications receive anonymised subsets of production data, refreshed on a regular cadence and reviewed periodically. A consolidated data lake is exposed as a data fabric to the test platform, which can draw data from files, APIs and databases, with fixed or dynamic retrieval. Tests get realistic data on demand, and nobody handcrafts data sets that age out within a week.
How did this hold at La Redoute?
This design was built at La Redoute for human volume, and it describes closely what agent volume now requires. Environments were first aligned by mapping logical and physical test environments one to one to the main use cases, from development through integration, UAT and regression and performance to production. Development then moved to ephemeral environments for fast iteration, and a daily release train ran from integration to production, admitting changes that carried strong tests or sat behind a feature flag.
Applications outside the core ecommerce platform had to be up and monitored from UAT like production, with release management and backward compatible changes. Key referential applications ran on anonymised production subsets refreshed weekly and reviewed every quarter. A data lake was consolidated and made available as a data fabric to Cerberus Testing, which retrieves data from files, APIs and databases, with fixed or dynamic retrieval, for flexibility, reliability and scale.
The results are public. The ecommerce test base grew to more than 7,500 automated tests and supported daily production releases of the website and mobile apps across international markets. The CNCF case study records commit to production falling below ten minutes and new services going live in minutes instead of days, and the platform as a whole moved from 40 to 80 deployments a day as the approach spread to the other applications.
What should the main branch tell you?
The main branch is where integration capacity becomes visible, so it deserves to be measured on its own. CircleCI's split between feature and main branches is the clearest diagnostic available: feature branch throughput rising while main branch throughput stays flat or falls is an integration problem, not a development problem.
Figure 2. More code, less delivered. For the median team, feature branch throughput rose while main branch throughput fell. Source: CircleCI, 2026 State of Software Delivery.
Five signals cover most of what a CTO needs to see:
main branch throughput, tracked separately from feature branch throughput;
main branch success rate, against a target near 90%;
time to restore a broken main branch;
the rate of flaky tests and false failures caused by environments;
the freshness of test data in each environment.
Together they show whether integration capacity keeps pace with supply. The hours people spend restoring the main branch or chasing false failures are human intervention as well, so they belong in the denominator of validated business value per unit of human intervention.
What tends to fail first?
Pipelines rarely fail at agent volume because of one missing tool. They tend to fail through habits that were tolerable at human volume and become expensive when change volume rises.
A single shared environment used for every kind of test is the most common. Functional, regression and performance tests then compete for the same space, and a failure no longer says which kind of problem it reveals. Handmade test data is a close second, because it ages quickly, collides between teams and cannot be produced as fast as agents consume it.
Large release windows are the third, since they batch many changes together and make every release harder to diagnose and roll back. Tightly coupled neighbours are the fourth: when an application cannot deploy without a matching change elsewhere, integration capacity is set by the slowest team involved. Tolerated flaky tests complete the list, because each false failure costs a person's attention while proving nothing.
In what order should you build it?
The order that tends to hold starts with purpose. Mapping environments one to one to their use comes first, because every later choice depends on knowing what each environment is for. Test data comes next, since realistic and available data is what makes the environments trustworthy, and it takes the longest to set up.
Ephemeral environments follow once the shared environments are stable, and the daily train comes last, when the entry rule can rely on tests and flags that already work. An organisation whose main pain is environment queues may reasonably start with ephemeral environments. What tends to fail is starting with the release train, which then runs on unreliable environments and stale data and turns every departure into an incident.
What happens one stop ahead?
Design one stop ahead. A pipeline with higher integration capacity puts more change into production, and the next stop is production operations: incident absorption, rollback, observability and the capacity of the people on call. Progressive delivery and feature flags already help there, and the operating side of that stop is the subject of later pieces in this series.
What should a CTO decide?
Fund environments and test data as shared capacity, sized to the supply the agent programme will create, rather than as a line in each team's budget. Make backward compatible change a policy for every application that others depend on, so integration never waits for the weakest neighbour.
Give test data a named owner, with anonymisation, a refresh cadence and a periodic review written into the role. Set the release train and its entry rule explicitly, so that boarding with strong tests or behind a flag is a standard every team and every agent meets.
The question for the main branch
Raising supply without raising integration capacity moves the queue from review to the main branch. The organisations that absorb agent volume will be the ones whose pipelines were designed for it before the volume arrived.
If verified change doubled tomorrow, would your main branch stay green, and would your test data still be there?
Read further
The thesis in full: Redesigning engineering production for the agentic era
The model this piece builds out: The AI Engineering Production System
The stop before this one: Designing the Verification System
Why the constraint moves: AI Won't Replace Your Engineering Bottleneck. It Will Move It.
What the system is optimised for: What Is Your AI Engineering System Optimising For?
The discipline behind it: Quality Engineered, Speed Delivered
FAQ
What is an agent ready delivery pipeline?
It is a delivery pipeline designed to absorb the higher change volume that AI agents produce without degrading the main branch. It maps each environment to one purpose, uses ephemeral environments for iteration, releases on a regular train with an explicit entry rule, runs neighbouring applications like production, and serves realistic test data on demand. Its health is measured on the main branch, not on feature branch activity.
What is integration capacity?
Integration capacity is the volume of verified change an organisation can merge, integrate and release in a given period while the main branch stays healthy. It is measured through main branch throughput, success rate and time to restore, set against the supply of verified change. It is the second stop at which the Absorption Gap can be measured, after verification capacity.
How many environments does a delivery pipeline need?
Enough that each one serves a single purpose. A common mapping is development, integration, UAT and regression, performance and production, with development on ephemeral environments. When two kinds of testing share one environment, their failures become hard to interpret and both slow down.
Are ephemeral environments enough on their own?
They solve iteration, because each change gets its own environment without queuing. They do not replace the shared environments where changes meet real dependencies, real data volumes and real performance conditions. Most organisations need both: ephemeral environments for development, and stable, production like environments from integration onward.
How do you provide production like test data safely?
A common approach is to refresh anonymised subsets of production data for key referential applications on a regular cadence, weekly for example, with a periodic review of what is extracted and how it is anonymised. Consolidating the data into a lake and exposing it to the test platform as a data fabric lets tests retrieve fixed or dynamic data from files, APIs and databases on demand. The cadence, the anonymisation rules and the review need a named owner.
Does a release train slow down continuous delivery?
A daily train is fast enough for most changes, and it makes release a routine event with a predictable rhythm. Its entry rule, strong tests or a feature flag, is what keeps it safe as volume grows. Changes that need to move faster can still use the same rule on an additional departure.