Most enterprises have an agentic AI mandate and a flat headcount. The engineers who could deliver it are already committed, and the capacity has to be released from work the organisation is doing today. Most IT service teams are already overloaded with exactly that work.
This article covers where that capacity is currently held, why efficiency programmes rarely release it, what an integration failure costs beyond IT hours, how to measure what your organisation actually has trapped, and which interventions produce capacity that lasts beyond the next planning cycle.
Key takeaways
Capacity created by efficiency is reabsorbed, because the team still owns the work. Capacity created by transferring accountability does not come back.
IT teams spend 36% of their time on custom integration work, according to MuleSoft's 2026 survey of 1,050 IT leaders, while the connected share of the application estate fell from 29% to 27% year over year.
In the same research, 82% of IT leaders name data integration as a major obstacle to implementing AI. The work consuming capacity is also the work blocking the outcome.
Integration failures cost more than IT hours. While a flow is down, the business process it carries stops, and that disruption never appears on the integration budget line.
Hours understate the problem. Integration maintenance is interrupt-driven, and interrupts destroy the contiguous blocks in which agentic and architectural work gets done.
For the operating model behind managed integration services, the Integration Ops book covers lifecycle phases, ownership patterns, and playbook examples in depth. Download it free.
What does capacity for AI actually mean?
Capacity for AI is the availability of engineers who understand how the organisation's systems behave in production, in blocks of time long enough to design and test autonomous behaviour safely. It is a function of who is free, what skills they hold, and how often they are interrupted. Headcount alone does not describe it, which is why organisations with stable IT staffing still report having nobody available for agentic work.
The distinction matters because the three components fail independently. An organisation can have spare people with the wrong knowledge, the right people with no uninterrupted time, or the right people fully committed to keeping existing services running. Each requires a different intervention, and only one of the three is solved by hiring.
Why efficiency programmes do not release capacity
Interventions fall into two classes, and they behave differently over a planning cycle. Both are worth doing; only one of them shows up in next year's resourcing.
Efficiency interventions make the same team faster at work it continues to own. Better tooling, workflow automation, an AI coding assistant, a low-code platform. The gain is real and measurable at first. It also erodes, because ownership generates demand: the team that owns a service absorbs every request that service creates, and the freed hours refill from the backlog that was already there.
Ownership interventions remove the work from the team's accountability. Somebody outside the team monitors it, holds the escalation path, and answers for the outcome under a service commitment. The hours do not return, because the mechanism that used to reclaim them no longer points at your team.
The practical test is one question. After the change, who gets called when it breaks? If the answer still includes your engineers, the capacity is on loan.
We have argued separately that adding headcount does not solve IT service scaling, because knowledge transfer and coordination costs grow faster than the team. This article addresses the sharper 2026 version of the problem. Where does capacity for a genuinely new class of work come from when nobody is being hired?
Where the capacity is currently held
MuleSoft's 2026 Connectivity Benchmark Report, based on 1,050 IT leaders globally, puts integration at 36% of IT time spent designing, building and testing custom integrations. The 2025 edition of the same study reported 39%.
Those figures cover the build phase only. Our position: design, build and test is a fraction of the total cost of an integration over its lifetime. The rest arrives after go-live, when the connection carries a live business process and every failure interrupts work far beyond the IT team.
The trend underneath the figures is the other useful part.
The estate grew by roughly 7% while the connected share fell. The time spent barely moved. An organisation in this position is running to stand still, and the work being displaced is whatever it planned to start next.
ONEiO's own research on the state of integration solutions points the same direction from the delivery side, with resource constraints reported as a leading cause of integration project delay. The constraint is people, and it has been for some time.
PwC's 2026 Digital Trends in Operations Survey points the same direction from the buyer side: of 767 US operations executives whose technology investments have not fully delivered, 52% name integration complexity as the top reason, ahead of data issues and user adoption.
The capacity you need has a specific shape
Capacity is usually discussed as though engineers were interchangeable units. For agentic work they are not.
An agent that acts across systems needs someone who understands data contracts, system semantics, failure modes, and how each connected platform behaves under production load. That knowledge is unevenly distributed, and it concentrates in one group: the people who maintain the connections. Integration maintenance is the only role that requires knowing every system at once, because a broken flow can originate anywhere along it.
Gartner's April 2026 research on AI in infrastructure and operations found that 38% of I&O leaders facing setbacks cited persistent skill gaps, with only 28% of AI use cases fully succeeding against ROI expectations. In many organisations those skills already exist in-house, fully occupied with keeping the current estate running.
This has a direct planning consequence. Releasing capacity from first-line support produces hours. Releasing capacity from integration maintenance produces the specific people who can make an agent safe. The two are not substitutes.
For a fuller view of what agents require from the layer beneath them, see our analysis of what changes when AI agents enter your integration layer.
Measure interrupts, not hours
A timesheet showing six hours a month on integration support looks manageable. It is misleading, and Google's SRE practice explains why.
Google caps operational toil at 50% of an SRE's time by policy, and its own quarterly surveys report an average of about 33%, with a spread from 0% to 80% across individuals. Two findings carry over to any IT organisation. Trapped capacity sits in specific individuals, so an organisational average says little about who is available. And the leading source of toil is interrupts.
Integration maintenance is interrupt-shaped by nature. A partner changes a field. A certificate expires. A sync stops without an alert and surfaces days later when two systems show different figures. Some of these are serious incidents in their own right, and even the small ones require the person who understands the whole chain.
The cost does not stay inside IT. While a flow is down, the process it carries has stopped: orders wait, tickets stall, a partner or customer is affected, and any service commitment attached to the process is at risk. Six hours on the IT timesheet can mean far more lost time across the organisation, none of it budgeted anywhere, and all of it money that could be funding the AI initiative instead.
Inside the team, six hours spread across fifteen interruptions removes every block long enough for design work. Building an agent that acts safely across several systems is not a task that fits between escalations.
The third column is rarely measured and is usually the one that explains why an approved AI initiative has not started. Proactive monitoring is the discipline that moves an organisation from column two to column three, by catching failures before they become interruptions.
Will AI free the capacity on its own?
This is the most common objection to the whole argument, and the current evidence does not support it. In the 2025 Stack Overflow Developer Survey, 66% of developers name "AI solutions that are almost right, but not quite" as their biggest frustration, and 45.2% report that debugging AI-generated code takes longer than writing the code themselves.
That describes a change in the type of senior work, with authoring time becoming verification time. Verification is still senior, still interrupt-driven, and still unavailable for building something new. AI assistance is worth having and it is not a capacity strategy.
The final column is the one that separates the rows. Three of the four approaches leave accountability where it was, which is why the capacity they create is provisional.
Where a managed integration service fits
A managed integration service takes ownership of the connections themselves, including monitoring, incident response, change, and the service level attached to each one. The provider is on the escalation path.
For a capacity programme the effect is specific. Interrupt volume falls, because failures are detected and handled outside the internal team. The engineers who held the most systems knowledge become available in contiguous blocks. The business processes riding on those connections stop absorbing unplanned downtime. And the integration estate stops blocking the agentic work, because connections are operated to a commitment, with someone whose job it is watching them.
"Unbothered. I think that's the thing, how it changed us... we use our time to do other things, to monitor other things instead of the data exchanges." That is Dmitri at the City of Espoo, describing what the change looks like from inside the team.
When this is not the right choice. If your integration estate is small, stable and internal, the interrupt load is already low and there is little capacity to release. If your engineers are genuinely free and the binding constraint is skills, training or hiring addresses that more directly. And if integration is your differentiator, keeping the capability in-house is a reasonable strategic choice. The case strengthens with estate size, the number of external parties involved, and the rate of change in connected systems.
Bottom line on capacity for AI
In most organisations the capacity for AI already exists. It is allocated to keeping a growing, partly connected application estate working, and the organisation pays for that allocation twice: once in engineering hours, and again in the disruption each failure causes to the processes those connections carry.
Two things follow. Efficiency programmes will not release the capacity, because the team keeps the accountability that reclaims the hours. And the pool worth targeting first is integration maintenance, because it holds both the largest share of engineering time and the specific people whose systems knowledge makes agentic work safe.
Start by measuring. Run the capacity ledger for one month across your senior engineers and look at the third column. If the longest uninterrupted block in the month is under half a day, the AI initiative is waiting on capacity, not on budget or skills.
Not sure where your integration layer stands? The Integration Ops maturity assessment gives you a structured read on ownership, monitoring, and change readiness across your estate.
