Enterprise support was built for a clock speed that no longer exists
Contents
For about twenty years, enterprise applications ran on a slow, predictable clock. You patched monthly. You did a big platform upgrade every year or two, planned well in advance, with long stretches of stability in between. Support was tiered humans matching known problems to known runbooks. The whole model assumed change was slow and scheduled, and for two decades that assumption held.
The comfortable story now is that AI quietly takes that same model and makes it cheaper. Agents pick up the front line, deflection climbs, the service desk shrinks. That part is real and worth doing well. It is also the easy half, and it distracts from what is actually happening underneath it.
That clock has now broken in three places:
- Security, because AI now finds and weaponises flaws faster than any patch cycle was built to handle, across a surface that keeps growing
- Architecture, because vendors have abandoned the scheduled upgrade for continuous change you do not control
- Support, because the work itself is shifting to AI agents that fail in ways nobody designed
The same AI that resolves your tickets is finding the vulnerabilities, forcing the releases, and doing the work. Most commentary treats these as three separate conversations owned by three separate teams. They are one shift, and it all lands on the application support function - the team(s) responsible for lifecycle, support, patching, upgrades and the break/fix that keep software alive. It is the least re-architected part of the estate and the place all three collide.
You cannot bolt AI onto a support model built for a world that changed underneath it. The operating model itself has to change.
Clock one: the exploit window went negative
A class of AI systems now finds real, novel vulnerabilities faster than humans ever could. This is not a single vendor’s party trick. An autonomous AI penetration tester topped HackerOne’s US leaderboard in 2025, out-submitting every human researcher. Google’s research agent found a live-exploited SQLite flaw, this was the first time an AI caught an in-the-wild bug before the attackers finished using it. Frontier models from more than one lab have started turning up zero-days across operating systems and browsers, including one preview release that reported the majority of its finds were still unpatched at disclosure.
If you cannot see what an agent is doing, it is a risk, not a productivity gain.
The same capability that helps defenders is available to whoever is attacking you. When discovery gets cheap and fast for defenders, it gets cheap and fast for everyone. And discovery is only half of it. Writing a working exploit, the step that used to demand a skilled human and time, is the part AI is collapsing fastest. The data already shows the consequence. Mandiant’s M-Trends 2026 reports that the median time-to-exploit has gone negative, estimated at roughly a week ahead of the patch in 2025, meaning that on average exploitation now begins before a fix is available. Exploits were the number one initial infection vector. The comfortable gap between “a vulnerability is disclosed” and “we get around to patching it” is the thing that just disappeared.
Volume is moving the same way. More than 48,000 CVEs were published in 2025, up over twenty percent year on year and the highest annual total on record, roughly 130 a day.
Most organisations still patch in weeks
Set that against how fast enterprises actually patch. In one 2025 survey of security and IT teams, only nine percent could remediate critical vulnerabilities in production within 24 hours, and more than three quarters took longer than a week. So the exploit lands in negative time and the patch lands in weeks. A faster change window will not close that gap. The model is too slow for the job.
It gets worse before it gets better, because we are also generating vulnerable code faster than we can review it. Veracode found that 45 percent of AI-generated code failed basic security tests, and that the newer, larger models were no safer than the old ones. And the surface itself keeps growing on every side. As AI-assisted and citizen-built apps multiply, the same way cheap production multiplies output, there is more to keep patched and defended: the apps, the SOE and supporting systems beneath them, and every new security control and integration you add to keep up, each one more software that can break and has to be watched. The patch load is the downstream bill for every app you let people build.
The implication for support is direct. Patching can no longer be a monthly ceremony, and the standard operating environment can no longer be a thing you refresh once a year. The mechanics differ across the estate: a SaaS platform can update itself whether you are ready or not, an on-prem server you still patch on your own cadence, a workstation app you have to package and push to the fleet, the OS runs a different clock again. The direction, though, is identical. Update cadence must become continuous and largely automated, because the clock you are racing does not keep office hours.
Clock two: the annual upgrade is already dead
The vendors said it out loud. In March 2026, Microsoft told its business-applications customers it was moving beyond twice-a-year launches to lighter, more frequent updates, and put the reason plainly: “innovation does not happen twice a year; it is constant.” Salesforce now ships its agent platform on a continuous delivery model rather than its usual three-times-a-year cadence, explicitly to keep up with the velocity of AI features. That breaks the planning assumption most application strategies are still built on.
There is a sharper edge to this in any regulated industry. When a vendor changes how a process behaves without asking, that is not always a support ticket. In finance or healthcare it can be a compliance event, a control that quietly stopped doing what your last audit said it did. The same logic runs through to agents acting on your behalf. When an autonomous agent makes a costly decision off the back of a feature that shipped overnight, the question of who is accountable, you or the vendor, is not one most current contracts were written to answer.
I have run the other model. I have led the twelve-month re-platforming programme that used to be the hallmark of a mature applications function, dragging a heavily customised core platform back to a clean, near out-of-the-box baseline so it could be upgraded sanely again. That work mattered, and the discipline behind it still does. But the cadence it assumed, a big considered push every few years with long stretches of stability in between, is gone. On-prem you can still resist for a while, freezing versions to hold a stable fleet, but coupling makes that harder: the moment one team upgrades a shared platform, everyone working off the same models is dragged with them. We no longer own the release calendar, the vendor does, and the vendor’s calendar is “always.”
The out-of-the-box instinct that used to be about keeping upgrades cheap is now about keeping upgrades survivable
Build architecture that flexes with the platform
When change is continuous, customisation stops being a convenience and becomes a standing liability. Every heavy customisation is something that can break on a Tuesday you did not choose. The architecture that survives this is the one designed to flex with the platform rather than freeze it in place: configuration over customisation, loose coupling over deep integration, continuous automated regression testing as a permanent capability rather than a project phase, and a system that can restart and update without losing a user’s place, because change that wipes someone’s working state every day or week is not an upgrade, it is a scheduled outage. The out-of-the-box instinct that used to be about keeping upgrades cheap is now about keeping upgrades survivable when they arrive every week.
There is a second architectural shift hiding inside this one, and it points straight at the third clock. You are no longer only designing systems for human users clicking through screens. You are designing them for agents, which means least-privilege access, observability, and legibility have to be built into the design rather than bolted on afterwards. Supportability and patchability stop being qualities you inspect for at the end. They become design inputs.
Every heavy customisation is something that can break on a Tuesday you did not choose.
Clock three: agents are the new actor and the new workload
Agents are becoming first-class participants inside enterprise systems, not features sitting beside them. Gartner expects 40 percent of enterprise applications to include task-specific AI agents by the end of 2026, up from less than five percent in 2025. Treat the precise number as directional. The direction is not in doubt, because it is written into every major vendor’s roadmap. The rails are hardening to match. The Agent2Agent protocol passed 150 organisations and a stable 1.0 in its first year under the Linux Foundation, with native support across the major clouds, and the open Model Context Protocol has become the common way to connect agents to data and systems, the integration layer I went deep on in building an MCP server. The workflows that used to be hardcoded, step one calls step two calls step three, are starting to be replaced by agents negotiating outcomes between themselves.
The story everyone tells about support and agents is the easy half. Yes, agents will handle the front line. Gartner expects agentic AI to autonomously resolve 80 percent of common service issues by 2029, cutting operational costs by around a third. That part is real and worth doing well. I have watched a virtual agent move deflection from less than a fifth of contacts to more than nine in ten, and the benefit to a service desk is not subtle.
Agents create a new kind of support problem
Here is the half that gets less airtime, and it is the one application leaders should sit with. When orchestration moves from designed workflows to agent-to-agent interaction, the failures stop being deterministic. A hardcoded workflow fails in known ways you can write a runbook for. An emergent interaction between agents fails in ways nobody specified, because nobody specified the interaction in the first place. “The agent did something unexpected with a system it had access to” is not a ticket type the tiered service desk was built to handle. You do not fix that with a better runbook. You fix it with telemetry into what the agent actually did and why, and most estates cannot see that today.
There is also a population of agents you never sanctioned. The same people who quietly built spreadsheets and macros to paper over the gaps in your applications are now pointing personal agents at enterprise systems to do the same thing. Bring-your-own-agent is shadow IT with permissions, and it arrives at support as failures in workflows that exist in no service catalogue.
And agents are software. They inherit clock one, because they have vulnerabilities of their own and they need standing access to data and systems, which is attack surface that did not exist last year. They inherit clock two, because they are updated continuously by vendors and by your own teams. Whether the AI acted usefully or did something quietly wrong is, as I argued in the interface is the product, a question of whether you built the legibility to tell. The three clocks are not three problems. They are one clock, and support is where it strikes.
Where it all collides
The tiered support model rests on four assumptions. AI has broken all four.
- Change is slow, so you can batch it into windows. Clock two ended that.
- Systems are deterministic, so a known input has a known fix. Clock three ended that.
- Users are human, so support is a human-to-human conversation. Clock three added a second population of non-human actors that also need supporting and governing.
- Issues are known, so most of the work is matching a symptom to a runbook. Clocks one and three made novel, emergent failure the normal case rather than the exception.
Support is the least re-architected of the three functions and the one where all three accelerations compound. The patch you cannot apply fast enough, the vendor feature that changed behaviour overnight, and the agent that did something nobody designed all arrive at the same desk. That is the wake-up call. If you only ever modernise two of the three clocks, the third one becomes the bottleneck for the whole organisation, and it will be support.
Principles for the model that replaces it
I don’t have a playbook, because the right shape depends on your estate and the honest answer in 2026 is that everyone is still learning the details. What I do have are some principles that I’ve been designing against. None of them is a tool you buy. Each is a decision about how the function works.
Run on the threat and vendor clock
Run support on the threat clock and the vendor clock, not your project calendar.
Patch handling, update absorption, and regression testing become a continuous flow rather than scheduled events. This is the operating discipline behind a self-managing pipeline I built: automate the work that does not need human judgment so the humans are free for the work that does. The cadence of the function has to match the cadence of the threats and the releases hitting it, which means continuous by default.
Build for losing the patch race
Assume you will lose the patch race, and build the controls for losing it.
If exploitation now beats the patch, fast patching is not sufficient. The controls that matter are the ones that work while the fix does not exist yet, and they belong to security. Prioritise by real exposure rather than raw CVE count, because a hundred and thirty disclosures a day cannot all be urgent, so exploit-prediction scoring and the known-exploited lists should drive the queue ahead of severity alone. Put compensating controls where patching cannot reach: virtual patching and WAF rules, segmentation that caps the blast radius, and detection and response tuned for the window after a vulnerability is exploited and before it is fixed. Govern agents as the identity surface they now are, with least-privilege scoped permissions, short-lived credentials, and monitoring for the non-human accounts that already outnumber the human ones. This is the part of the operating model the security function owns.
The right people, not fewer
Staff for capability, and automate everything you can.
The lazy version is “do it with fewer people,” and it is rarely what happens. The work does not shrink, it shifts and changes: more systems and agents to supervise, more change to absorb, and far more output to review and govern. Production went nearly free; reviewing it did not. That is the consumption bottleneck landing on your teams, and the DORA 2025 telemetry shows the shape of it: individual output climbs, delivery stays flat. So hire for capability, not headcount: people who can own applications through constant change rather than work a ticket queue. They have to absorb vendor releases they did not choose, hold a tight change process while the ground keeps moving, and handle the failures no runbook covers. And give them the observability and tooling to support a moving estate at pace, so keeping it working does not come down to a few people holding it together by hand.
Push the long tail to the edges
Push the long tail to the edges and govern the centre.
The 40,000 small process gaps on every frontline were never going to be served by a central queue, and now they do not have to be. Frontline people and their agents resolve the long tail where the context already lives, while central support sets the guardrails, curates what is allowed, and governs the whole thing rather than working every ticket itself. This is the same shift I described for governed citizen development, applied to support.
Supervise after you deploy
Supervise agents after you deploy them.
It’s the old, you can’t improve what you can’t see. Putting an agent in front of users is the easy day. The work that matters is designing the escalation paths, the observability for non-deterministic behaviour, the human-in-the-loop checkpoints, and the kill switches. If you cannot see what an agent is doing, it is a risk, not a productivity gain. Gartner expects more than 40 percent of agentic AI projects to be cancelled by 2027 on cost and weak controls, which is exactly what happens when deployment is treated as the finish line. Choosing where to apply agents is itself the highest-leverage decision, and getting it wrong is most of why so many AI programmes return nothing.
Supportability as an architecture input
Treat supportability and patchability as architecture inputs.
What an application even is has changed. It is no longer something you build, freeze, and maintain. It is a moving target that absorbs vendor feature drops, continuous patches, and new integrations every week, and the architecture has to be designed for that rather than surprised by it. That means loose coupling so one forced change does not break three others, observability so you can see what moved, the ability to patch and roll back without a maintenance window, and continuous automated testing so the next release does not catch you out. Supportability and patchability are not features the support team asks for once the system is live. They are requirements on the design, and getting them right is what lets an application keep up with the clock.
The cheapest place to fix a support problem is before it ships.
The clock only gets faster
The annual-upgrade world is not coming back, and the tempo is not going to settle down to something comfortable. It is going to keep rising. The organisations that come through this are not the ones with the best chatbot. They are the ones that stop trying to retool the old support model and instead redesign the three coupled functions, patching, architecture, and support, as a single problem with a single clock.
The foundations you lay in the next year decide whether the next acceleration is something you absorb or something that breaks you. If you want one place to start on Monday, do not start with a tool. Pull a month of your own support data and find where the three clocks already collide: the tickets that are really unpatched-in-time exposure, the ones that are really a vendor changing behaviour without warning, and the ones that are really an agent doing something nobody designed. That collision is your real backlog. Design the new model around relieving it, and let the tooling follow the design rather than lead it.
The way enterprises support their applications was built for a clock that no longer ticks. It has to change as fundamentally as the software it supports already has, and you cannot buy your way out of that with a tool. Rebuilding the function is the work of the next few years, and the clock is not going to wait.
Written by Bradley Hunt. For more on AI-first enterprise architecture, see the writing index.
Read next
Bradley Hunt
AI, engineering & leadership