What early adopters are teaching us about agentic AI in IT

New technologies rarely arrive with an operating manual.

The organizations that move first end up writing it. They discover which problems the technology solves, where it breaks, what controls it needs, and how people’s jobs change around it. The early adopters of cloud computing did this a generation ago. The practices they developed through trial and error eventually became standard operating procedure for everyone else.

I think we’re at a similar moment with agentic AI in IT.

At Fixify, we have a front-row seat to how forward-leaning IT organizations are putting AI agents to work. We recently studied roughly thirteen weeks of production activity from more than 40 companies using agentic AI for real IT requests.

The dataset included 17,929 agentic plans, 147,351 actions inside those plans, and 52,689 skill executions across companies in technology, financial services, healthcare, and other industries.

This is an early-adopter snapshot, not a forecast carved in granite. But it offers some of the clearest evidence yet of what a practical operating model for agentic AI may look like.

Spoiler alert. The lesson isn’t that IT is racing toward full autonomy. 

It’s that a new division of labor is emerging: AI agents carry more of the routine execution, analysts supervise and shape their decisions, and clean operational data determines how reliably the entire system works.

Three findings stood out to me.

1. AI agents handle one in three IT actions – but that number isn’t the story.

During our study, AI agents carried out roughly one-third of the actions performed across the IT teams we examined.

Depending on your expectations, that may sound surprisingly high or surprisingly low. But the percentage alone doesn’t tell you how the work was organized.

The more important detail is that the AI-proposed actions in our study were subject to analyst review. The agent could assemble a plan, recommend an action, communicate with a requester, and carry out approved steps. But the analyst remained responsible for deciding whether proposed actions should run.

That distinction matters.

There are at least four separate parts to agentic work:

1. Planning what should happen.
2. Proposing the next action.
3. Approving or declining that action.
4. Executing the approved step.

An AI agent can take on a meaningful share of this process without removing human control. In fact, that’s what the early operating model appears to look like.

Agents are carrying more of the repeatable volume. Analysts are governing the system.

The balance also depends on the work involved. AI agents performed the largest share of actions in software and application requests, security tasks, and collaboration work. Analysts remained more involved in onboarding, offboarding, identity lifecycle, and hardware, where mistakes tend to be harder to reverse.

That’s an important clue for IT leaders deciding where to start. The best early candidates aren’t simply the tasks with the highest volume. They’re the tasks where the venn diagram overlap of “well understood” and “lower risk” is the largest.

For example, one recent customer wanted to automate a high-volume class of tickets from end to end. But when we looked more closely, we found that the IT team was routing many of those tickets to another team with the access needed to complete the work.

The better solution wasn’t full automation. It was to automate the initial triage. The agent asked the right questions up front, then routed each ticket to the appropriate team with the information they needed to act immediately.

The result was faster resolution and less strain on both teams. We didn’t need a world-ending hive mind. We just needed to point a little conversational intelligence in the right direction.

All that is to say that the question we should be asking isn’t just, “How much is the AI doing?” It’s “Which decisions still belong to people, and how well is that approval loop designed?”

A strong agentic system should make proposed actions easy to understand, give analysts enough context to make a real decision, and apply tighter guardrails when the consequences of a mistake are higher.

That supervision layer isn’t a temporary set of training wheels. It is part of the operating model.

2. The “no” that improves the system

The organizations we studied used a human-in-the-loop component that enabled review of some or all of the tickets that were slated for automation. This gave us a clear view of where an AI agent’s recommendation diverged from human judgment. This happened in about 23% of the actions proposed.

In other words, roughly one time in four, an agent said, “Here’s what I recommend,” and a human decided it was not the right action.

At first glance, a rejection may look like a failure of automation. In practice, it’s one of the most valuable signals the system produces.

An approval tells the system that its proposed action aligned with the team’s policies and judgment. A decline tells it that something was wrong: perhaps the target, the timing, the procedure, the risk level, or the interpretation of the request.

If the system is designed properly, that’s exactly the feedback that can be used to improve the system’s future plans, playbooks, policies and proposals. Supervision is therefore doing two jobs at once. It’s controlling risk today and helping the automation become more useful tomorrow.

Over the study window, the rejection rate fell from approximately 27% to 16%.

That isn’t just the result of model improvements, although there were some. It was also influenced by configuration changes, accretion of more advanced context, and changes in the mix of work. 

The plans themselves also changed. The median agentic plan shrank from 18 actions to 13, while the proportion of conditional actions fell from 48% to 25%. At the same time, the share of performed actions executed by AI rose from 23% to 41%.

