How agentic AI
is changing IT
.avif)
Early days: The state of agentic AI in IT — and where it’s headed
Automation with agentic AI is reshaping the world of IT in profound ways. To understand the changes, Fixify dug into the data. We found that a new division of labor is emerging among early IT automation adopters: AI agents are handling more and more of the routine execution of IT tasks, while analysts are supervising, approving, rejecting, redirecting, and taking over when requests require judgment. AI is emerging, not as an autonomous replacement for IT work, but as a structured coordination and execution layer for getting work done.
Our findings are based on 17,929 agentic plans (the plans an AI agent produces for a request), 147,351 plan actions (the individual steps inside a plan), and 52,689 skill executions (the discrete actions an agent carries out) from March through June 2026. The data comes from more than 40 companies ranging in size from fewer than 100 employees to more than 2,000 across a range of industries including technology, financial services, and healthcare. All of these organizations are early adopters of agentic AI for IT, so their experience gives us signals, but we know there’s a lot of change still ahead. What we can see most clearly now is where the shifts are happening quickly, when agentic AI works and when it breaks, and how the role of IT analysts is evolving — and why it will remain critical.
These data points offer a glimpse at some of the most interesting findings from our research. We’ll analyze them more deeply throughout this report.
.avif)
Six key takeaways
AI agents are taking on a meaningful share of routine IT execution.
During our four-month study, AI agents performed roughly one-third of executed actions, all under analyst supervision. AI agents’ involvement was highest in software, applications, security, and collaboration work, where requests tend to be repeatable and easy to reverse. Analysts remained closely involved, especially in higher-stakes areas such as identity lifecycle, onboarding, offboarding, and hardware.
Human supervision is central to automation with agentic AI.
Analysts reviewed AI-proposed actions and declined about one quarter of them across the full window. The rejection rate fell substantially over the four-month period, suggesting that the feedback loop is improving agent performance. Each approval or rejection teaches the system what the IT team considers acceptable, turning supervision into AI training in addition to oversight.
Identity and access management is the frontier for automation.
IT analysts’ most common use of AI agents is to change access, from group membership changes to credential resets, account provisioning, license assignment, and other identity lifecycle tasks. Much of this work runs through identity providers, especially Okta, making identity systems a key site for agentic IT automation.
Automation failures are often data problems, not AI reasoning problems.
While identity and access are the most common targets when AI automation changes a system, they’re also where failures are most common. The largest failure category is “target not found,” meaning the user, group, account, or resource the agent tried to act on was not where the system expected it to be. To address this problem, IT analysts can focus on identity hygiene. Clean directories, consistent naming, timely deprovisioning, and well-maintained integrations can improve outcomes more than model tuning alone.
The IT analyst role is shifting toward judgment, exception handling, and system improvement.
As agents take on more repetitive tasks, analysts spend more time reviewing proposals, correcting course, handling unusual cases, and improving the automation itself. The hardest requests remain human-heavy, especially those that require repeated replanning or contextual judgment. The human IT analyst role isn’t disappearing; it is moving up the stack.
The practical path forward is supervised autonomy for AI agents — with lots of human oversight.
In this model, agents carry routine volume while humans remain responsible for important approvals and exceptions. With this in mind, IT teams should invest in strong review workflows, clean identity data, documented playbooks, reliable integrations, and clear escalation paths. These foundations make agentic automation more reliable and easier to expand.
Here’s the big picture: Our research shows that agentic AI is becoming a new operating layer for IT. It plans, proposes, communicates, waits, branches, executes, and replans. But the analyst remains the governor of the system. It’s a human-supervised model where AI agents handle repeatable work while people focus on the decisions that matter most.
Let’s take a deeper look at some of the key findings and what they may mean for the future. For the most curious among us, we’ve also included a methodology note and a glossary.
How humans and AI agents share IT work
Among the early adopters of AI that we studied, analysts are no longer carrying every request step-by-step. They’re assigning work to AI agents, reviewing what those agents propose, and stepping in when the work requires judgment. The result is not hands-off automation, it’s a new division of labor.
Across 13 weeks of production data, we saw where that shift was happening and what the human-AI relationship looks like in practice.
Where AI agents take on the largest share of execution
AI agents handle a substantial share of the execution when work is repeatable, structured, lower risk, and easiest to reverse, including software and application requests, security tasks, and collaboration changes. But even in these categories, agents still handle well under half of the actions.
Meanwhile, the work that stays mostly in people’s hands is onboarding and offboarding (23% AI-executed), IAM (29%), and hardware (27%). These involve identity-lifecycle and physical work where a wrong action is hardest to undo.
Where AI agents do the most work
Supervising AI agents
Here’s one big change on the horizon for IT analysts: supervising AI agents will become a big part of the job. When an agent proposes an action, an analyst reviews the proposal and decides whether it runs. Across our dataset, analysts approved most proposals and declined about 23% of them.
Staying in the approval loop lets IT analysts accomplish two important things. First, it keeps the most consequential changes under human control. For example, you probably don’t want AI automatically resetting the CEO’s password. Second, the IT analyst approvals help train AI agents: each approval or rejection teaches the model which actions fit a given situation, so the agents get better at proposing actions a supervising analyst will accept. Our data shows the impact of that learning curve. Over four months, the rejection rate declined from 27% to 16%.
Analysts decline fewer proposals as the agents learn
There are two main factors that matter for a good analyst-agentic AI relationship: how good an agent’s proposals are, and how quickly an analyst can approve or decline them. To improve the process, make the review surface easy to understand so analysts can assess proposed actions and make quick decisions about how to proceed.
Companies that are getting the most utility from AI agents in IT are letting AI agents do more of the routine access work and less of the identity-lifecycle and hardware work. You can reinforce that pattern: put guardrails in place where a mistake is costly and let AI agents carry the routine volume.
A roughly one-in-four rejection rate indicates that AI agents are getting healthy supervision. Every decline teaches agents what your team would not approve. To get the most from this process, review what gets declined and why — this improves the models and shows you where it’s safe to expand next.
Next: Section 2 opens up the agentic plan itself — we looked at what’s inside these plans and how the structure makes AI agents more reliable.
How humans and AI agents share IT work
Every IT team knows the difference between a one-off fix and a runbook. A fix solves the issue in front of you. A runbook lays out the steps, decision points, handoffs, and fallback paths that make the work repeatable. Agentic plans work the same way. They map what should happen first, what depends on the result, when to ask for approval, and what to try next if the original path does not work. When reality diverges from the plan, the agent replans.
Normally you only ever see a plan in the moment, for the one task or project you’re working on at the time. We took a wider view. We looked across tens of thousands of agentic plans built for real IT automation work to see what they’re actually made of. What’s inside – and how the plans evolve over time – is more revealing than any single plan lets on.
Here’s the short version: most of the early agentic IT automation plans weren’t system commands. They were scaffolding — the branches, messages, and hand-offs wrapped around a small core of actions that actually change something. And that structure is one reason agentic automation can be more reliable than fixing things with one-off skill executions.
What does an AI agent’s plan really look like?
Open up the work an agent does on a request and you’ll find six kinds of actions. Only one of them — running a skill — actually changes a system. (You can think of a skill as a discrete action the agent can carry out in a connected tool, such as resetting a user’s multi-factor authentication in Okta, adding someone to a Google group, assigning a software license, or unlocking an account.) The other five action types allow the agent to coordinate that work: messaging the requester, leaving notes for the team, instructing an analyst, waiting, and occasionally running a packaged workflow.
What an agentic IT automation plan is made of
Running a skill accounts for about 39% of all actions. The rest is communication (41%, split between messages to the requester and internal notes), analyst hand-offs (10%), waiting (9%), and workflows (1%). The system-touching work is the minority; most of an agentic plan is the coordination and communication around it.
An agentic plan maps many paths — but only one runs
Like all of us, when an AI agent builds a plan it doesn’t know what it doesn’t know. To navigate the unknown, AI agents build in far more scenarios than they execute. A typical plan lays out 15 possible actions but runs only 2 — because most of those actions are conditional branches for situations that might arise. 72% of plans include at least one branch, and 40% of all blueprinted actions are conditional.
A plan maps many paths; but most don’t run
The gap between possible scenarios and executed ones is a key strength for automation with AI. The agent maps the paths a request could take, then walks down the path that makes the most sense as it meets reality. Most of the plan stays unused on any given run, just as the untaken branches of a decision tree go unused.
Skills that run inside structured plans succeed more often
Structuring work into plans pays off in reliability. In our dataset, skills that ran inside an agentic plan succeeded 93.7% of the time; skills that ran as one-off, ad-hoc actions succeeded 87.5% of the time.
Structured plans are more reliable than ad-hoc fixes
Note that the success of agentic plans versus one-off approaches is impacted by the types of problems handled by each. Structured agentic automation plans are usually tackling simpler problems, while harder or more novel work is more likely to be handled with one-off skill executions. Even so, the difference in success rates is consistent, and it holds across the window.
Over the four months of data, the gap between agentic and ad-hoc reliability grew — but not because the agents pulled ahead. Agentic reliability held steady, between 93% and 95% every month. What moved was the ad-hoc rate, which fell and got choppier as structured automation absorbed the easy, repeatable work and left the harder, less predictable tasks to be handled ad hoc. The widening gap is mostly a story about what’s in each bucket.
When you evaluate agentic tools, ask whether the system works from a structured plan — with branches, communication, and hand-off points — or just fires individual actions. The structure is much of what makes the work reliable and reviewable.
A plan that blueprints 15 actions and runs two is working as designed — the unused paths show there were contingencies for things that didn’t happen, but could have. Judge plans by their outcomes, not by how much of the plan actually happened.
Skills that run inside a plan succeed more often than ad-hoc one-offs (93.7% versus 87.5%). Send repeatable, high-volume work through structured plans where you can, and keep ad-hoc execution for genuine exceptions.
Next: Section 3 narrows in on places where agentic AI actually changes a system — especially identity and access requests that dominate agentic execution. We look at where this succeeds, and where it most often breaks down.
The identity and access frontier for AI automation in IT
Most of what an IT automation agent does is look things up and move tickets along. Only a small share of the skills it runs actually change a system — about 6%. Most of that 6% happens in identity and access management, including adding people to groups, resetting credentials, and opening and closing accounts. This is where agentic automation does its most consequential work. It’s also where it most often breaks down.
What are AI agents up to in identity and access?
In our study, there were a few key areas in identity and access management where AI agents were most productive. Group and channel membership is by far the largest piece — about 77% of all changes — followed by credential resets like MFA and passwords (15%) and account lifecycle work (9%). And these changes succeed far more often inside a structured plan (84% success rate) than when run as one-off skills (71% success rate) (see Section 2 for details about agentic AI automation plans and why they work).
They’re also highly concentrated. About 84% of all changes in our data ran through Okta, the identity provider, with most of the remainder in Google Workspace.
Where agentic automation makes changes
When we look at these changes by type, most fall into three categories. Group and channel membership is the bulk of the work — adding and removing people from the groups and channels that grant access. Credential resets come next: MFA resets, password resets, and account unlocks. Account and app lifecycle, including provisioning and deprovisioning accounts and assigning application licenses, makes up the remainder.
What gets changed, by family
Where AI automation breaks down
Across all skills, about 1 in 10 executions in our data failed (9.6%). The failure rates were highest in identity-lifecycle work — onboarding and offboarding (18.5%) and IAM (13.5%).
Where automation breaks down most
Hardware and connectivity changes rarely fail; identity-lifecycle changes fail three-to-nine times as often. The pattern isn’t random. It reflects issues with data AI agents depend on.
Why AI automation fails: the target isn’t there
The most common reason for a skill failure is relatively simple. The thing an AI agent is trying to act on — the user, group, or account — isn’t where the agent expects it. Target-not-found accounts for 48.5% of all failures.
Why automation fails: the target isn’t there
When we also take the second most common failure, input that doesn’t match what the system expects (29%), into account, we can see that roughly three-quarters of all failures come down to one challenge. The agent’s picture of identity doesn’t match reality. People change teams, accounts get renamed, groups get restructured, and the directory the agent reads lags behind. This is an identity-hygiene problem more than an AI problem: the cleaner and more current the identity data, the fewer of these failures occur.
A target-not-found may not indicate a problem at all. Instead, it may mean that the work was already done — the account was already disabled, the membership already changed — so there was nothing left to act on. Most often, the failures that signal real breakage are the smaller categories such as configuration and connection errors, where the integration itself is broken. Those are a small share of failures, but they’re the ones worth alerting on. Counting every failure the same way, overstates how often automation actually goes wrong.
The single biggest source of automation failure is stale or mismatched identity data — the target record isn’t where the agent expects. Ensuring clean directories, timely deprovisioning, and consistent naming does more for reliability than tuning the AI.
The most consequential changes AI agents make tend to run through identity providers — about 84% in Okta in this dataset. Focus on a solid, well-permissioned identity-provider integration since this covers most of the system-touching work; long-tail app integrations matter far less.
Many not-found failures simply indicate that the work was already done. The failures that signal real breakage are the smaller configuration and connection errors. Route those to a human. Don’t drown the team in the rest.
Next: Section 4 looks at the trajectory of automation with agentic AI — how agentic plans, and the balance between scaffolding and execution, are changing month-over-month as the technology matures.
How agentic plans evolve
Early agentic automation plans have a tell: they’ve over-planned. When a system first takes on a task, it writes long, elaborate plans full of "if this, then that" branches that hedge against every contingency it can imagine. Over 13 weeks of data, we watched two things happen with these kinds of plans: they got shorter and less hedged, and the AI carried out a steadily larger share of them.
Two things move at once
Conventional wisdom says automation creates complexity: more rules, more edge cases, more scaffolding over time. But our data showed the opposite. Over time, agentic plans got leaner, and the AI was allowed to execute more of them. The chart below puts both trajectories side by side.
How agentic plans evolve
Agentic plans get leaner — for the same work
Plans created later in our study’s window were measurably simpler. The median plan went from 18 actions to 13, and the share of actions that were conditional — the “if/then” branches a plan builds in to hedge — fell from 48% to 25%, with the sharpest drop at the end of the window. Over time, we saw fewer steps and far less branching.
The obvious question is whether the mix of work simply changed — maybe later weeks just had easier requests. This wasn’t the case. The decline holds within the same use cases (login troubleshooting, app assignment, and the rest) and when we hold the overall work mix fixed. Plans aren’t getting simpler because the work gets easier. They’re getting simpler because the agent is improving.
Over time, the AI was trusted with more of its plan
At the same time, the division of labor shifted. Of the actions actually carried out, the share AI executed climbed from 23% to 41%. In parallel, the rate at which analysts rejected an AI-proposed action fell from 27% to 16%. The system was handed more, and humans second-guessed it less.
Why do agentic plans get leaner over time?
Leaner plans are exactly what you’d expect as the underlying technology matures. Early on, an agentic planner isn’t sure which procedure will work, so it applies hedges. It writes branches for cases that may never occur. As the system grounds more reliably in an organization’s real procedures, pulls in more context about the environment it’s working in, and gets better at judging when to run a known step rather than plan around it, that hedging falls away. The plan converges on what the task actually requires.
We observed this trajectory across the time of our study. The whole population of plans got leaner over 13 weeks as the technology improved. Since our window was short, we read it as a strong early signal rather than a settled law.
As agentic plans got leaner, they replanned more. That’s a sign of sophistication. Early plans hedged up front, scripting branches for cases that might never occur: nearly half of all actions (48%) were conditional. Later plans carried far less of that scaffolding (25%) and instead replanned dynamically when reality diverged — replans per plan rose from about 0.34 to 0.57 across the window. This isn’t constant churn: roughly 7 in 10 plans still never replan at all, so replanning is reserved for when conditions actually change. Adapting in the moment is a more advanced behavior than trying to pre-script every contingency — the system trades rigid up-front branching for judgment as it goes.
When you first turn on agentic automation, plans may look elaborate and heavily branched. If so, that’s the system hedging, not proof it’s handling complexity well. Judge it on outcomes and expect the plans to tighten as the system learns your environment.
The clearest sign an agentic system is maturing isn’t how much it does, it’s how often its proposals survive human review. A falling rejection rate means the AI’s judgment is converging with your team’s. That is a better readiness signal than raw automation count.
Leaner agentic plans rely on re-planning when reality shifts. Build workflows where these mid-flight replans and hand-offs are routine and low-friction to accommodate your maturing system.
Next: Section 5 turns from how agentic automation is changing, to what it means for the people doing the work — how the division of labor between analysts and AI is likely to shift.
The evolution of the IT analyst role
Our study data suggests that automation with agentic AI is not removing the analyst from IT work. But it is changing where analyst judgment is concentrated.
As agents take on more of the repeatable execution, the analyst’s job is shifting toward supervising the work: reviewing proposals, deciding when a recommended action is safe, stepping in when context matters, and improving the procedures the agents follow.
Earlier sections show the mechanics of that shift. AI agents carried out a larger share of performed actions over the window, analysts rejected fewer proposals, plans grew leaner, and replanning allowed maturing systems to adapt. This section looks at how our findings impact the people doing IT work.
The analyst becomes the governor of the system
Before agentic automation, much of IT work was step-by-step execution: look up the requester, check the policy, find the right group or app, make the change, update the ticket, message the requester. Agentic automation changes that sequence. The agent can assemble the plan, propose the next action, communicate along the way, and carry out routine steps after approval.
In this model, the IT analyst takes an active role in controlling how the IT agent behaves. The analyst decides whether the agent has the right target, whether the request fits policy, whether the proposed action is reversible, and whether the situation has moved outside the pattern. These approve-and-decline decisions help get tickets closed and they provide a signal that teaches the system how to handle the same situation next time.
The result is a role shift: less time spent repeating known steps, more time spent reviewing proposed actions, handling exceptions, and improving the workflows agents rely on. Routine execution moves toward the agent. Judgment, escalation, and system improvement stay with people.
Humans handle the unexpected
The requests that need the most analyst attention aren’t necessarily the least automated ones. They’re the requests where reality keeps diverging from the plan.
Section 4 showed that as agentic AI’s plans got leaner, replanning rose: replans per plan increased from about 0.34 to 0.57 over the window, while roughly 7 in 10 plans never replanned at all. That combination matters. Replanning isn’t constant churn. Most plans still run without it. But when a request keeps forcing course-corrections, it’s a useful signal that the work may require human judgment.
For IT teams, that makes replanning an operational marker. A single replan can indicate healthy adaptation. Repeated replanning can mean a request was ambiguous, the underlying data is stale, the policy is unclear, or the situation simply does not fit the standard path. This is where the analyst’s attention belongs.
Scale matters more than staffing pressure
There was one pattern we expected to find, but didn’t. When we looked at the number of end users per IT staff member, the most stretched IT teams weren’t necessarily the most automated.
What we found instead was a relationship between organizational size and AI automation. Larger organizations automated a higher share of their performed actions. Grouping organizations into three batches by employee count, the median AI-executed share was 26.4% in the smallest third and 41.9% in the largest. The mean moved in the same direction, from 27.3% to 37.5%.
Scale, not staffing pressure, tracks with automation
While we found this relationship between the size of an organization and its level of automation notable, there were exceptions. The largest organization in our dataset automated less than the overall size trend would predict. But the direction is consistent, and the explanation is likely more about operating maturity than staffing pressure.
Larger organizations tend to have an ideal foundation for AI automation. They have more request volume for agents to learn from, more documented processes for agents to follow, and more resources to invest in integration, configuration, and tuning. Automation maturity appears to grow less from being understaffed and more from having the foundations that let agents operate effectively at scale.
Build analyst time, queues, and metrics around reviewing proposals, escalating risky requests, and improving agent behavior. Treat that judgment as core work, not overhead around the “real” ticket work.
Requests that keep changing course are likely to need context, policy judgment, or manual investigation. Notice repeated replans and route them to people before they stall.
In these early days, the organizations automating the most have scale and operating maturity on their side: volume, documented playbooks, clean integrations, and time to tune. Invest there rather than expecting a thinly staffed team to automate its way out of structural gaps.
The methodology and glossary that follow document how we derived our findings and how we’re using our terms.
Every chart in this report is backed by a data table, shown in the “View data” panel beneath it. The charts and their tables, in order of appearance:
Three further data tables appear in sidebars: agentic versus ad-hoc reliability by month (Section 2), the signature-stat summary (Section 4), and conditional actions versus replans by month (Section 4).
Every figure in this report comes from what the agents and analysts actually did on real requests: the plans generated, the actions inside them, and the outcomes. None of the data relied on surveys or self-reports.
This report draws on production data from more than 40 companies across several industries, including technology, financial services, and healthcare — all are early adopters of agentic AI for IT automation. These companies range in size from fewer than 100 employees to more than 2,000. We collected the data over roughly 13 weeks, from mid-March to mid-June 2026. March and June are partial months. Wherever a monthly figure could be skewed because of a partial-month, we’ve marked it with an asterisk (*).
- 17,929 agentic plans —the structured plans agents produced for real requests.
- 147,351 plan actions —the individual steps inside those plans.
- 52,689 skill executions —actions that ran a skill against a system, inside plans and as one-off runs.
- 88,493 performed actions —actions carried out by an analyst or by AI after approval.
- 37,362 AI-proposed actions —actions an agent proposed that an analyst then approved or declined.
- 5,036 failed skill executions —used for the failure analysis.
- 3,147 identity and access changes — the change-work subset.
We categorized organizations by firmographic attributes (industry, employee count, IT-staffing ratios) to see how patterns vary.
Work was grouped into categories and into work types (routing, reading, change) by classifying the underlying skill action. A small catch-all "other" category was excluded from category charts and noted where relevant.
- This is a short, early window into how automation with AI agents is impacting IT teams. Thirteen weeks gave us a view into the direction these teams were headed, but not settled trends.
- Trajectories we noted describe the technology in general, but don’t necessarily reflect every adopter.
- We treated course-corrections and slow resolutions as markers with a likely common driver, not as proven causes.
- This is an early-adopter snapshot, so it doesn’t reflect what’s happening with the average IT team today.
A note on why we did this, and a glossary of the terms used throughout the report, follow.
.svg)
You've seen where AI takes the work across early adopters. Find out where it could take yours. Free customized report from 90 days of your ticket data.
A closer look at the terms we’ve used
Ad-hoc (one-off) execution
Running a skill directly, outside a structured agentic plan. Contrast with an agentic plan.
Agentic AI
A type of semi or fully autonomous AI system that can reason and act on its own or with human supervision. Agentic AI can integrate with other software systems.
Agentic plan
The structured plan an AI agent produces for a request: an ordered set of actions, the conditional branches between them, and the points where the agent communicates or hands off to a person. Most of a plan is this scaffolding rather than system commands.
AI-executed
An action the AI agent carried out automatically or after an analyst approved it.
Analyst-performed action
An action a human analyst carried out directly.
Category
The kind of IT work a request involves: IAM (identity & access), software & applications, onboarding & offboarding, hardware, connectivity, security, or collaboration.
Change-work
Skill executions that write a change to a connected system such as adding someone to a group, resetting a credential, provisioning or deprovisioning an account — as opposed to reading information or routing a ticket.
Conditional action (branch)
An action that only runs if a condition is met: the "if this, then that" paths a plan builds in to handle situations that might arise.
Execution mode
Whether a skill ran inside a structured agentic plan or as a one-off, ad-hoc action.
Identity provider
The system that manages who can access what (for example, Okta or Google Workspace). Most change-work runs through identity providers.
Performed action
An action actually carried out — by an analyst, or by AI after approval — as opposed to one that was only blueprinted or was cancelled because its branch wasn't taken.
Plan action
A single step inside a plan. Six types appear: run a skill, send a message, leave an internal comment, instruct an analyst, wait, or run a workflow. Only running a skill changes a system.
Proposed action (AI-proposed)
An action the agent proposed for a human to approve or decline.
Rejection (decline) rate
Of the actions an agent proposed, the share an analyst declined. A falling rate signals that the agent's proposals increasingly match what the team would approve.
Replan
When an agent revises its plan mid-flight because reality diverged from what it expected. Leaner plans replan more, adapting in the moment rather than pre-scripting every branch; most plans never replan.
Skill
A single piece of automation: one discrete action the agent can carry out in a connected tool, such as resetting multi-factor authentication in Okta, adding a user to a Google group, assigning a software license, or unlocking an account.
Success / failure / timeout
The outcome of a skill execution: it returned success, returned a failure, or timed out.
Target not found
A failure in which the user, group, or account an action refers to can't be located — usually because identity data changed faster than the directory the agent reads. The most common failure reason.
Use case
The specific task type behind a request (for example, login troubleshooting or application assignment); a finer grouping than category.