All of this is to say the system was becoming less hedged and more useful.

This suggests a better way to evaluate agentic AI. Raw automation volume isn’t enough. A team could automate more while producing poor recommendations, creating risky outcomes, or encouraging analysts to rubber-stamp decisions.

A healthier set of signals includes:

• How often analysts approve or decline proposals.
• Why they decline them.
• Whether similar proposals improve over time.
• How complex the proposed actions are.
• Whether execution succeeds after approval.
• Whether analysts later reverse or override the outcome.

A zero-rejection rate isn’t the goal. That could mean the system has become extraordinarily accurate. It could also mean analysts are no longer reviewing proposals carefully or that the system has been restricted to only the safest, simplest tasks.

What matters is the capability to learn, and the pattern of learning that shows up in the metrics.

Are the agents learning the team’s operating boundaries? Are analysts still exercising meaningful judgment? Are the declines revealing specific opportunities to improve the automation?

A rejection is part of the feedback loop that makes supervised automation work.

3. Most automation failures begin upstream of the AI

When an automated action fails, the instinct is often to look at the model.

Maybe it misunderstood the request. Maybe its reasoning was flawed. Maybe the vendor needs a better model or another product update.

Our data points to a more ordinary culprit.

Across all skill executions, approximately 9.6% failed. The largest failure category, representing 48.5% of failures, was “target not found.” The user, account, group, or other resource the agent was trying to act on was not where the connected system expected it to be.

Another 29.3% of failures came from invalid input.

Together, these categories accounted for more than three-quarters of failed executions. In many cases, the automation was operating from an incomplete or outdated picture of the environment.

Someone had changed teams. An account had been renamed. A group had been restructured. A user had already been deprovisioned. A directory or integration had not caught up with the change.

The agent went to act, and reality had moved.

Not every “target not found” result represents a serious problem. Sometimes it means the work was already completed and there was nothing left to change. But the broader pattern is clear: automation reliability depends heavily on the quality of the systems and data surrounding the AI.

That is particularly important because identity and access management is the leading frontier for agentic execution.

Only about 6% of the skills in our study made changes to connected systems, but most of those consequential changes involved identity and access. They included adding or removing group memberships, resetting credentials, provisioning accounts, and assigning application licenses.

We’re also seeing that identity infrastructure is becoming automation infrastructure. Approximately 84% of these identity and access changes ran through identity management systems like Okta, with most of the remainder running through Google Workspace, Microsoft 365, and Slack.

Two lessons matter here. And they’re both equally important.

• First, when you evaluate agentic AI, look closely at how it handles failure. If a user, account, or group isn’t where the agent expects it to be, what happens next? IT’s last mile is bumpy, so the AI needs more than a good first guess. It needs the ability to recover, replan, and keep moving.
• Second, IT teams already control many of the conditions that make AI effective. Strong information governance, clean directories, consistent naming, and well-maintained integrations can prevent a great deal of wasted time debugging failures that look like AI problems but are really data problems.

The early-adopter playbook is coming into focus

Taken together, these findings point toward an emerging model for agentic AI in IT.

It’s not a model in which an autonomous agent takes over the help desk and people disappear from the process.

It’s supervised autonomy.

The agent plans, proposes, communicates, waits, branches, executes approved steps, and replans when reality changes. The analyst governs the system: reviewing important actions, handling exceptions, correcting course, and improving the procedures the agent follows.

The organizations making progress are also building the foundations around the technology. They’re documenting repeatable work, maintaining reliable integrations, cleaning identity data, creating clear escalation paths, and deciding which actions deserve tighter guardrails.

That’s the playbook early adopters appear to be writing:

• Start with repeatable and reversible work.
• Treat supervision as both governance and feedback.
• Use approval patterns to decide where the system is ready to expand.
• Route unusual or repeatedly replanned work to people.
• Invest in the operational data and integrations the agents depend on.

The long-term story of agentic AI may eventually be about autonomy. But the more immediate story is about coordination: dividing work intelligently between agents and analysts, then improving that relationship over time.

That may sound less dramatic than replacing the help desk.

It’s also a much more credible path to changing how IT work gets done.

The full report includes the underlying data, methodology, interactive charts, and additional findings on agentic planning, reliability, identity automation, replanning, and the evolution of the IT analyst role. It is available at fixify.com/agentic-report.

We’ll also host a live discussion of the findings on Thursday, August 27 at 1pm ET, including what the data suggests IT leaders should automate first, and which signals indicate that an agentic system is ready to take on more. Register here.