The true promise of agentic AI lies in agents maneuvering, making decisions, and taking actions autonomously throughout the enterprise, but few IT leaders appear ready to give bots widespread control.

According to a KPMG survey from July and August, 62% of IT leaders reported they were building, deploying, or developing AI agents, up from 53% in the previous quarter. But many IT leaders still say they are uncomfortable with the prospect of turning over internal processes to agents, with some exceptions for basic, low-risk functions like tier 1 IT support.

Jim Olsen, CTO of AI lifecycle management and governance vendor ModelOp, sees agent autonomy making inroads in limited circumstances — for example, to process customer refunds or credits without human intervention. But early lessons in the risks of full autonomy remain top of mind for IT leaders.

“We saw the large adoption of Clawdbot and OpenClaw by individuals where they would allow it full access to their email and gave it full autonomy,” he says. “For some people that worked out well, but it was a large risk exposure.”

For IT leaders deploying autonomous bots, Olsen recommends confining them to a strict sandbox with well-defined policies to limit their autonomy.

“I do not see allowing agents full and complete autonomy to do whatever they want being used in an enterprise in the near future,” he says. “But restricted autonomy is, in fact, already in use today.”

Activities that aren’t mission critical and don’t have access to sensitive information will be where IT leaders first grant agents full autonomy, Olsen predicts. “As trust improves, so will the breadth of use cases,” he adds.

Some IT leaders are concerned about “autonomy creep,” when agents quietly take more authority than they are given. And many AI and security experts warn that human-in-the-loop guardrails don’t always give employees the authority or time needed to fix agent errors.

Still, IT leaders have several methods for enforcing runtime policies and keeping agent behavior within acceptable goals, including API gateways, OS-level enforcement, and credential management, Olsen says.

“This means having clear policies in place and being able to tie them to the specific agent and use case,” he adds. “Some of these solutions are available now, but a more overall cohesive strategy is needed to bring about this minimal level of trust.”

Defining the sweet spot for autonomy

With about 2,000 agents deployed within her enterprise, Siroui Mushegian, CIO of cybersecurity vendor Barracuda Networks, still has human employees checking bot actions.

“We have many agents that are very close [to autonomous] — many of our ticketing automations are in the ‘trust-but-verify’ category with the agents that oversee them,” she says. “The more we see success, the greater comfort we have, but I am still not 100% certain I want to allow zero human accountability, especially when it comes to auditable processes.”

Mushegian expects autonomy to expand as agents demonstrate they can handle specific tasks reliably. “The consequences of a mistake should determine how much evidence you need before giving an agent more authority,” she says.

Autonomy will likely come to agents executing specific tasks within a function, she adds. Routine internal support requests are a reasonable candidate for autonomy when the answer is well documented, the action is limited, and a mistake is straightforward to correct, she suggests.

Less likely candidates for autonomy are agents that can change access permissions or make changes to a production system, Mushegian adds.

“Even within one workflow, an agent might complete some steps on its own and need approval for others,” she says. “I’d give it only the authority it needs for the task, with human approval for decisions where a mistake could have serious consequences.”

It’s about the action, not the agent

Joshua Rowe, co-founder and CTO of household bills app provider Taupia, agrees that IT leaders shouldn’t give agents complete freedom in every circumstance.

“I’d draw the line at the action rather than the agent,” he says. “The same agent can act alone on one step and need sign-off on the next.”

However, Rowe sees a lot of areas where agents can run near-autonomously right now, including read-heavy work such as gathering data, triage, drafting, and comparing options.

Taupia is testing agent functionality that compares energy deals and takes steps to allow customers to switch providers without its employees approving each step. However, the customer still would have to review the change and confirm it before it goes into effect.

For agents to get autonomous authority for irreversible actions, the timeframe doesn’t depend on AI models getting smarter, Rowe says.

“It depends on how quickly an organization can make each action reversible or bounded, with spending limits, cooling-off periods, rollback, and an audit trail good enough to undo a mistake,” he says. “Once an action has those, it can go autonomous. Where it can’t be undone, like signing a contract or moving money out of an account, I’d keep a person approving it for the foreseeable future.”

A question of deliberate design

Maciej Walaszczyk, CTO at AI customer service platform provider Text, points to customer service as an area where IT leaders have begun to cede control to agents.

“In customer service, which is my field of expertise, agents can indeed answer customer inquiries without the need for constant supervision, as they learn from knowledge provided by humans,” he says. “The scope of autonomy depends on permissions and the consequences of an action. Furthermore, the scope of these responses can be tailored to specific needs.”

But Walaszczyk says he would not hand entire departments over to agents. Instead, IT leaders should delegate specific processes where they can define the goal, set boundaries, and verify the outcomes, he recommends.

“An agent acting on my behalf cannot have more authority than I do,” he adds. “I don’t think it’s a question of being comfortable or even courageous, but of deliberately designing the environment, permissions, instructions, and oversight.”

Trust will come from real work and verified results, and humans must remain in the loop to check agent outcomes in many cases, Walaszczyk adds.

“Oversight must be real,” he says. “It takes time and attention, and it means much more than clicking approve. Saying ‘AI did it’ does not remove their responsibility. Irreversible actions or those with major consequences require human review.”

For decades, CIOs have been challenging their organizations to shed one of the most persistent labels in our profession: order taker. Instead of waiting for the business to tell them what they want, technology leaders need to understand what the business is trying to accomplish, get invited into the first meeting, and earn the right to become a strategic partner. But in a fast-moving environment, is being a trusted advisor enough?

To reach the next level, top CIOs are increasingly transforming their IT organizations into what I call “innovative anticipators”: These IT orgs understand the business, customer, and possibilities so deeply that they can see around corners, anticipate what’s needed next, and create value before someone asks for it.

Janet Robertson, global CIO of RS Group, believes building that anticipation muscle isn’t simply about moving the IT organization to a higher level of maturity. Increasingly, it’s a business imperative.

For a recent episode of the Tech Whisperers podcast, Robertson and I explored the deeply human side of leadership: how trust goes both ways, how great leaders serve as a lighthouse when others are navigating through the fog, and how we prepare the next generation to lead in a world none of us has led in before. But hiding inside that conversation was another fascinating story to unpack.

RS Group is a global product and service solutions provider for industrial customers operating in 33 markets. Its journey has been remarkably similar to the one our IT profession has been making — from taking orders, to advising customers, to anticipating what they might need next. As Robertson evolves IT at RS into an innovative anticipator, the company as a whole is doing the same.

Two journeys, similar challenges. And as Robertson explains in the following conversation, strategic partnership may no longer be the destination for today’s CIO. It may be the starting point for what comes next.

Dan Roberts: You’ve said something that sounds simple but has enormous implications: There isn’t a technology strategy and a business strategy. There’s one business strategy. What changes in the way a technology organization operates when people genuinely believe that?

Janet Robertson: When the technology group is focused on an outcome, they’re looking at solving a business problem more than implementing a technical solution. That’s a nuance, but it’s really the most direct route to a solution, because they’re trying to solve a business problem and get a business outcome more than implementing a technology solution or a technology transformation. It’s a different mindset.

In practical terms, you end up with increased adoption because you’ve got buy-in from the business on the direct answer to the problem. You also end up with fewer bells and whistles — a solution that’s not gold-plated and that doesn’t have things you won’t need, which is more efficient, considering how fast things are moving today. Everything could be different.

In fact, we’re doing product development now as more of a continuous evolution using new, innovative tools that are available to us at each space. The days of planning a three- or four-year program are over. By the time you’re going live, the technology’s out of date, or the processes have changed, or the world’s changed around it. You’ve got to create solutions fast with the most direct available technology to support the business outcomes.

You can’t anticipate a business you only understand through dashboards. How do you get your technology leaders close enough to the work, the customers, and the people to see what they otherwise might miss?

I encourage my leaders to spend time in the everyday working life of the recipients of our solutions. Sit with some of our biggest customers and watch them place an order through our website. Sit with our middle- and back-office team and watch their process of paying an invoice, receiving an order, entering an order, processing an order. Go to the distribution center. Spend time with the people who are using your solution.

Our customer experience officer has been riding around with salespeople, experiencing what they are going through in a day-to-day environment. I’m going out to Milan, Italy, next week to open our new our automated warehouse there. I’m almost more excited about launching it and seeing what we’ve implemented in use than I was planning the program. I want to see the ship sail in clear waters.

When technology leaders spend the time doing this, they start to see the connection directly between what they’re putting out there and what actually has to take place. You get very different perspectives from different sides of the fence when you get hands-on. It’s less about KPIs and dashboards and the results out of the other end of it. It’s more about understanding who’s consuming what you’re producing and how you’re providing value to them. Because sometimes, their biggest pain point is something you put down as a priority 5, and it’s in the lowest level of the backlog, but would completely change their perspective, improve their experience, and drive value.

What have the best consumer experiences taught you about orchestrating a B2B customer experience that will continue to differentiate RS Group?

Our catalog is massive, and we’ve got so much to navigate. As a consumer, with the new developments you can go on to an Amazon experience and find anything you want using even cryptic keywords. Or you can go on to Google and find 20 different buying options. That is absolutely transformative for us, because a lot of our customers buy that way. They’re searching for something that’s maybe very specialized, so they expect the same kind of Amazon-type experience when they’re looking for a specialized manufacturing-line repair part.

For us in the technology space, it means we’ve got to make sure that our data and our foundations are prepared to enable those large language models for the AI and generative search for agentic purchasing. What’s a little bit different from the B2C space is that many of our customers are starting to implement agents to do a lot of their procurement. So we’ve got to be prepared on the receiving end of those agents to be able to place those digital orders. It’s not really an e-commerce, add-to-cart channel anymore. Now it’s a direct agentic experience in purchasing for our bigger customers that use agentic purchasing.

To lead the way on that is a huge differentiator, and we are aware of it, and we’re keeping an eye on it. We have to be able to move fast and pivot quickly. Who would have thought two years ago that we were going to be talking to agentic procurement?

For years, we’ve challenged IT organizations to do a better job demonstrating their value to the business and to become trusted advisors. How has your organization made that pivot, and what does the next evolution of that journey look like?

When I first joined RS, my department was seen as less of a technical advisor or an expert in new technologies and new ways of getting things done. We were seen more as order takers and a cost center, basically a necessary evil. The pivot we’ve gone through has happened by listening and engaging with the business to understand and help them articulate what problems they’re truly trying to solve. I say, “Please tell me the what, and let me and my experts provide you the how.”

It’s taken some time, honestly. That evolution from an order taker to a trusted advisor is a journey, because you’ve got to prove that you know what you’re talking about, that you’re up on the latest technology, you understand the latest tools, and you are thinking outside of the box — truly providing the vision and the art of the possible to a problem they don’t know how to articulate. The biggest driver for me is connecting my leaders and my team to the business in general. They’re out looking for tools to solve those business problems.

Now we’re starting to partner with our business partners to show them the art of the possible with some of the new trends that are coming, like agentic procurement and large language model search. SEO is gone; now it’s GEO, generative engine optimization. So instead of “Tell me your business problem,” it’s moving to “Let me tell you how to solve a problem you might not know you have yet. This is a way to anticipate what is probably coming down the pipeline, and it’s going to be a problem soon.”

Because we’re leading the way in talking to our business about where the future’s going in technology and customer search and customer analytics and data science, we’re being brought in to discuss these developing trends.

That level of anticipation requires intelligence, or what you’ve described as “intelligent automation.” What’s involved in building that kind of anticipation engine?

Just like you can’t expect a 300-year-old house to be a smart house overnight, you can’t turn a 100-year-old business into an efficient, highly data-connected enterprise overnight. We know that we’ve got some legacy plumbing that we need to repair, and we are well into that journey now. We know that the data we have is incredibly valuable, but we need to understand how to use it, how to interrogate it, and how to get the right answers out of it. Without a structured format, and without all the speed and the pipes and efficient use, we can’t take advantage of that.

Bad data and a bad foundation only accentuate bad decision-making from the data. If you put a lot of intelligence over the top of an unstructured or bad format and foundation, you get really bad data to make decisions from, and it just makes it that much worse. So sometimes you have to build a little bit of a foundation before you’re able to just run with it.

For years, the goal for technology organizations was to become the trusted advisor who gets invited to the first meeting, not just be handed requirements after the important decisions have been made. Robertson’s experience suggests that today’s CIOs need to challenge their organizations to go further, from “Tell me what you’re trying to accomplish” to “Let me show you what’s coming.” That requires getting close enough to your business colleagues and customers to see what they may not see yet. It’s the difference between being invited to the first meeting and being the reason the meeting gets called.

For more from Janet Robertson’s leadership playbook, tune in to the Tech Whisperers.

See also:

• IT reinvention requires mastering the art of translation
• What separates true enterprise leaders from strong tech execs
• The 7 new Cs of IT leadership for the AI era

Every platform leader I know is being asked the same question: How do you deliver more with less?

The usual answers are familiar: hire more people, add more process or ask the existing team to move faster.

All three miss the underlying constraint. Headcount is an input. Throughput is an outcome. Organizational complexity is a cost.

Adding people can increase capacity, but it also adds communication paths, onboarding, coordination and decision overhead. Adding process can create consistency, but it can also slow the decisions it was meant to improve. Asking a team to work harder eventually consumes the very capacity you are trying to increase.

There is another answer: design the organization so ownership scales faster than headcount. That means deliberately small pods with sharp charters, end-to-end ownership and aggressive use of automation, platforms and AI.

I spent more than a decade running provisioning and lifecycle for very large infrastructure fleets at VMware, where small teams operated systems at a scale that looked impossible on paper. Today I lead an engineering organization of three teams at Stripe, built from a half dozen pods, each with its own charter and a large scope that nests into the team and organization charters above it. The lesson has held in both environments: the unit of scale isn’t headcount. It’s ownership.

Small pods work because they concentrate ownership, reduce coordination and make leverage compound.

The headcount trap

When a leader says they need more people, they usually mean they need more throughput. The two are not the same.

Brooks made this point in The Mythical Man-Month: adding people to a late project can make it later because communication paths grow faster than headcount. The tax does not stop at communication. Every additional person can add onboarding, alignment, decision-making, context sharing and ownership ambiguity. As organizations grow, nobody can hold the entire problem in their head. The organization compensates with meetings, documentation, processes and coordination roles.

You haven’t necessarily bought capacity. You may have bought complexity.

This does not mean hiring is bad. Growing teams and increasing scope often require more people. The mistake is treating headcount as the default answer to every capacity problem.

Before adding people, ask a harder question: What is preventing the existing people from owning more?

Sometimes the answer is genuinely capacity. Often, it is handoffs, fragmented ownership, repetitive work, unclear boundaries or systems that nobody has permission to retire. Those are organizational design problems.

The squeeze-harder response fails differently but just as predictably. The engineers who absorb extra load quietly are usually your strongest ones. They are also the ones with the most options elsewhere. You won’t see the organizational cost immediately. You’ll see it when they leave.

Design for ownership

A pod is a small group of engineers with one clear charter and ownership of a meaningful scope from end to end: building it, operating it and eventually retiring it.

The exact number matters less than the principle. The group should be small enough that its members can understand the problem, make decisions without extensive coordination, and maintain unambiguous ownership. The goal isn’t to hit a magic headcount. It is to keep the cognitive and coordination load low enough that ownership remains clear.

The charter is what makes that possible. A good charter is one sentence that names what the pod owns and, just as importantly, what it does not.

“Own the lifecycle of this fleet, end to end” is a charter.
 “Help with infrastructure” is a wish.

In my organization, each pod’s charter is large in scope but sharp at the edges. Pod charters roll up into team charters, and team charters roll up into the organization charter. That hierarchy creates something more valuable than organizational neatness: decision rights.

When a request arrives that fits no charter, it becomes a visible leadership decision. Should we create a new pod? Change an existing charter? Stop doing something else? Or explicitly decline the work?

Without clear boundaries, the same request usually finds the most helpful engineer and becomes someone’s spare-time responsibility. That is how organizational entropy starts.

End-to-end ownership is the real multiplier. When the same people who build a system operate it and eventually decommission it, handoffs disappear. Waiting disappears with them. Quality improves because the people creating the system are also responsible for living with its consequences. Decisions get faster because there is no ambiguity about who gets to make them.

Ownership compresses organizational latency.

The leverage stack

Small pods only outperform if human effort is multiplied. A three-person pod delivering ten-person impact isn’t doing ten people’s work through heroics. It is using leverage.

I think about that leverage in three forms: automation, shared platforms and AI.

Automation

The first form is automation. I have run one rule for years: a repeated task is a bug in the system, not a job description.

If a pod does something twice by hand, the third time it should become code, a pipeline or a paved path that makes the right way the easy way. The system should do the repetitive work. Humans should do the judgment work.

Platforms

The second form is organizational leverage. Shared platforms, paved roads, reusable infrastructure and common capabilities allow every pod to build on work that someone else has already done. A pod that can consume a reliable internal platform ships like a team much larger than itself. A pod that has to build its own foundations is a small team doing a large team’s plumbing.

The best platform work therefore does more than improve one team’s productivity. It multiplies the capacity of every team that depends on it.

AI

The third form is increasingly AI. The interesting question isn’t whether an engineer can write code faster with AI. The more important question is whether AI allows a pod to absorb more scope without adding people by reducing the cost of cognitive work.

AI can help pods investigate unfamiliar systems, generate and analyze code, create tests and documentation, accelerate onboarding and absorb routine operational work. That creates a new kind of leverage: compressing work that previously consumed significant engineering time.

But AI does not fix organizational ambiguity. It amplifies the structure it lands in. A pod with a sharp charter, clean interfaces and strong ownership can turn AI into leverage. A vague organization with an AI assistant can simply produce ambiguity faster.

The goal isn’t AI-powered productivity for its own sake. The goal is increasing the scope a team can responsibly own.

The hardest decision is what not to do

None of this is free. Staying small requires decisions that often feel wrong in the moment.

The first is choosing what not to staff. Every planning cycle produces more good ideas than the organization has capacity to pursue. The design only holds if you let some of those ideas die on the table. A pod at 120% of its charter is not a success story. It is a slow failure with good PR.

The second is allowing pods to kill their own systems. End-to-end ownership includes the end. A pod that cannot retire its own work accumulates systems faster than it can eliminate them. Eventually, engineers spend more capacity feeding old systems than creating new value. Some of the highest leverage work my teams have done has been turning things off.

The third is saying no to good ideas because the pod is full. Not “not yet.” Not “let’s find a way.” No. The charter is the reason. It feels harsh. What is actually harsh is saying yes and allowing the pod to discover the cost at 2 a.m.

The hardest part of small-pod design is not deciding what each pod should do. It is deciding what the organization will deliberately not do. That is a leadership responsibility.

Defend the boundary

The biggest threat to a small pod isn’t failure. It is success.

Successful teams attract scope. A team solves one problem, so someone asks it to solve the adjacent problem. Another stakeholder has a one-off request. A system loses its owner and suddenly the successful team becomes the obvious new home for it.

None of these requests is unreasonable individually. Together, they create organizational entropy. A successful pod can quietly become the large, overloaded team it was designed to replace.

Defending small is therefore active work.

The charter is the first line of defense. Requests outside it get a visible decision, not quiet absorption.

The second is regularly reviewing what each pod is actually carrying against what its charter says. Scope drift is much easier to see on paper than in someone’s calendar.

The third is recognizing when a pod has genuinely outgrown its design. When a pod’s scope has legitimately doubled and stayed there, the answer isn’t to quietly double the size of the pod. Split the scope. Create two pods with two clear charters.

Scale the ownership boundary, not the coordination burden.

When small pods don’t work

Small pods are not a universal answer.

Some problems genuinely require larger groups or tightly coupled expertise. Some domains have operational, security, regulatory or reliability requirements that make a very small team impractical. Some work is inherently exploratory and doesn’t yet have a stable boundary that can become a pod charter.

The principle isn’t “make every team smaller.” It is: make ownership as small and as clear as the problem allows.

If a problem cannot be cleanly separated, don’t force an artificial boundary. But if a problem can be owned end to end by a small group, don’t add organizational complexity simply because more people are available.

Measure leverage, not activity

Traditional engineering metrics often measure activity: tickets completed, projects delivered, story points, utilization. Small pods need measures that make their leverage visible to the business.

I look for three categories.

Capacity

• Scope owned per engineer
• System scale supported per engineer
• Operational load per engineer
  
  

These numbers reveal how much meaningful scope the organization can sustainably own.

Velocity

• Lead time from request to production
• Decision latency
• Time spent waiting on another team

These show whether ownership is actually reducing organizational friction.

Leverage

• Toil eliminated
• Manual workflows automated
• Systems retired
• Capacity reclaimed
• Recurring operational work eliminated
  

These capture the work that no longer requires human effort.

These are signals, not quotas. The goal is not to maximize scope per engineer, but to understand whether organizational leverage is increasing sustainably.

A small pod’s most valuable work is often invisible: an incident that never happened, a system that no longer exists, a manual process that no longer requires an engineer, a dependency that disappeared, a class of requests that became self-service.

If you don’t count those outcomes, the organization’s highest-leverage work becomes invisible. And invisible work does not survive budget season.

The real trade

None of this is a shortcut. Small pods demand sharper charters, stronger technical foundations, more discipline about leverage, and harder leadership decisions than large teams do.

That is the trade. You exchange the comfort of headcount for the compounding leverage of a few people who own something completely and multiply themselves through automation, platforms, AI and organizational clarity.

The goal isn’t fewer engineers. It is less organizational complexity per engineer.

The organizations that consistently deliver more aren’t necessarily the ones with the most people. They are the ones where small groups can own increasingly large scopes because the organization systematically removes coordination, toil and work that doesn’t require human judgment.

Scale the scope, not the team.

CIOs have always felt pressure to deploy emerging technologies rapidly. Implementation brings challenges, including calculating and measuring upfront investment costs. Deploy too quickly, and when the hype fades, many IT departments are left with a costly architecture to support, security gaps, and operational issues.

The same trend is happening with AI. Many CIOs procured enterprise-wide AI model licenses and empowered employees to experiment with language models and develop AI agents. Others asked DevOps teams to accelerate AI code generation and vibe coding. The shift from rapid experimentation to deploying more AI capabilities to production can leave CIOs with mounting AI debt and AI FinOps gaps.

CIOs’ near-term concern is managing budgets amid consumption-based AI pricing models. Even as AI token costs decrease, more employees are using AI, and agents are given more challenging, expensive assignments. Here are seven common mistakes IT leaders make that result in blown AI budgets.

Defining an AI strategy without measurable business outcomes

Most CIOs and CAIOs recognize the need to establish AI strategies focused on areas where AI can provide lasting business value. But many fail to quantify targeted business outcomes, leaving employees to use adoption metrics as the primary objective.

“Every token spent on a pilot that never proves its value is money leaders can’t get back and lost opportunity cost, which is a governance failure more than a technology one,” says Rob Scudiere, CTO at Verint. “Every agent and workflow should have to earn its budget by showing results that achieve the desired business outcome, or lose it.”

Kris Beevers, CEO and cofounder of Netbox Labs, says to use existing business metrics to see whether the areas adopting AI are improving them faster. “If adoption is climbing but the outcomes aren’t moving with it, that’s a pretty good signal to rethink where you’re spending,” Beevers says.

Recommendation: Financial impacts may be hard to target during experimental phases, but employees should set financial objectives before moving AI agents into development and deployment phases.

Experimenting without AI governance

CIOs may find they have a real mess on their hands when a few pilot AI agents quickly scale to thousands running in production. Much of AI governance focuses on identifying owners, setting data-access rules, defining target business outcomes, and establishing accuracy guidelines. CIOs must also educate employees on underlying cost factors, including model selection and platform standardization.

“Delayed AI governance gets framed as a compliance risk, but it’s just as much a budgetary concern,” says Guy Bourgault, head of agentic systems at Concentrix. “The longer organizations wait to define ownership, standards, and controls, the more they end up funding inefficiency, rather than progress.”

Varun Goswami, global head of product and AI at Newgen, says AI budgets are wasted on scattered pilots, duplicated integrations, and agents that run quietly without ever proving value. “Build on one governed platform rather than a dozen parallel stacks, reuse templates and connectors instead of custom-building each use case, and match the model to the job rather than routing everything to the priciest foundation model,” Goswami recommends.

Data quality is a third concern, according to Collibra and The Harris Poll, with 96% of IT leaders saying project failure almost always traces back to poor data foundations, and 51% reporting significant staff hours spent manually correcting autonomous AI agent outputs. CIOs should set data quality metrics and establish data products to build a trustworthy AI context layer.

Recommendation: CIOs should update and communicate their AI governance policies monthly, as AI cost, capabilities, compliance, and security considerations evolve rapidly.

Focusing tokenomics on model costs and not business value

Much of the discussion around AI token economics, or tokenomics, focuses on the costs of using different AI models. But the FinOps Foundation defines tokenomics as “the study of how the production, distribution, and consumption of tokens generate business outcomes and AI value within an organization.”

Because many organizations use multiple models, SaaS with AI agents, and internally developed AI agents, CIOs should partner with the CFO to measure total impact, including AI’s direct token costs, employee efforts, ongoing inference costs, and the value delivered.

“Companies can quickly overspend on AI when they focus too narrowly on token consumption, and the starting point should always be the business outcome,” says Prakash Kota, CIO at UKG. “I use the Three T’s: does the work require talent for judgment or expertise, can existing tools solve it efficiently, or do tokens create enough value to justify the investment?”

CIOs should then set AI budgets at the employee, department, and workflow levels. Each group’s budget should be reviewed and adjusted regularly based on outcomes. This discipline promotes fiscally smart decisions about when and how to use AI capabilities and can drive a top-down culture change.

“The same tokens can go to a skilled engineer shipping a product faster, or to a non-expert generating 10 versions of the same slide deck,” says Tom Shea, CEO and cofounder at OneStream. “The line item in the budget looks identical either way, and true token efficacy requires governance to ensure those tokens are empowering experts to accelerate output, rather than fueling a massive cost explosion.”

Recommendation: Setting AI budgets too soon may curtail employees’ enthusiasm in learning and experimenting with AI. Establish financial targets based on a maturity curve to encourage experimentation first, then fiscal discipline when AI agents are deployed to production.

Developing AI agents without standards

CIOs should communicate these two cost considerations to DevOps teams using AI code generators.

First, according to Stack Overflow’s 2026 Developer Survey, 73% of developers use AI coding assistants and agents daily, but developers care more about quality (75%) over cost (38%) when shaping prompts and picking models. CIOs should set guidelines for balancing cost and quality tradeoffs, establish DevOps non-negotiables, and require code analysis in deployment pipelines.

“Coding is no longer a constraint, and the bottleneck has moved to how we ensure the correctness of code,” says Anurag Dhingra, SVP and GM of networking and collaboration at Cisco. “There’s just no humanly possible way to review every piece of code that is written by AI.”

The problem is that 96% of developers don’t fully trust AI-generated code and 48% always check their AI-assisted code before committing, according to Sonar’s State of Code Developer Survey. As large organizations may use several AI code-generating tools, they need to benchmark quality, cost, and developer satisfaction.

“Teams need clear guardrails and engineering standards, especially as AI agents accelerate development and can introduce costly rework,” says Andrea Malagodi, CTO at Sonar. “Having live data aggregated from your one or many providers, to enable you to see the cost per PR [pull request], is a good governance mechanism.”

Recommendation: While AI code generation is a remarkable breakthrough, it also brings new costs and quality considerations CIOs should track.

Using frontier models for all AI needs

Another cost consideration comes as organizations deploy hundreds of AI agents and provide developers several AI models to choose from. Developers may choose models based on preferences rather than performance and cost considerations.

Craig Wiley, VP of AI at Databricks, says 77% of companies now juggle multiple model families because the best model for one task is rarely the best for another. “The flexibility comes at a cost of managing shifting prices, scattered vendors, and zero visibility into where your budget’s actually going. The fix is real-time budgets and smart routing that automatically sends queries to the most cost-effective model,” Wiley says.

Recommendation: Josh Fecteau, chief data and AI officer and CIO at Teradata, says that frontier models are expensive and not necessary for every task. “Diversify your model strategy with cheaper small language models, custom models, and industry-specific models,” Fecteau recommends.

Deploying AI agents without monitoring cost spikes and inefficiencies

A key challenge with AI agents is their variable costs, especially when they are given tasks of varying complexities. While some AI providers are moving to outcome-based pricing models, many still use a license model with a fixed number of tokens, plus consumption-based pricing for overages. This means CIOs must monitor costs, set AI observability standards, and define rules for handling performance variances in AI agents.

“I spent 25 years in telephony where every minute had a price, and agentic AI is the first software I’ve seen that bills like a phone call and gets budgeted like a license,” says CJ Combs, AI strategy executive at Columbus. “AI costs stop being predictable the moment an agent can loop, because it keeps pulling in context, retrying, and calling tools in ways nobody budgeted for.”

Experts suggest several implementation cost inefficiencies to review. Babak Pahlavan, founder, CEO, and CPO at NinjaTech AI, says that AI agent processing duration is an easy indicator. “A single autonomous agent running a multi-hour task can burn a month’s allocation in an afternoon because every tool call, every retry, every piece of context it re-reads gets billed,” Pahlavan says.

Other cost factors require experts to review an AI agent’s decision logs to determine optimization. Adi Elimelech, CTO and cofounder of Jedify, says, “If every query drags an entire database schema back to the LLM, token costs scale with the size of your environment rather than the complexity of the question. The cost compounds, since the model often doesn’t get it right on the first pass and loops back for another round trip before landing on the correct answer.”

Recommendation: CIOs will need to mature several AgenticOps and site reliability engineering practices to monitor AI agents and respond to cost, security, quality, performance, and other incident types.

Building agents without a change management plan

One of the biggest gaps in deploying AI agents is that deployment is just one step in a change management process. AI governance requires identifying agent owners who are accountable for decisions and responsible for outcomes. These owners should also sponsor the underlying change management process.

“The biggest AI cost overruns rarely come from technology,” says Abhijit Kakhandiki, SVP and GM of digital business automation at BMC Software. “They come from organizations deploying AI without redesigning processes, ownership models, and governance.”

Part of the change process requires identifying human-in-the-middle responsibilities to review the agent’s recommendations. The review process builds trust and lets owners switch to autonomous decision-making for low-risk, high-volume, trusted recommendations.

“It’s not going to be a binary switch where, from day one, you’re going to trust AI agents to run tasks autonomously,” says Joel Hellermark, chief AI officer at Workday. “Progressively, they’re going to earn the right to run those workflows autonomously. If it’s your fiftieth time approving an expense below $50 for one of your direct reports that looks exactly on policy, you can trust the agent to run it for you.”

Recommendation: Growing adoption isn’t the end game, but it’s a key step toward delivering business value. Metrics to track adoption include AI response quality, trust scores, repeat usage, and value delivered to adopters.

A simple rule is that you can’t manage what you don’t measure. CIOs should set budgets, track costs, and measure outcomes, especially as more agents move into production.

Much has been made of Generation Z’s supposed inability to adequately conform to modern-day corporate culture.

A recent Business Insider article on Gen Z (born 1997–2012) workplace readiness contains some damning statistics. The piece cites a 2024 poll of nearly 1,000 business leaders, 75% of which described some or all of the recent graduates they hired as “unsatisfactory.” Arguably worse, it cites another 2024 study from Hult Business School, in which 37% of HR leaders said they’d prefer to have a robot or AI do a job than hire a recent new grad, while another 30% said they would rather just leave the job vacant. Quite damning, indeed.

Warranted or not, these complaints about Gen Z are not new.

NYU Stern professor Suzy Welch conducted a September 2025 study juxtaposing the values of incoming Gen Z workers with those of hiring managers. Welch’s study included survey data from 2,100 hiring managers and a behavioral assessment of over 45,000 respondents (7,500 of which were Gen Z).

In a Wall Street Journal Op-Ed, Welch writes, “A mere 2% of Gen Z members hold the values that companies want most in new hires, namely achievement, learning and an unbridled desire to work.” According to Welch’s study, Gen Z members mostly value well-being and self-care, helping others and authenticity and expression. Oh, heaven forbid.

Not to be outdone, in March 2026, another NYU professor wrote a Wall Street Journal Op-Ed on “Why Gen Z is unprepared for the workplace.” The one, from psychology professor Tessa West, laments Gen Z’s lack of communication skills and failure to understand older generations. West writes, “Younger generations—Gen Z specifically—have learned to communicate in a digital world, sending texts and instant messages instead of interacting in person.”

West attributes Gen Z’s poor communication skills to a combination of excessive screen time, online classes during the COVID pandemic and a general overreliance on technologies. I cannot definitively say whether these accusations hold water; however, I do believe that the answer doesn’t lie in replacing humans with AI or leaving roles unfilled. Hiring managers need to adapt to younger generations, whether they want to or not. And we’re seeing this in the help desk software space in real time.

Gen Z has little patience for traditional corporate bureaucracy

Aside from grievances from older folks like me, the fact remains that Gen Z has little patience for traditional corporate bureaucracy. When these younger workers experience a technology glitch, they don’t want to log into a clunky portal, fill out a 10-field form and wait two days for a level 1 support agent to respond. These kids expect instant, consumer-grade, self-service resolution. If the enterprise doesn’t provide it, they’ll just bypass IT entirely.

To overly generalize, most members of Gen Z are comfortable with AI chatbots and tend to search for their own solutions online before reaching out to another human directly. This tendency to rely on mediated communication as opposed to person-to-person communication makes sense given their life experiences with COVID, online coursework, the post-pandemic reevaluation of work culture and their status as a mobile-first generation.

Ramifications for the help desk software space

To retain young talent, enterprises should consider deploying conversational AI, automated self-service password portals and omni-channel support to match the speed at which Gen Z operates.

Self-service should be the first order of operation. Rather than forcing employees to create a ticket and escalate an issue to an agent, workers should have the option to remedy the situation themselves. Across the IT support industry, we’re seeing more emphasis on AI oversight and escalation handling, as opposed to level 1 IT support work.

Additionally, given Gen Z’s mobile-first status, it is vital to have mobile-native applications for internal IT issues. These shouldn’t just be desktop portals reconstructed to fit a mobile interface; these should be mobile apps with consumer-grade quality UX interfaces equipped with things like push notifications for ticket updates.

We’re also seeing more agentic chatbots in the ITSM space. Gen Z workers (and all generations, really) expect agents to be able to handle simpler requests, like access provisioning, password resetting and resolving calendar conflicts.

Omni-channel continuity has become vital too. When Gen Z’ers begin a conversation in Slack or Zoho Cliq, they expect that conversation to seamlessly flow into SMS, email, mobile apps and other corporate channels.

Key takeaway

When it comes to IT service management, Gen Z workers expect agentic self-service, a mobile-first UX, omni-channel support and the ability to resolve tier-1 support issues themselves. Despite the lamentations of some old curmudgeons like me, Gen Z isn’t going anywhere. And what’s more, Gen Alpha (2010 – 2024) is waiting in the wings. If we haven’t brought our service desk infrastructure up to Gen Z’s standards, now is the time.

The legal disputes between Germany’s largest software company, SAP, and the Munich-based process mining specialist Celonis took another turn last week. After the German Federal Cartel Office most recently dismissed a complaint filed by Celonis in July, the Munich I Regional Court ruled entirely in favor of Celonis in a case regarding the infringement of a European patent held by Celonis.

Case No. 7 O 12849/25 concerned patent EP 3 139 274 B1 describing a method for determining a net lead time between process steps using process data stored in a structured manner in main memory (in-memory).

Celonis had filed a lawsuit alleging that the patent was infringed by a feature of the SAP Signavio Process Intelligence software solution — SAP acquired Celonis’s rival Signavio in March 2021.

SAP must cease use and provide information

The court ruling prohibits SAP from offering the patent-protected method in Germany or using it itself. SAP must also provide Celonis with information regarding the extent to which it has infringed the patent since April 22, 2020, including details on:

• where the patent-infringing processes originated and through which channels they were offered and distributed;
• which customers purchased them, including names and addresses;
• how many access licenses were granted and how much users paid for them;
• for how many users the methods were used per calendar year;
• which other individuals were involved in offering and using the methods.

In addition, SAP must provide a transparent account of the extent of the patent infringements based on its financial figures. The company is obligated to pay appropriate compensation or damages.

“The ruling by the Munich Regional Court confirms our legal position: SAP Signavio’s technology infringes on Celonis’s patent rights. We consistently protect our intellectual property and remain committed to fair competition,” explained a Celonis spokesperson.

SAP says no consequences for its customers

SAP, however, points out that the court ruling pertains to a single, specific feature within SAP Signavio Process Intelligence, not to the product as a whole. SAP Signavio Process Intelligence remains available to customers, according to a company spokesperson.

The spokesperson also dismissed concerns that the ruling could hinder companies’ migration to SAP S/4HANA Cloud. Migrations to SAP S/4HANA Cloud are not affected by this, he said. SAP is working to ensure that there are no disruptions for its customers.

The concern is not entirely unfounded: SAP Signavio is part of Rise with SAP, a SaaS solution from the Walldorf-based company designed to support migration to the S/4HANA Cloud. SAP Signavio’s process mining tools are designed to provide insight into actual process flows and identify inefficiencies and bottlenecks.

SAP will appeal

The Regional Court’s ruling does not mean the matter is by any means settled: As the spokesperson for the Walldorf-based software giant explained, SAP does not share the Munich court’s legal opinion and will file an appeal against the ruling. In addition, SAP has challenged the validity of the patent in question before the Federal Patent Court.

“SAP’s top priority is to ensure that customers are not affected by this. All other issues will be resolved through the appropriate legal channels,” said the spokesperson for the Walldorf-based company.

This article first appeared on Computerwoche on Oct. 13, 2026.

Regulated industries have been dealing with the equivalent of sovereign data for a long time. And as the geopolitical situation makes it more broadly relevant, it doesn’t make it any easier to deal with.

From concerns about the reach of the US CLOUD Act and what telemetry or sensitive business data gen AI models might collect, to implications of the US government taking part ownership of a range of technology companies and the impact of EU regulations, the state of the world means more organizations need to think about where data is located.

The result is a flood of announcements from hyperscalers about new EU cloud regions, as well as pitches from regional and private cloud providers. The promised sovereignty may be anything from a local availability zone to more sophisticated approaches to ownership structure, compliance frameworks, where logs are stored, or where support staff work.

Actual data sovereignty involves legal, technical, contractual, governance, and infrastructure questions, but all too often, what’s on offer is what IDC research director Rahiel Nasir calls sovereignty washing. “When you look under the lid, all they’re really offering is a solution for data residency and data localization, keeping data in country,” he says. “That’s part of sovereignty, but not all of sovereignty.”

In his experience, in-country data centers are the first thing organizations ask for to support data localization and data residency, but they also require enhanced controls over identity and access management. That’s critical because data sovereignty is as much about who has access to the data and why, as where it lives.

“It’s really important the only people who touch my data in what is supposedly a sovereign cloud environment are those I give permission to,” he adds. “Because it’s my data, and I’m the only one who can give the authority to grant access to it. That also applies to support and admin staff.”

Companies want control through where they store data but also to restrict how users can interact with it that might expose that information outside an approved environment or jurisdiction, adds Acceldata SVP Ali Afsar.

Access and control

Don’t confuse the regulatory requirements of data residency with data sovereignty, Scality CMO Paul Speciale warns. “Residency is about geography,” he says. “Sovereignty is about control, jurisdiction, and who ultimately has the legal authority to access data.”

For CIOs, the question is no longer simply where the data is but who can access it, who controls the encryption keys, under which legal framework it operates, and can that control be proven. That includes being able to show who accesses data, from where, and for what purpose, which requires verifiable controls like jurisdiction-aware data placement, immutable backups, tightly governed admin access, and clear audit trails.

The UK government’s recent call for evidence on the impact of international data flows on sovereignty makes this explicit, referring to transfer by access where personal data remains in the UK but is accessed from overseas, including by a user located in another country. Access transfers include administrative access, backups, disaster recovery, support incidents and sometimes — depending on the specific regulations — processing the data.

GDPR doesn’t mean data has to stay in the EU but it does require data to be protected to EU standards wherever it goes. Data transfer obligations for other jurisdictions can be far more restrictive, so multinational organizations may need access controls limiting who can see what regulated data from different locations.

RBI-regulated payment-system data, for instance, must be stored in India, but can be processed outside India, Afsar explains, as long as it’s deleted from overseas systems within 24 hours. And with limited exceptions, personal data in Saudi Arabia must be processed within the Kingdom, and China treats overseas access to some categories of data stored in China as a cross-border data activity. Russian laws require similar strict data localization, and personal data of Russian citizens has to be stored, processed, and kept within the country’s borders at all times, which is why LinkedIn was blocked there.

Elsewhere, regulations are most restrictive for specific markets like healthcare, financial, and public services. Not everything needs to be transferred to a sovereign cloud, Nasir points out, as use of that data is subject to regulatory compliance, and the increasing need for AI training.

“This is the data that’s going to have catastrophic business impacts if leaked,” he says. “To give enhanced controls and security for that data, you’d consider wrapping sovereign controls around it. Everything else not subject to compliance nor sensitive data can be accessed by whomever you want and from wherever.”

Sovereignty and safety

Organizations typically know data sovereignty rules well but still experience incidents like data breaches, government data access requests, and unauthorized cross-border transfers caused by, for example, traveling employees or excessive admin access, according to Kiteworks’ 2026 Data Security and Compliance Risk report.

“Location only tells a regulator where the data rests, not who can still reach it,” says Kiteworks’ EMEA GM Dario Perfettibile. “Every real exposure we’ve seen so far happens through access not geography.”

Thinking data needs to stay in region because then it’s safe gives a false sense of security if practiced as a substitute for proper data management. Access, data labelling, and retention polices take more work but are what can prevent incidents. “If you have a data policy in place, it can force a reapproval of the access,” he adds. “It can restrict access to you only, or it can block you out immediately.”

Location isn’t everything

Using a service closer to home doesn’t automatically make any of that easier. “Many organizations still assume sovereignty can be achieved by moving data from one cloud provider to another, or by replacing one hyperscaler with another,” says Keepit Group CISO Kim Larsen. “That misses the bigger picture.” CIOs should treat sovereignty as an operational capability not a compliance exercise, he adds, since sovereignty isn’t about scale or ownership of infrastructure for its own sake, but maintaining control.

“If an organization doesn’t know who can access its data, which legal frameworks govern that access, or whether it can recover its data independently, simply changing where the servers are located does little to reduce risk,” he says.

Just because something is based in your region doesn’t automatically make it a good choice. The EC, for instance, has set up accounts on W Social, an independent social media platform based on the AT protocol designed for data mobility and user migration, which Bluesky uses but is hosted in Europe.

The Commission’s own open source strategy suggests open source promises more control over digital infrastructure by avoiding vendor lock in, and a recent policy brief positions digital sovereignty as a form of digital independence. But having servers in the EU isn’t the same as freedom of digital movement since unlike Eurosky, based in Europe and using the same protocol, W limits interoperability so it can require identity verification, and has closed its source code after security researchers pointed out vulnerabilities.

Most organizations will continue to use both global and local providers, though they might prioritize what Nasir called glocal options built on partnerships between the two. “Organizations want to use a mixture of local and global providers,” he says. “They want all the innovation capabilities that the Microsofts, AWSs, and Googles of the world give us, that they consider local providers can’t match.”

IDC figures suggest only 4% of European organizations plan to switch to purely local options. “We can’t live without US technology today and there’s no appetite to do that,” says Nasir. Availability matters and local providers may not have the same level of infrastructure as global options. They can offer low hanging fruit like video conferencing solutions, but not more complicated directory and database services, or productivity software that’s intertwined with those US-provided services.

Choices about where to store data, and the technical controls to enforce that, have their own operational implications.

“Redundancy and resiliency are key tenets of sovereignty,” he adds. “You want to make sure your operations are always available. In order to enable that, you want to spread the risk.”

On a major S/4HANA transformation, the first signs of trouble did not look like resistance. They looked like missed stand-ups. Then deliverables started slipping, readiness checkpoints came back with gaps and the same functional leads kept surfacing on the list of competing priorities.

The people behind those signals were not disengaged. They were functional resources supporting the implementation while still doing their day jobs. At the same time, the organization was adopting Agile ways of working, so they were also learning new project roles, Agile ceremonies, Jira, new testing expectations and new processes. Many of them held real authority in their day jobs that did not carry over into their transformation roles, which meant they were learning to operate without the standing they normally relied on.

When teams fell behind, the response from leadership was reasonable on its face: more meetings, more follow-ups, more frequent status updates. The intent was to get the program back on track. What I watched happen instead was that the same people responsible for completing the work spent more of their week explaining why the work was behind.

That is the pattern most organizations miss. Change saturation gets diagnosed as a communication gap, and the treatment consumes the capacity the team needs to recover.

What misdiagnosed saturation looks like on the ground

Saturation rarely announces itself in an engagement survey. It shows up first in delivery mechanics, and those signals are easy to read as a discipline or messaging problem.

The first signal is erosion in attendance, not pushback. Stand-ups get missed, ceremonies get shorter and the same names drop off invitations. Nobody is objecting to the transformation. They are triaging their calendars.

The second signal is status work crowding out delivery. When a growing share of a team’s week goes to preparing updates, attending check-ins and answering follow-ups, the program has started paying for visibility with the capacity it needs for execution.

The third is readiness gaps that get labeled as training issues. People who attended the sessions still are not ready, because the sessions competed with everything else on their plate and landed at the wrong moment.

The fourth is easy to overlook on global programs: capacity assumptions that do not match the actual calendar. On more than one program, the roadmap accounted for U.S. holidays and overlooked holidays affecting large portions of the teams in India, South America and other locations. The plan was built on capacity that was never there, and the gap surfaced weeks later as slipped dates.

Taken together, these signals point to the same root cause. The work did not get harder. The load did. Yet each signal is usually treated as a separate performance issue and handled with more oversight.

None of this is unusual. In Prosci’s research on change saturation, 78 percent of respondents said their organizations were nearing, at or past the point of saturation, and people managers and front-line employees carry the heaviest load. Those are the same people a transformation depends on to adopt and operate what it delivers.

Why more communication makes it worse

When a program falls behind, the executive instinct is to increase pressure around the existing dates. Add a working session. Increase the cadence of status reporting. Ask for more frequent communication so leadership can see what is happening.

Every one of those moves is made with good intent, and every one of them draws from the same limited pool of time. The people being asked for more updates are the people who were already stretched. On a program adopting Agile at the same time, the added forums sat on top of stand-ups, planning sessions and retrospectives the teams were still learning to run. Visibility goes up, capacity goes down and the program slips further. It also changes how the team experiences the program. Instead of support, they experience scrutiny, and people already carrying two jobs start to feel that the program mostly adds questions.

There is a line I use with leadership teams when this starts to happen:

When a team is behind, the instinct is often to add oversight. But every additional status meeting takes time away from the work you’re trying to accelerate.

Communication and visibility matter. They do not solve an underlying capacity problem, and sometimes they deepen it. Gartner found that only 32 percent of business leaders said the last change they led achieved healthy adoption by employees, and Gartner has argued that leaders get further by making change routine than by trying to inspire people through it. Saturation is a load problem. Louder or more frequent messages to an overloaded team do not reduce the load.

What actually relieves saturation

The moves that worked on my programs were less about new frameworks and more about giving capacity back.

Adjust the operating model as teams mature. Early go-lives needed frequent stand-ups, heavy training and hands-on support. After teams had been through multiple S/4HANA go-lives and understood the process, we deliberately reduced the cadence. Daily meetings became four days a week and eventually two. Holding on to the early-phase cadence after teams had outgrown it would have been another quiet drain. Reducing meetings on a program that has just slipped feels counterintuitive. It requires leadership to trust the dashboards and the team more than the meeting count.

Protect time when the team is on track. On one program, we kept Mondays and Fridays free of meetings when the work was on schedule. It signaled that the time belonged to the work, and teams used it.

Make upcoming work visible instead of asking for more reporting. Readiness dashboards showed what was coming, and we gave advance notice when phases were changing so people could plan around the shift rather than react to it. The dashboards did the job the extra status meetings were trying to do, without taking anyone out of the work.

Make support available without requiring attendance. Recorded training, multiple sessions and office hours let people get targeted help when they needed it without adding another meeting to everyone’s week.

Understand the change landscape before launching the next initiative. That means surveying employees and listening beyond the executive level to the functional teams who will do the work. Executives tend to see initiatives one at a time. Employees experience their cumulative impact alongside their day jobs. Research highlighted in MIT Sloan Management Review found that employees can realistically absorb one or two major changes a year, while leaders are planning for three or four. A short survey of the functional teams will usually surface collisions a portfolio view misses, because those teams feel every initiative that lands in the same week.

The principle behind all of this is one I come back to on every program: “You can’t ask people to absorb more change without giving them something back.”

For CIOs, change saturation is a portfolio decision, not a communications task. CIOs sit where multiple initiatives converge on the same functional teams, and they are often positioned to see the cumulative load before anyone else does. The decisions that relieve saturation are theirs to shape: what gets sequenced first, what waits, what cadence a mature team actually needs and whether the capacity assumptions behind a roadmap match the real calendar.

One practical test helps. Before approving the next initiative or the next status forum, ask which work the affected teams will stop doing to make room for it. If nobody can answer, the capacity is being borrowed.

The organizations that sustain transformation across multiple waves are not the ones with the best change campaigns. They are the ones that treat capacity as a constraint to be managed with the same discipline they apply to budget and scope.

You can’t communicate people into having more capacity. You can only decide, deliberately, how much change you ask them to carry at once.

ServiceNow is giving its AI Control Tower new features to make AI agents more governable — and a new name, Super Intelligence Control Tower (SICT), to please the US President. It is also updating EmployeeWorks to make building AI agents easier.

AI Passport, a new component of SICT, gives every agent, whether from ServiceNow or a third party, a verifiable identity, and provides runtime control over its activities.

As enterprises scale autonomous agents from pilots to production, they are facing new challenges, said Nenshad Bardoliwalla, SVP of AI product management at ServiceNow: “If companies can’t identify which agents are running, what they are doing, and what systems they can access, then scaling quickly becomes a risk.”

An AI Passport is a cryptographically signed credential for AI agents that is checked at runtime to verify the scope authorized by the enterprise. When an AI agent stays within its passport scope, it can operate freely, but if it tries to deviate, defined actions are enforced. These can include redirecting, restricting, or reconnecting the agent with proper context, or even triggering a kill switch. All actions are audited so agent activity can be tracked.

It is built on open specifications, so any governance product, identity provider, or enforcement point can issue and verify credentials for their own and third-party AI agents, and those credentials are verifiable at every step in multi-agent workflows.

A bouncer at every door

This is a real step forward, said Frank Dickson, principal analyst at Dickson Research. “Most agent governance today is a security camera. It records what happened so someone can review the tape later. AI Passport is a bouncer at every door.”

The controls extend beyond ServiceNow’s own agents, he said: “For third-party agents, the passport replaces the agent’s own ‘claims’ about its permissions,” he said. “Taking an agent’s word for what it is allowed to do is an Achilles’ heel of agentic AI.”

And, he said, “A passport is only as trustworthy as the office that issues it. Here, the issuing office is ServiceNow’s CMDB, its GRC policies, and its workflow approvals. If that data is stale, the passport is stale. Credit ServiceNow for building on open specifications, but an open spec matters only when others adopt it. Nvidia is the launch partner, and ServiceNow says that enforcement implementation is still being built.”

In addition to AI Passport, ServiceNow has further beefed up its governance tools with a number of other features, including shadow-AI detection to locate unapproved agents on the network; more than 400 connectors to enable AI discovery across platforms and vendors; access mapping; and continuous enterprise AI observability.

It also announced cost governance; “value intelligence” that connects consumption, cost, quality, and “realized user value” to help teams optimize their AI use; AI cost management as part of ServiceNow IT Asset Management, which integrates with the Control Tower; and policy enforcement.

AI Passport, Shadow AI detection, and AI Cost Management are expected to be available by year end.

EmployeeWorks enhancements

The third generation of ServiceNow EmployeeWorks now lets employees add automations to the autonomous AI personal assistants they build. ToolSmith is a new agentic developer environment that takes tool building “from days to minutes,” the company said.

What companies have been trying to do, said Bhavin Shah, SVP of ServiceNow’s employee experience group, “is to give developers a way to build, but in a way that’s governed, that allows them to stay within the guardrails and the controls that that are required in order to do the kinds of safe but deep and capable work that they want for their constituents inside the company.”

ToolSmith helps address that problem. It’s a vibe-coding environment with which developers can build automations for ServiceNow EmployeeWorks AI assistants by describing what they need in natural language. ServiceNow said ToolSmith was trained on over 75,000 APIs and optimized for reliability and token efficiency. Developers can test and refine its output using the same conversational interface.

ServiceNow said that ToolSmith also identifies what to build next, scanning logs “to identify opportunities to fix, improve, or invent the next best workflow.”

Non-coding employees, on the other hand, can build new Productivity Assistants to perform contextual or persona-based work including long-running tasks, the company said. There are also pre-built assistants available, beginning with several for HR service delivery.

EmployeeWorks itself includes two assistants out of the box: a research assistant that can scan internal and external sources for answers, based on the user’s role, and a calendaring assistant that, ServiceNow said, “goes beyond typical calendar booking solutions by orchestrating nuanced requests like scheduling quarterly one-on-ones with an entire team on days that minimize disruption to project work or finding the least hectic day to bring together a team for a full day workshop. “

To automate repetitive tasks, Productivity Routines run proactively in the background, repeating routine steps and providing deliverables without human intervention. Employees just have to describe what they want to automate, select the necessary tools, and deploy the routine.

“The principle is right,” Dickson said. “The people closest to the work understand the problem best.”

But, he added, “the guardrails are only as good as the decisions behind them. Productivity Routines, by ServiceNow’s description, run in the background without human intervention. That is unsupervised work, and someone should own it.”

All of these EmployeeWorks enhancements are in controlled availability now.

Bottom line

Melody Brue, analyst in residence at Moor Insights & Strategy, said the announcements are a sign that ServiceNow is extending its existing security and workflow controls into a broader role in governing agent actions across systems.

“AI Passport makes identity and authorized scope verifiable, Control Tower provides oversight and enforcement, and ToolSmith expands the tools and connectors through which agents can act within enterprise guardrails,” she said, adding that with CEO Bill McDermott’s recent positioning of ServiceNow as a security company, “This suggests an ambition to become a control point for enterprise autonomy.”

But, she said, “What matters now is how consistently ServiceNow can enforce boundaries and verify outcomes across the systems agents actually touch.”

Dickson, too, has concerns.

“ServiceNow says Control Tower tracks spending by user, department, and runtime, and ties that spend to quality and value. The brake is another matter,” he noted. “The graduated alert, throttle, and block enforcement is described in future tense, as is the AI Cost Management integration, which is expected by year end.”

However, “a meter you can watch is not a brake,” he said. “A Productivity Routine that runs every morning is a standing purchase order. Someone should sign it.”

Give every agent and every routine a named owner and a budget before it goes live, he advised, and ask ServiceNow how assists are counted for background routines and whether hard caps exist today. Turn on throttling the day it ships, and reconcile its dashboards against your own invoices.

But despite these concerns, he said, ServiceNow has the right idea. “An agent should carry its permissions, its manager, and its budget wherever it goes. But until the brakes ship, that budget is a decision a person still has to make.”

For the past half century or more, the teams running enterprise software stacks have nurtured a vast ecosystem of tools to keep software humming along. They’ve built CI/CD pipelines, elaborate test suites, code repositories, and tools galore, all with the goal of keeping the systems up and running.

Now AI is throwing a wrench into the whole endeavor. Software is now more complex and sometimes mysteriously unpredictable. Expectations are sky high, but no one is certain what to expect in good conscience.

Luckily, dozens of companies are rushing to build new tools designed to keep agentic stacks on the straight and narrow, delivering value to everyone. The field is rapidly evolving, probably having changed since you started reading this article.

Some of the tools involved in the emerging agent stack aren’t that different from what enterprise teams already have in store. In the end, LLMs are just piles of bits that need to be loaded into a processing chip, just like old-fashioned software. Many of the old tools that watch for overloaded nodes or overpacked disk drives are just as valuable as ever, perhaps more so because LLMs chew through storage even faster. And some of the companies tackling these problems are the same steadfast suppliers who have earned the trust of your DevOps teams; they’ve just extended their own offerings to handle LLMs and AI.

Other challenges, however, are quite different. For example, LLMs are terrifyingly non-deterministic, a real challenge for belts-and-suspenders engineers who traditionally tend the software. Tool vendors are building entirely new systems to handle these somewhat random deviations so that traditional DevOps teams — and their C-suites — don’t have heart attacks.

The field is also rapidly expanding in wildly divergent ways. Some vendors are building tools for developers who are creating new LLMs. Others are concentrating on the challenges that come from worrying about an LLM, day in and day out, in large scale production.

We’ve compiled lists introducing the most intriguing companies developing tools for this rapidly altering space, including tools aimed at AI orchestration; AI observability, aka AgentOps; AI evaluation and benchmarking; and AI trust, guardrail, and governance. We’ve even thrown in some vibe-coding tools for citizen development and AI workflow tools for business processes.

While it was relatively easy to split the field into distinct lists, that process will only grow more challenging because the tools — and categories — are starting to overlap. As vendors evolve their strategies, this overlap will grow further, with a variety of entries tackling a wider range of challenges, vying for a greater percentage of CIOs’ AI middleware and operational budgets.

To help you make sense of this complex tool landscape, here are the most common categories vendors are using to identify what their products do, each of which maps to what are becoming the key components IT needs to keep their AI and agentic stacks productive and humming.

Observability

Vendors often use the term “observability” to refer to the most basic of data collection work — that is, testing to make sure the various machines are running, the RAM isn’t too full, latency is acceptable, and the logs aren’t filled with error codes.

Watching these metrics isn’t much different from caring for an old-school collection of microservices, and often the tools aren’t much different, either. Many of the most popular tools are the same dominant market leaders that have been extended to collect data from the various GPUs, too.

Leading vendors: DataDog, Dynatrace, New Relic, Splunk
Upstarts: Ariz, LangSmith, Braintrust, Galileo
Open-source alternatives: OpenTelemetry, Phoenix, Langfuse

Cost engineering

Many AI pipelines are often more complex than regular microservice architectures, and that means they need someone to carefully watch the bill. Plus, as attention to AI ROI rises, capturing spend is essential — especially given how quickly AI tokens can add up.

Cost engineering tools can integrate information from various portals like OpenRouter and compare it against internal hardware. Sometimes breaking down these comparisons is difficult because the right way to allocate costs to each user isn’t as obvious, even though they’re often just one number. These accounting operations tools will become even more important as LLM bills grow.

Leading vendors: CloudZero, Finout
Upstarts:  Amnic, Bifrost, Portkey
Open-source alternatives: OpenCost, Langfuse

AgentOps

When metrics and telemetry begin to focus on the LLM, the word “AgentOps” starts to appear. It’s just like DevOps but it’s concerned with watching token counts, tracking the performance of RAG databases, and collecting traces for debugging purposes.

When the work is truly agentic, AgentOps must also juggle the state that agents generate while looping through their various activities. Agents aren’t just a one-and-done call to an LLM. They’re software packages that need to store information as they work toward a final answer.

This job of an AgentsOps team gets trickier because these areas are where the models often behave non-deterministically. Is some model hallucinating? Are an agent’s prompt chains running to completion? The tools in this space track all these metrics, often in a dashboard with nice graphs that make problems stand out.

Leading vendors: Databricks, Datadog, Dynatrace
Upstarts: Arize, Braintrust, Comet
Open-source alternatives: Langfus, LlamaIndex

Evaluation

The buzzword “evaluation” starts to appear alongside tools that are used in the earlier stages of development, when various models and prompt combinations need to be tested again and again.

In many cases, these tools use another model to evaluate the quality of the answer from the first model, as well as to keep an eye out for potential hallucinations or other failures. In some cases, the tools query humans who sit in the evaluation loop to give their opinions of how well the model is performing. Good tools can watch the agents continuously and reroute any sketchy behavior to the human-in-the-loop.

Many of the vendors use the word “evaluation” to describe measuring just how well a model is performing for a particular business application. That is, how well it’s working for what your boss wants it to do.

Leading vendors: Databricks, SuperAnnotate, Scale AI
Upstarts: Braintrust, Galileo AI, MaximAI
Open-source alternatives: Langfuse, Prompfoo, Tagas

Benchmarking

The word “benchmarking” is similar to “evaluation” in AI vendor literature, but it is usually found more in the tools used by the creators of the models. There are a number of public benchmarks filled with standard queries, and the model developers rank themselves on how well they do solving these problems. This often generates a raw score that is then compared to another’s raw number. Some teams create their own benchmarking problem sets and use them during evaluation to assess how well models might meet their needs.

Leading vendors: Hugging Face, Databricks
Upstarts: Reka AI, Patronus AI
Open-source alternatives: Promptfoo, DeepEval

Trust

The tools that wear the “trust” benchmark are often meant to help evaluate how well a model is protecting the needs of any business that is deploying it. That is, can they trust it to deliver accurate and useful answers without hallucinations, data leakage, inappropriate behavior, or worse? Prompts with malicious instructions are especially tricky to detect. Some enterprises want a trust score that measures the consistency of the answers. Overall, tools that target the “trust” metric are often utilized more during development and early deployment.

Leading vendors: Azure AI Content Safety, Bedrock Guardrails, Vertex AI Search
Upstarts: Patronus AI, Arthur AI
Open-source alternatives: NeMo Guardrails, Llama Guard

Guardrails

The word “guardrails” is usually applied to tools that are part of the deployment stack. That is, they sit as watchdogs and make sure the LLM doesn’t spin out of control. They also ensure the model is trustworthy, but they’re more tuned to operating in real-time than those aimed at trust, as outlined above.

These tools are often filled with fixed rules, such as scanning for social security numbers or watching for noxious words. The challenges get trickier because agents are executing software, and that means the guardrails must do more than analyze outputs. They also need to manage the execution environment, often running in a sandbox, and watch for exploits and other malicious behavior. They need to validate and double-check not just code, but the OS-level commands for manipulating files and processes.

Leading vendors: Azure AI Content Safety, Bedrock Guardrails, Vertex AI Search
Upstarts: Patronus AI, Arthur AI
Open-source alternatives: NeMo Guardrails, Llama Guard

Context

Many systems rely on a vector database to store embedded data to chunks of trustworthy documents. These RAG databases need much of the same care as regular databases, and the tools for their care are often similar. PostgreSQL, for example, has a vector addition that needs the same kind of scrutiny from a database administrator as a regular PostgreSQL database.

Leading vendors: MongoDB, Elasticsearch
Upstarts: Pinecone, Weaviate
Open-source alternatives: Milvus, PostgreSQL

Gateway routing

Increasingly, AI systems employ models in constellations, and a gateway router is what examines a prompt to determine which model or agent is best for answering the query. Moreover, as agents undertake their work, the router can distribute the agent’s various subcalls to the fastest, cheapest, or most accurate LLM or subagent.

Watching over this stage in the pipeline requires a different set of intelligence because the questions can often involve both applicability and cost. Sometimes this layer must balance the extra cost versus the need for a better answer.

Leading vendors: Cloudflare, AWS, Google Cloud, Azure
Upstarts: OpenRouter, ModelsLab, Respan
Open-source alternatives: LangChain, Bifrost, LiteLLM

Access control

Who gets to use the model? Who is paying? Many access control tools are the same ones that were part of standard APIs or web services. Is there an API key? Is the account below its budget? The tools watch for overspending because both the customer and the boss want to make sure the money keeps flowing and no tokens are wasted.

Leading vendors: Auth0, Apigee
Upstarts: Amnic, Portfoundry
Open-source alternatives: LiteLLM, Bifrost

Compliance

Some industries have explicit compliance requirements dictated by law. Some have their own internal controls. Tools devoted to compliance are often a subset of the ones devoted to guardrails. But they’re often treated separately from guardrail tools because they’re more likely to be of interest to lawyers and that makes the stakes higher.

Leading vendors: ServiceNow, IBM
Upstarts: VerifyWise, Norm AI
Open-source alternatives: Aether, Giskard

AI models are becoming short-term tenants in long-lived enterprise data estates. Yet many organizations are remodeling the building around each new occupant.

The market keeps asking which model enterprises should trust: open or closed, domestic or foreign, one frontier provider or another. These are legitimate questions. They are also questions with a very short shelf life. Model rankings change by the month. Providers change terms, regulators redraw boundaries and capabilities that looked scarce six months ago become commodities.

In my experience, enterprise data doesn’t move at that speed. Neither do the controls, applications and business processes built around it. That mismatch is why the most important AI architecture decision for CIOs is no longer which model to choose. It is whether the enterprise can absorb continuous change without fragmenting its data estate or surrendering control.

The winners in enterprise AI will be those who build a data foundation extensible enough to accommodate it ,build a data foundation extensible enough to accommodate that ongoing change and sovereign enough to remain in control.

Extensibility is now a production requirement

During experimentation, architectural limits are easy to hide. A team can connect a new model to a copied dataset, prove a use case and call the pilot successful. Production exposes the real architecture: identity, permissions, data residency, lineage, latency, recovery and cost.

Every time those controls are rebuilt around a model, the model becomes a dependency. Adding or changing capabilities can mean moving data, recreating access policies, revalidating pipelines and reopening compliance reviews. What looked like speed at the pilot stage becomes a maze of point-to-point architecture that is difficult to extend and even harder to govern.

This isn’t a hypothetical. A Harris Poll surveying 600 CIOs found that 81% expect to rely on two or more large language model providers in 2026, and 93% say different models perform better for different use cases, requiring ongoing evaluation. More than half also noted they’ve switched providers at least once already, mostly to cut costs. This is consistent with our observations in the field: Multi-model is not a future scenario CIOs plan around. It is the operating condition they’re already managing now, whether or not the architecture underneath was built for it.

The gap between expectation and architecture is where the real cost surfaces. When a model is deeply embedded in application logic, data pipelines and prompt structures, replacing it with another provider turns into a multi-quarter engineering project rather than a simple configuration change. Teams end up paying twice, once to adopt the new model and yet again to unwind everything wired to the old one.

This helps explain why AI experimentation remains far ahead of AI value. CIO.com’s 2026 State of the CIO survey found that only 19% of respondents said their AI initiatives had met or exceeded business goals. Architecture is not the only reason, but systems optimized for the first model demo rarely become durable production systems by accident.

I recommend that CIOs add extensibility and control to the familiar measures of performance, security and cost. Can a team introduce a new model without relocating governed data? Can it change the deployment environment without rebuilding the application? Can it add a new way to query data without creating another synchronized copy? If the answer is no, the enterprise is extending its AI capability by fragmenting its control.

Put control where the durable value lives

Models are increasingly interchangeable. Enterprise context is not. The distinctive asset is the governed body of customer history, operational state, intellectual property and institutional knowledge that gives a model something useful to reason over.

That makes the data layer the durable control point. Identity, access, locality, audit and policy should be enforced as close to the data as possible, inside an environment the enterprise can operate, extend and move. The model can then be inspected, sandboxed or replaced within those boundaries.

A common pattern shows why. A team wires retrieval and access controls directly against one model’s embedding format and API to get to production faster. A year or two later, a new regulatory requirement or a stronger-performing model prompts a switch. Governance fenced around the original model will result in rebuilding access policies, revalidating pipelines and, ultimately, reproving compliance inside the new vendor’s environment. Governance enforced at the data layer, on the other hand, allows the new model to inherit the operating policies and audit trail from day one, maintaining the existing fence even as the model changes.

This does not make model provenance or security irrelevant. It makes those risks containable. Governance attached separately to every model is a collection of fences that must be rebuilt whenever the vendor changes. Governance anchored in the data layer is the property line: The tenant can change and the building can expand without changing who controls the grounds.

That is what sovereignty means in operational terms. It is not only where data is hosted but who can govern, move and extend the environment on their own terms.

Ask what the enterprise still controls

Before approving the next AI platform, CIOs should ask three questions:

1. Can this architecture absorb a new model or workload without moving governed data?
2. Which governance controls remain ours if the provider, region or deployment model changes?
3. Does adding this capability extend the foundation or create another data copy, control plane and dependency?

These questions become more urgent as agents move into production. Agents multiply quickly; they act across systems and they need the governed data the enterprise already holds. When controls are enforced where that data lives, every new agent inherits them by default. Without that foundation, each agent brings its own pipeline, permission model and place to store what it needs, and the governance burden grows with every agent added.

IBM’s Institute for Business Value surveyed 2,000 technology executives in 2026 and found that businesses building control into their AI systems deploy 16 times more AI agents than those relying on manual governance, while spending a fraction of the budget to get there. This research is consistent with what I’ve seen in the field. In our research report with MIT Technology Review, we found that 95% of enterprises are planning to establish their own AI and data platforms within the next three years, and the 13% most committed to sovereignty are already delivering 2x more agentic and generative AI applications in mainstream production.

Businesses designing for adaptability early on are more likely to keep their workloads portable and have an easier time replacing models, instead of getting locked into hard dependencies. These businesses also reported a meaningfully higher return on their AI investment. There’s a clear gap that traces back to architecture. Whichever model a business happens to select matters less than whether the foundation underneath can absorb the next one.

The next model announcement will attract the headlines. The more consequential work sits underneath it: building an extensible data foundation that can accommodate the next model, the next regulation and the next workload while keeping data under consistent enterprise control.

The smartest AI strategy is not a perfect bet on today’s model. It is a data foundation that can keep extending without ceding authority over the data it serves. The building should outlive the tenant, and no model or platform should ever hold the deed to the enterprise’s data.

For years, one of the practical constraints in software testing was time. Writing test cases takes time, preparing data takes time, regression takes time and analyzing what happened after an incident can take even more time. AI is changing this very quickly. Today, a QA engineer can generate test data, write scripts, analyze logs or create dozens of test cases in seconds. From the outside, this looks like an obvious productivity win: if we can create more tests faster, quality should improve as well.

Our experience shows that it is not that simple.

At Gurtam, we have been experimenting with AI in QA for some time. We tried different models, worked on prompts, used AI for generating test cases from documentation and eventually built our own internal assistant for this purpose. The technology is already genuinely useful, but the more we use it, the clearer one limitation becomes: generating tests is becoming easier much faster than evaluating whether those tests are actually useful.

This distinction matters, because volume and quality are not the same thing.

More test cases do not automatically mean better testing

Test generation seems like one of the most natural applications of generative AI. A task already has requirements; there is documentation and the model can use that context to produce positive scenarios, negative scenarios and boundary cases almost instantly. Recent research into LLM-based test generation reflects the same opportunity, while also showing that the quality and usefulness of generated tests remain highly dependent on context, evaluation methods and human expertise.

In practice, we often see two extremes. If there is a lot of documentation, AI can generate a  large number of cases, many of which add little value. They may look technically reasonable, but they do not necessarily improve coverage in a meaningful way. The QA engineer still has to review them, understand which cases matter and remove the rest.

The opposite happens when documentation is incomplete. In that case, the generated tests are often too superficial. They cover what is explicitly written, but they miss relationships, dependencies and risks that are obvious only if you understand the product and the surrounding system. The output can still look convincing, but that does not mean it gives enough confidence in the quality of the feature.

This is where AI exposes a familiar problem rather than eliminating it. A model can work only with the context available to it. If important product knowledge lives in people’s heads, in previous incidents or in an understanding of architecture that was never documented, the generated test cases will not magically contain that knowledge.

We built our own assistant to see how far automation could go

To make test generation more practical, we built an internal assistant. The workflow is simple: a QA engineer gives it the number of a task from our tracking system, the assistant finds the relevant documentation, combines that information with the task and generates test cases.

We also created an interface where these cases can be reviewed, edited and removed if they are unnecessary. Once the QA engineer is satisfied with the result, the final set can be sent directly to the system where we store our test cases.

This already removes a noticeable amount of repetitive work, which is useful on its own. But naturally, once you automate this much, the next question appears: can we remove the review step as well?

In theory, it sounds reasonable. A product team creates and documents a task, a developer starts working on it and the AI assistant automatically generates the test cases. By the time development is finished, everything required for testing is already prepared.

We considered such a flow. So far, though, our experience has not given us enough confidence to run it without human validation. The issue is not that AI cannot generate tests. It clearly can. The issue is that it can still produce a large number of unnecessary tests and at the same time miss something important.

That means the review stage is not simply cosmetic. It is still part of the actual quality work.

AI is already very useful when the task is clear

This does not mean I am skeptical about using AI in QA. There are many areas where I think it already works very well.

Test-data generation is an obvious example. If we need boundary values, test JSON objects or large amounts of synthetic data with different parameters, AI can prepare this much faster than a person would manually. Log analysis is another strong case. Sometimes we deal with very large volumes of logs that no engineer would realistically read line by line. AI can help identify what happened during a particular incident or at a specific point in time and narrow down the area we need to investigate.

It is also useful for generating small scripts or applications that remove repetitive work. This can include scripts for load testing, data generation, file analysis, one-off automated tests or simple interfaces for test environments.

The common pattern is that the engineer already understands what needs to be done. AI helps execute the task faster. In those scenarios, it works as a very strong assistant.

Where I would be much more careful is when we move from execution to decision-making.

The risky part is not automation itself, but giving AI the final say

I would not currently trust AI with the complete process of writing and maintaining automated tests without supervision. In our own experiments, we have seen how easily it can generate unnecessary tests while still missing important scenarios.

The same applies to complex, non-linear business logic. A model can process requirements, but understanding what is risky for the business or what behavior is acceptable in a particular context often requires more than what is written in documentation.

I would also not rely on AI alone for deciding whether a release is ready. Release quality is not simply the sum of passed test cases. You need to understand what has changed, where the risks are, what dependencies exist, what was not covered and what the possible business impact is if something goes wrong.

Data is another concern. Sensitive information disclosure is already recognized as a specific risk in LLM applications, particularly when systems process personal data, confidential business information or credentials. I would therefore be especially cautious about giving external models access to information that an organization cannot afford to expose.

For now, the simplest principle still works well: trust, but verify.

The role of QA is changing because the routine part is shrinking

If AI takes over more repetitive regression work, basic test generation or routine execution, that does not mean QA becomes less relevant. It creates time for the things teams often postpone because there is never enough capacity.

Testing architecture is one example. Risk modelling is another. There are also non-functional testing, test infrastructure, shift-left practices and involvement in business decisions before they become development problems.

This is one of the reasons I see the profession moving towards Quality Engineering. Traditional QA is often associated with checking whether the finished product behaves according to requirements. Quality Engineering is broader. It means trying to reduce the possibility of defects appearing in the first place by influencing processes, architecture and automation.

This also changes what we expect from experienced QA engineers. A technically strong tester should be able to test almost any task in the project. A strong Senior QA needs to see the project as a whole: its architecture, dependencies, risks and connection to business decisions. In a mature team, such a person becomes a link between business and development, not just the person who verifies a feature at the end.

AI makes this transition more visible because the mechanical part of the work is becoming cheaper. The value moves towards understanding what actually needs attention.

We will also have to test AI itself

There is another side to this shift. AI is not only becoming a tool for QA; it is also becoming something QA engineers will increasingly have to test.

We are already seeing more assistants, decision-making systems and AI-based product features. There are still no universally established practices for testing all of them, but I expect this to become a normal part of QA work. The direction is already visible in emerging AI assurance frameworks: NIST, for example, is developing structured approaches to test, evaluation, verification and validation of AI systems across LLMs, multimodal models and AI agents. Validating hallucinations, checking for toxicity, testing data leakage and resistance to prompt injection may soon become standard requirements in some QA roles.

This makes the idea that AI will simply remove the need for QA difficult to take seriously. The more software relies on AI, the more new quality risks appear.

AI models can make mistakes, hide errors, adjust tests to incorrect behavior or generate code with bugs. Another AI model may then fail to identify those same problems. Giving such a system full responsibility for release acceptance without human control is hard to imagine in any serious production environment today.

The important question is no longer whether AI can generate tests

It can.

The more useful question is what happens after generation. Which cases are actually valuable? Which ones are redundant? What is missing? Which risks are not visible in the documentation? And does the final set of tests give us enough confidence in the product?

AI is making the production of testing artefacts much faster. What it has not removed is the need for judgement.

For QA engineers, that means the profession is not disappearing. It is becoming more analytical, more engineering-oriented and more connected to product and business decisions.

And at least for now, the final responsibility for understanding whether the system is actually good enough still belongs to a person.

ServiceNow has launched two AI solutions that can help enterprises identify business processes ripe for automation, build the workflows to address them, and continuously improve them with AI agents.

AI Workflow Factory and Autonomous Engineer, announced on Tuesday, will bring process discovery, AI-assisted development and workflow execution into a single system that ServiceNow says can help enterprises move from individual AI projects to continuous workflow improvement.

“Instead of starting a new transformation project each time a business problem surfaces, every outcome helps reveal the next opportunity for multi-process improvement with AI,” the company said in a statement.

AI Workflow Factory connects Process Mining, Autonomous Engineer, Build Agent, and App Engine. Process Mining identifies processes that can be improved based on business metrics, while the development tools build and test workflow changes, and App Engine runs them at scale, the statement added.

ServiceNow described the approach as a “continuous workflow improvement loop,” connecting process discovery, development, and deployment. It said the model allows an enterprise to use the results of one improvement to identify the next opportunity rather than launching a separate project each time.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the approach addresses the coordination required to turn a process problem into a deployed improvement, but does not remove the need to address the underlying business process.

“Data and integration remain its connective tissue. Faster building still leaves ownership and process redesign unresolved unless the enterprise addresses them explicitly,” Gogia said.

Measuring the payoff

ServiceNow said AI Workflow Factory can be used for specific business outcomes. It cited a case-deflection example in which Process Mining identifies where cases can be deflected, after which AI agents can build and deploy workflows across business units and continue refining them against the target outcome.

The company said people would continue to set the direction and approve outcomes while AI takes on more of the work involved in building and operating workflows.

Gogia said CIOs should evaluate the business benefit alongside the ongoing cost of running the resulting automation.

“Process owners have reason to feel relief when repetitive implementation becomes easier, but the benefit depends on accepting and maintaining what is built,” he said. “CIOs should measure the business outcome alongside recurring platform costs.”

Gogia also said enterprises should account for workflow retirement when calculating the value of automation. The test, he said, is whether savings continue after a workflow enters production.

Autonomy needs boundaries

Autonomous Engineer addresses the development work required to turn requirements into applications and workflows. ServiceNow said it supports “unattended coding for autonomous planning, building, and testing of implementation work” while allowing developers to retain control over critical decisions.

The capability can create an implementation plan and, following human approval, carry out development and testing work, according to ServiceNow.

Gogia said enterprises should determine how much work can be delegated based on the nature of the task rather than setting a universal target for autonomous development.

“Delegation should follow task clarity and reversibility, with independent validation before release,” he said. “No universal percentage describes how much enterprise development can safely be delegated.”

He also cautioned against relying entirely on AI-generated testing when implementation and its tests are based on the same interpretation of a requirement.

“An engineering leader’s caution is justified when implementation and generated tests share the same reading of a requirement,” Gogia said.

ServiceNow said its process includes approval of the implementation plan and human validation of completed work. Gogia said scoped permissions and bounded environments can limit an agent’s potential impact, while tested revocation and recovery can help enterprises control its authority.

“Production responsibility must remain explicit even when implementation is unattended,” he said.

Governance brings a new question

ServiceNow is also making governance part of the workflow model. It said its AI Control Tower provides centralized oversight of AI workflows, decisions, and agent actions running through AI Workflow Factory. Its Action Fabric capability extends that model to third-party AI agents and tools.

It said the approach gives enterprises “one governed view for the enterprise” while allowing them to use other AI development tools and third-party agents.

Gogia noted that enterprises need coordinated governance across agents, with authority defined for each system. He said ServiceNow has a role because its workflows connect business decisions to actions, but cautioned that interoperability does not necessarily mean equivalent governance or enforcement.

“Policies and audit evidence create platform gravity,” Gogia said. “Open protocols help systems communicate, but do not establish equivalent enforcement or portable enterprise controls.”

For CIOs, that makes the ability to revoke agent authority and recover from a control-plane failure an important consideration, he pointed out.

“An enterprise should be able to replace its governance platform without losing the evidence of how it governed,” Gogia said.

AI Workflow Factory is globally available, while Autonomous Engineer is available through an early-access program on request, the statement added.

Sumit Johar has been modernizing BlackLine’s IT environment since becoming CIO of the software company in early 2024.

As a longtime IT leader, Johar has plenty of experience overhauling tech stacks, but he says the work has taken on new meaning — and urgency — in the AI era.

“The definition of modernization has literally switched in the last two to three years,” he says. “Suddenly everything that you built in the last few years looks like legacy, because the SaaS model, which we have been using for the last 10 to 15 years, there is an opportunity now to totally change that and modernize with AI and for AI.”

Johar is doing just that, surveying the company’s SaaS portfolio, particularly zeroing in on point solutions, asking whether each is worth the cost, whether it delivers true business value, or whether IT can use AI to build a service better suited to his company’s needs.

At the same time, AI is changing how workers interact with technology, he says, enabling people to query applications via natural language and chat, which has his IT team considering which applications may need to be modernized or abandoned altogether as a result.

Take, for example, dashboards. “We built dashboards because there was no other or better way to report on your data,” he says. “Now I can simply ask a question and get an answer, which is what I was interested in anyways. So if I have my ERP and CRM talk to me in a human language, I’m happy with that. That’s modernization.”

As a result, he adds, “some of us might be getting rid of [our dashboards], and some might be slowly reducing the dashboarding tools we have.”

As organizations remake and automate workflows with AI, software that enables those workflows could meet a similar fate, Johar says.

Even chatbot-building products that IT implemented a few years ago are prime targets for rationalization due to AI advances, he adds. “I still need chatbots, but I don’t think I need specialized software to build a chatbot anymore. Any generic AI platform that I have will give me the ability to basically build them,” he explains.

High-priority tasks

For Johar, the longstanding CIO tasks of modernization and rationalization remain make-or-break activities for IT.

Johar and other IT leaders see modernization and rationalization as vital to controlling IT spend — as high of a priority for CIOs as it’s ever been, freeing up dollars for innovation (the No. 1 objective for nearly every IT leader and their CEO’s top priority).

IT leaders also see modernization helping them create a future-ready IT environment, one that’s not encumbered by legacy technologies and complexities that don’t play nice with emerging technologies.

“CIOs don’t have much of a choice than to continue modernization; they’re in a perpetual state of modernization,” says Amar Aswatha, senior vice president for global business engineering at CGI, a consulting and services firm. “They’re trying to simplify yesterday’s tech state while creating resilience and the right environment for AI and to be ready for whatever will emerge.”

Other factors also drive the need for ongoing modernization, Aswatha notes. The rapid pace of innovation is reducing the shelf life of many technologies more quickly, necessitating more rapid overhaul cycles than in the past. Meanwhile, the past decade’s mass migration to the cloud has meant that CIOs “traded server sprawl for subscription sprawl,” he says. The rush to adopt AI is having a similar effect, leading to AI and agent sprawl — and the need for new and more widespread rationalization and modernization strategies.

Still, CIOs must be more surgical than they’ve been in the past, using a scalpel not an ax to shed legacy technology and simplify IT environments, Aswatha advises.

That means accounting for both current and emerging business needs when determining what systems should be modernized — not simply relying on age or other such non-business-related factors. And IT leaders can’t see rationalization as an exercise in reducing application count to a set number; unnecessary complexity should instead be the target.

Such approaches require CIOs and their teams to understand current and future business needs, as well as how those needs, and the organization’s overarching strategy, shift over time, Aswatha says.

“CIOs have to watch for business signals on when and what to modernize and rationalize. It’s not about spring cleaning, it’s about what apps are slowing the business down,” he advises.

‘Best for the organization’

Rachelle Putnam, vice president and CIO of General Dynamics Land Systems, which manufactures military vehicles, is taking such an approach.

Putnam, who has led IT at the company since 2014 and managed a move off a mainframe about a decade ago, says modernization today means asking whether existing technology “allows us to have the flexibility and the functionality we need.”

Like many CIOs not on IT’s bleeding edge, for Putnam savvy modernization is about strategy, not technology. “Some might say we’re not on a modern tool set, but that doesn’t mean we don’t have the functionality we need,” she says.

For example, Putnam embraces a cloud-smart strategy, modernizing on the cloud where it makes sense and on-prem when that’s the better or required option based on government regulations.

She applies a similar lens to rationalization, asking whether any given application uniquely fulfills a business need or whether other apps in the portfolio can do the job. Such questioning helped her standardize the company on two CAD tools, down from 10, and standardize on one reporting tool instead of using three.

Putnam is also increasingly asking whether she even needs a vendor solution.

“With tools like Claude Code, when we look at [vendor-offered] apps, we ask if we even need them or whether we can create our own and not pay for maintenance,” she says. “Sometimes we want SaaS, where we want those updates, but there are others that we don’t need updates and won’t need to change the application much, so those are the ones we’re going to look at creating ourselves.”

Like other CIOs, Putnam believes modernization produces benefits for IT and the company as a whole, ensuring the organization not only has the technology necessary to perform but also a standardized data environment so that “everyone is looking at the same data, and it means the same thing,” she says.

In addition to cutting IT maintenance and management costs, modernization also reduces risks, by eliminating unsupported legacy tech and difficult-to-manage complexity.

And it makes IT talent more effective and efficient, by eliminating the need for outdated skills, which are typically hard to find and thus come at a premium. With rationalization, IT teams no longer must learn multiple vendor solutions or assign different workers to different solutions.

Modernization challenges

Of course, Putnam and other IT leaders acknowledge there are challenges to modernization and rationalization, too.

“Cost is certainly one. Sometimes it costs more to get off one than continuing to run multiples,” Putnam says.

Even in such cases, however, hard-to-quantify benefits make the move worth it, she adds. For example, rationalizing to one common system used throughout the company’s multiple geographic locations means workers anywhere can easily be assigned to help when one region faces a surge in work.

Data migration is another common challenge. But data issues can usually be overcome with “creativity, mostly, and having someone dig down to really get it done,” Putnam says. Sometimes it may mean shelving the data and only retrieving it if necessary.

Then there’s the challenge of limiting future rationalization by controlling what gets added to the IT environment today. To that end, deploying and using a common tool is the default standard now at General Dynamics Land Systems.

“That’s a rule that everyone abides by,” Putnam says, acknowledging some pushback. “Sometimes people will argue for that extra 15% that one tool might have that the existing tool doesn’t have. But we stress that standardization is best for the organization as a whole.”

A staple of CIO work

Krishna Prasad, CIO of UST, a digital transformation and IT services provider, similarly sees modernization through a business — not a technology — lens today.

Whereas modernization was once triggered by advancements that made existing tech outdated, obsolete, or no longer supported by the vendor, now modernization is triggered when business advancements render a deployed technology deficient, he says.

This new scenario has CIOs, including himself, modernizing faster than in past eras, Prasad says. And it’s why modernization remains a core component of the CIO role.

“Modernization means meeting today’s business needs, and that may mean we need to deploy a new version of [a technology] to get a better experience, speed, agility, or in a way that we can provide transparency,” he adds. “So, at UST we have always thought about modernization as a continuous process.”

For example, Prasad is currently modernizing the company’s CRM platform, even though the existing one would not be considered legacy tech using a traditional definition. Yet the deployed CRM wasn’t providing the capabilities UST needed for its sales department to deliver on the company’s vision.

“We weren’t having a good user experience, and sellers weren’t updating the information as they should, so we didn’t have real-time data and then the operations team had to do the data entry, so you had cost there, too, and we had reduced agility as a result,” Prasad explains.

Similar factors are at play when it comes to rationalization, which he believes should also be an ongoing concern for CIOs.

Despite the benefits these efforts bring, Prasad acknowledges the heavy lifts involved, ones that many organizations aren’t yet prepared to undertake. For example, UST still has a financial system running on premises, and because the complexity of “disentangling the financial systems from the guts of the business is challenging, it’s a change that the business isn’t willing to make right now,” he admits.

Such situations ensure modernization projects will remain a core IT task in the years ahead.

See also:

• 6 strategies for accelerating IT modernization
• 8 IT modernization traps CIOs must avoid
• Massive modernization: Tips for overhauling IT at scale

Clients ask me this question perhaps more than any other. They’ve usually just come off a bad experience, either analytics stuck in IT’s backlog for months or analytics scattered across the business without anyone accountable for what it all means. My answer is always the same. Split it. IT owns the data engineering. The business owns the analytics. And you need one small team sitting between them to keep the whole thing from drifting apart.

That’s not a compromise position I land on to avoid picking a side. I’ve witnessed companies that went all in on one extreme or the other, and they end up in the same place. They have expensive dashboards sitting untouched and analysts who stopped trusting the numbers years ago. Give me twenty minutes with a client and I can usually tell which extreme they started from, just by looking at what’s broken.

Full centralization and full decentralization both fail the same way

When IT owns everything, security and governance are usually solid. You need people who actually understand networking and access control managing any connection to raw data coming out of your ERPs, TMS and CRM systems, not analysts who picked up security practices on the side.

But speed dies. Business analysts wait on intake forms and requirements documents that assume you can specify a dashboard’s full scope before you’ve ever seen the data move. Analytics doesn’t work that way. It’s one of those areas where you need multiple iterations to land on the right end state. You learn what you need by building something rough, using it for two weeks and rebuilding half of it. A team that has to file a ticket for every iteration will never keep pace with a business that changes its questions weekly. People who sit close to the business need the freedom to iterate as the tools mature, and that freedom disappears the moment every change has to clear an IT queue.

Flip it and hand analytics entirely to the business, and you get the opposite failure. I worked with a company this year that let every department build its own reports with no shared standards or governing body. Marketing had one set of definitions for a “customer.” Sales had another. Finance had a third, and every meeting turned into an argument about whose number was right. Total spend wasn’t being tracked either. As you can imagine, by the time they called me, their cloud analytics costs on Microsoft Fabric had already climbed past $20,000 a month, and the team couldn’t point to where it was going. They fixed it by building a small internal group, essentially a center of excellence, that owned the standards everyone else built on top of. CIO contributor Ranko Cosic’s April 2026 piece, “How analytics and AI are reshaping the boundaries of IT leadership,” draws a similar line, arguing that IT leadership builds the capability to analyze while analytics leadership builds the capability to decide. I’d add a third piece. Someone has to own the handoff between those two, or you get exactly the sprawl I saw at that client.

There are numbers behind this. In a survey of more than 2,400 CIOs, Gartner found that companies where IT and business leaders co-own delivery, what Gartner calls the “franchise” model, hit or beat their targets on 63% of digital initiatives. Companies where IT keeps sole ownership hit that mark on just 43% of initiatives. Only 12% of CIOs run a true franchise model today. That’s the whole argument in one number.

Adoption breaks when builders and users are different people

A few years ago, I got called into a large manufacturing company that had spent three years and an entire IT department building a dashboard platform meant for the whole organization. When I looked at usage, six people were opening those dashboards regularly. Six, out of thousands of employees. The tools worked fine technically. What broke was trust, and it’s a classic mistake. Trust and adoption begin when end users are part of the design process, or better yet, when they’re the ones building the tools.

That number stung, but it isn’t unusual. A BARC and Eckerson Group survey of 214 data and analytics leaders found average active adoption of BI tools sitting around 25%, a figure that had barely moved in seven years of tracking. Those companies bought good tools, but the adoption model wasn’t built to match. They skipped giving the people who’d use those reports a role in building them. Adoption climbs when the people using a report have a hand in shaping it, or better yet, built it themselves. That manufacturing client shifted from a fully centralized build to a decentralized one, with IT still owning the underlying data and business teams, together with us as consultants, owning what got built on top of it. They now have roughly 80% of employees using the tools weekly, on the same data, at the same company, with nothing changed but who owned the build.

I bring this up with every client who tells me they want “one IT team” running analytics end to end. A single team can own the pipeline. It can’t own every department’s judgment about what a useful report looks like, and trying to force that usually produces the same six-user outcome I saw at that manufacturer.

Standardization is the toll you pay for scale

There’s a fifth benefit to this structure that I didn’t lead with, but it’s the one that surprises clients most. It’s that alignment gets easier, not harder. Any organization of real size has a hundred project requests, a thousand small enhancements and a never-ending list of technical debt sitting somewhere. When all of that runs through one intake, owned by the seam team instead of scattered across five departments, prioritization stops being a fight and starts being a conversation. Time and time again, I’ve watched people set aside what’s good for their own team once they can actually see the whole list, the whole picture of what needs doing across the business. That only happens with one line of work to look at, not five competing ones.

This doesn’t come free. Splitting ownership this way comes with costs, and I tell clients about all three before they commit to the model.

First, the ramp-up is slow. If your organization has been running fully centralized or fully decentralized, the first few months of a split model will feel like you’re moving backward. You’re building shared data models from a standing start. You’re writing templates nobody has tested yet. None of it pays off immediately, and it takes longer than anyone wants to admit before the shared foundation starts paying for itself.

Second, coordination gets harder. Running one IT team that reports up a single chain is simpler than coordinating a business analytics team and an IT team that each report somewhere else and only share a dotted line into governance. You’ll spend real time in rooms aligning people who don’t share a manager.

Third, standardization itself is a hard sell early on. People resist naming conventions and data model rules when they can’t yet see why those rules matter. I’ve sat through those meetings. It usually takes a few months before teams start seeing the payoff in shared resources and consistent numbers across departments, and until then you’re asking people to trust a process they can’t yet see the benefit of.

I still think the tradeoff is worth it. The alternative is a business that’s either too slow to answer its own questions or too scattered to trust the answers it gets. Every client I’ve seen commit to the split — security in IT, agility and ownership in the business, a small governing layer holding the seam together — has come out the other side with something that actually gets used. The ones that skip the governing layer end up back in my inbox a year later, describing the exact same $20,000-a-month problem with different numbers attached.

So, when a client asks me where analytics should sit, I don’t tell them to pick a side. Instead, I tell them to build the seam. Put someone in charge who speaks both languages, IT and the business, and give that person say over the standards. If you skip that part, you end up back where you started. Get it right, and it’s the difference between six people opening a dashboard and eighty percent of the company doing it every week.

ServiceNow has a new take on the service desk: Flow by ServiceNow, a standalone AI product that allows users to get help via chats in Microsoft Teams, Slack, or a Flow web app, or by email, rather than having to leave what they’re doing to open a helpdesk ticket.

Flow can be up and running within a day, no implementation project or infrastructure required, the company said. The product can stand alone or plug into the ServiceNow platform for customers who need enterprise scale, governance, and cross-functional workflows, it said.

It’s a smart move, said Frank Dickson, principal analyst at Dickson Research. “The pitch is what Flow does not require. ServiceNow claims Flow can be running in a day with no implementation project, no CMDB migration, and no infrastructure. Every item on that list is something its flagship ITSM platform does require. ServiceNow is selling the absence of its own complexity,” he said.

Flow will connect to more than 100 systems through pre-built connectors. If the AI can’t surface the information it needs to fulfill a request from available data sources, Flow will escalate the issue to a human. Frequent requests, such as those for password resets, can easily be automated by IT, ServiceNow said.

Cost of consumption

Customers don’t need an existing ServiceNow implementation to use Flow; as soon as it goes live, it can handle user requests. Pricing will be consumption-based.

ServiceNow customers who subscribe to its AI services will also be able to deploy Flow with no additional licensing costs; they will just pay for consumption via assists from their existing pool.

The product is currently available at no charge during what ServiceNow refers to as Controlled Availability. Organizations seeking early access can sign up on the Flow website.

Flow is now available to current ServiceNow customers in North America, and the company plans to make it generally available in North America and EMEA by year-end. Wider availability will follow in the first quarter of 2027, a company representative said.

Melody Brue, principal analyst at Moor Insights & Strategy, said that Flow is a logical next step for ServiceNow. “The company built its business around digitizing work that historically moved through tickets, forms, portals, and manual handoffs,” she noted. “The AI opportunity is to make that same operational depth easier to access through conversation and, increasingly, voice.”

Headless trade-off

Dickson said Flow rides a larger trend toward headless software, in which the engine runs in the background and uses someone else’s user interface, in this case Slack or Teams. But it’s a trade-off: “ServiceNow describes its platform as a single pane of glass. With Flow, it hands the glass to someone else. Whoever owns the interface owns the daily habit, and in headless software, the habit may become the relationship.”

That said, Brue saw Flow as a good fit for today’s market. “Customers want AI with a clear use case, quick time to value, and proof that it can do more than generate answers,” she said. “They want it to resolve real work. A standalone product also gives ServiceNow a lower-friction place to land (with the goal of expanding), reaching customers that may not be ready or have time for a full platform rollout.”

But, she said, while many vendors offer AI assistants, “the real test is whether this can reliably complete work across systems, with the right permissions, approvals, and human handoffs. ServiceNow has a credible foundation in workflow and service operations. The question is whether it can make that enterprise depth simple and fast enough to deploy for the product-led AI market it is targeting.”

With the current fierce competition to capture “the front door of work,” she said, “ServiceNow’s opportunity is to differentiate not just on the conversational experience, but on its ability to carry a request through governed workflow, approval, and fulfillment across systems.”

Many IT leaders still struggle to find ROI when deploying AI agents at scale, but a few IT sweet spots are emerging as use cases that can provide CIOs tangible cost relief.

Rhonda Baldwin, CIO at LaunchDarkly, says coding agents and service desk agents are helping the SaaS provider cut IT costs.

“Coding agents increase engineering capacity without requiring a proportional increase in headcount,” she says. “They also help us optimize cloud costs and reduce workflow consumption costs.”

In addition to coding and cloud cost optimization, IT leaders see tier 1 and 2 IT support as another promising area for agents to free up IT budget, although many have just begun to track savings from AI agents, and those that do use several different metrics.

For Baldwin that includes cost avoidance, as coding agents have helped the company build internal tools rather than buying additional software, she notes.

Here, the savings have been substantial, she says, with the company foregoing about $1 million in spending on two optimization projects and another $120,000 by building its own enterprise asset-management solution with AI coding tools.

In addition, LaunchDarkly has saved about $50,000 in annualized savings by using agentic AI for tier 1 IT support. “This not only boosts employee productivity but also helps us avoid costs related to software, implementation, asset management, and having remote service technicians,” she says.

IT support and self-service resolution

IT support is a strong use case for IT leaders looking for agent cost savings, says Gil Pekelman, CEO of AI agent provider Atera, whose company recently released a joint study with Forrester claiming significant ROI for its IT incident support agent.

“The calculation is very straightforward,” he notes. “We have a company that has 10,000 employees, and all IT support is offshored. If they’re going to close that down now, they can immediately measure the savings there.”

Kevin Rooney, CIO at West Monroe Partners, reports significant savings for the digital consultancy through just such a deployment.

Now, employees can an internal IT and HR support agent in Teams or Slack to get answers to common questions, request software access, reset passwords, unlock accounts, submit and update tickets, or connect with a live support professional when needed, he says.

“By handling high-volume, repeatable requests and improving ticket intake and routing, it helps our IT team spend more time on complex issues and higher-value work,” Rooney adds.

West Monroe is evaluating the impact of the agent in terms of self-service resolution, ticket volume, response time, and capacity savings, but it has driven a 40% reduction in yearly managed service provider costs, he says. The bot has also led to an estimated operational time savings of 2,700 hours per year, he adds.

Cost savings in the cloud

Matthew Wallace, co-founder and CTO of KamiwazaAI, has also found major IT savings from agentic AI. The Ai orchestration platform provider uses agents in several areas, including software engineering, project management, data science, and systems engineering.

Cloud optimization is another area where the company is saving money by using agents, he adds.

“We have a set of agents that monitor new systems in the cloud, coordinate with those turning them up, and coordinate budget approvals, with an easy way to shut down unauthorized spend and log it,” he says.

That agentic system has replaced a function that required a high amount of human coordination and attention, he notes

“You have to check and understand who set it up, when, what the cost is, whether it has internal approval, and various details about resource sizing, placement, etc.,” he explains. “Later, you have to check whether someone has responded with information and whether anyone in management has offered an approval or rejection.”

The first round of cloud optimization agents that Wallace’s team deployed cut cloud spending by 70% immediately, he says.

Check the numbers

However, Jeet Pattanaik, founder and CTO of AI-base solutions provider Glokal AI, says some organizations are inflating their IT savings from agentic AI because they’re not measuring all the costs.

While he believes some IT leaders are finding real savings, they’re often smaller and slower than advertised, he says, noting that in reality most organizations are still hunting for ROI.

“The pilot always looks great because it runs on the easy tickets,” Pattanaik says. “Then, production brings in all the odd cases, and somebody has to check what the agent actually did. That checking is what quietly eats the savings, and it almost never shows up in the business case.”

He sees tier 1 support — password resets, access requests, answering questions already in the documentation — as the place where organizations are saving IT budget using agents.

“The sweet spot is work that’s high volume, well documented, and cheap to undo if the agent gets it wrong,” he says. “Tier 1 fits that nicely. Tier 2 only partly. Anything that changes someone’s permissions or touches production systems isn’t ready yet, because one bad action there can cost more than a thousand good ones save.”

IT leaders deploying agents for IT support should keep an eye on how often tickets get reopened, Pattanaik adds. “A ticket the agent closed isn’t always a problem solved,” he says. “If people keep coming back with the same issue, you didn’t save anything, you just pushed it down the road.”

He gives this example: A service desk handles 10,000 tier-1 tickets a month at about €15 each. The agent closes 40% of them, which, on paper, saves €60,000 a month. But if 15% of those come back reopened, that’s €9,000 of work returning to humans. Add around €15,000 for people checking what the agent did, and the real cost reduction is closer to €36,000, about 60% of what the pilot promised.

There’s also a cost to eliminating workers focused on tier 1 support, he adds. “One cost nobody seems to count: Tier 1 is where people learn the job,” he says. “Automate all of it, and you lose the path that turns juniors into your future senior engineers.”

Alternative clouds have emerged amid major cloud providers such as AWS, Google Cloud, and Microsoft Azure, and often specialize in niche areas like AI-native computing, and sovereign and edge deployments, while professing to provide cost reductions and best-of-breed performance.

“Many organizations are rebalancing away from all-in hyperscaler strategies to avoid lock-in and concentration risk,” says Kyle Campos, CTPO at CloudBolt, a cloud management platform. “At the same time, alternative clouds are often purpose-built for specific advantages.” To him, benefits include lower-cost object storage at scale, better edge performance for latency-sensitive apps, and faster access to dedicated GPUs for AI workloads. Data sovereignty is also pushing adoption of localized providers.

But as alternative clouds, also called neoclouds, make headlines and amass considerable funding rounds, their use in enterprise environments remains relatively nascent. While enterprise executives see the potential in using alternative clouds, especially for GPU workloads, many are skeptical, taking a balanced approach to assessing maturity, costs, and whether it’s worth sacrificing continuity with existing clouds.

Smartsheet CIO and CISO Ravi Soin is one of these executives taking a measured approach. “We’ll grow our use of alternative clouds, but within a clearly defined perimeter,” he says. “That discipline is what separates considered adoption from sprawl.” For Soin, many neoclouds still fail early in the evaluation process, especially for regulated workloads where a mature compliance posture is non-negotiable.

In order to fully evaluate alternative clouds, the platforms must be treated with the same vigilance as any other IT acquisition. “This remains consistent across any tech stack: fit, form, and function,” says Nigel Gibbons, director and senior advisor at the NCC Group, a cybersecurity consulting firm. “This means alignment of the cloud to workload performance, security, and sovereignty needs.”

Overall, CIOs aren’t rushing into alternative clouds. It’ll take a serious proof spanning regulatory impact, auditability, resilience, and total cost planning in order to convince large organizations to migrate away from well-established cloud infrastructure. More realistically, such clouds will be evaluated on a per-workload basis.

Compliance and transparency

When evaluating neoclouds, compliance is top of mind for enterprise executives. “Compliance posture such as SOC 2, ISO 27001, and sovereign-specific certifications like FedRAMP or IRAP is the first filter and, for most neoclouds, an early exit,” says Soin.

Smartsheet runs AI on enterprise customer data and therefore requires strict compliance and sovereignty frameworks. “That defines a hard boundary where regulated workloads stay with certified providers,” he adds. “Workload identity doesn’t federate natively across clouds, so every trust relationship must be hand-built and audited. For a platform where data sensitivity varies enormously, that governance gap isn’t theoretical.”

Gibbons adds that trust validation is becoming a pressing requirement from regulators and the overall market. “The uncomfortable truth is that most organizations have operated on deferred risk captured in registers, softened in board narratives, and tolerated due to limited visibility,” he says. The pattern of tumultuous changes in the AI market, he adds, is encouraging more of a resilience mindset among technical executives assessing new technologies.

Operational transparency is another pressing area to evaluate. For Soin, the infrastructure that supports AI workloads requires granular auditability. “Can the provider give you end-to-end observability across the inference layer: tamper-evident logs, model versioning, the ability to trace what happened to customer data from input to output?” he asks.

Smartsheet’s enterprise customers also ask how AI is applied to their data and what controls exist, and that answer has to be defensible. “A neocloud that can’t support it isn’t just an operations risk, it’s a risk to the customer trust our business is built on,” he says.

Per-workload evaluation

Although neoclouds are often framed as a replacement to hyperscalers, they’re more often complementary infrastructure, purpose-built for individual use cases. “A neocloud isn’t a type of cloud, but more a design principle,” says Gibbons. “We can think of it as infrastructure optimized for a specific workload, trust model or control requirement, rather than general-purpose scale.”

Their usage hinges on the project at hand, which typically involves AI/ML projects. “We work with a mix of alternative providers depending on workload fit,” says CloudBolt’s Campos. “We’ve used alternative cloud providers for VMware as part of a cloud migration strategy.” Their customers use alternative clouds for object storage, edge and low-latency needs, AI/ML GPU capacity, and legacy virtualization workloads that don’t map cleanly to hyperscaler-native services.

Executives must determine which environment makes sense for the workload at hand, and act accordingly. “CIOs should begin by clarifying the specific workload opportunity an alternative cloud is meant to accelerate, then evaluate providers against developer and operator experience inclusive of ability to scale with business need,” adds Campos. “From there, the priorities are whether the platform can be governed and operated alongside existing clouds, with strong visibility into usage and unit economics. Security, compliance posture, and credible SLAs for reliability and performance should be evaluated at the same bar as hyperscalers. The goal is to add flexibility without creating a new operational silo.”

Not all workloads are a fit for neoclouds or alternative providers, however. While these platforms benefit numerous workload-specific options, they’re not viewed as wholesale replacements for hyperscalers. For general-purpose enterprise functions, hyperscalers may still retain advantages around integrated services, discounts, operational maturity, and the availability of relevant job skills.

For this reason, many technology leaders are still in an exploratory phase. “Our infrastructure today runs on hyperscalers, and that’s been the right choice for where we’ve been,” says Smit Shanker, global CIO of Xebia, a global IT consulting and software engineering company. Still, he encourages CIOs to begin actively evaluating alternatives. “We’re now in that evaluation phase, looking at where specialized providers, sovereign options, or hybrid approaches make more sense for specific workloads.”

Shared responsibility model

CIOs require a high-degree of enterprise-grade trust that must be codified beyond empty promises and proven under real-world stress tests. As such, before diving headfirst into a newfangled cloud, Smartsheet’s Soin advocates verifying its shared responsibility model, which stipulates commitments the cloud provider has to uphold, and where responsibility lies with consumers.

For Soin, it’s especially critical to understand how a cloud provider acts when incidents occur. “Request post-incident reviews before signing anything, not templated RCAs but the real communication timeline,” he says. “Shared responsibility models are well-documented until they’re tested. Find out what happened the last time they were tested.”

Ultimately, alternative clouds need to meet the same enterprise maturity bar as established cloud providers. “Assurances must include auditability, compliance, resilience, transparent SLAs, interoperability, portability, and independently validated trust, not vendor assertions,” says NCC Group’s Gibbons.

Total cost analysis

Understanding the economic impact is necessary to determine whether an alternative cloud is worth it for the business. This is an area where alternative clouds shouldshine, with reports estimating savings of up to 70% compared with hyperscaler GPU instances. Traditional cloud computing pricing models are often opaque, and charges related to add-ons, upsells, and hidden fees around egress and ingress are notoriously known to surprise cloud computing consumers.

For certain workload categories, the economics can favor alternative clouds. “Traditional cloud providers often impose substantial data egress fees that inflate the total cost of ownership for data-heavy architectures,” says Dave McCarthy, VP of cloud and infrastructure services at global market intelligence and advisory firm IDC. “Alternative providers frequently minimize or eliminate these bandwidth penalties entirely, offering a more transparent cost structure,” he says.

Still, a full cost audit is necessary before going all-in on an alternative cloud. “What I’d recommend to anyone is do the full-cost model before you commit,” says Shanker. He suggests conducting a comprehensive analysis of cloud compute, inference, API volumes, and maintenance costs for things like infrastructure upgrades projected against the actual demand curve. When viewed together, he says, they create compounding costs that most C-suites haven’t modeled.

“Most enterprises are still modeling cloud economics on implementation costs alone, and that’s incomplete,” he adds. “The organizations getting AI right are the ones treating infrastructure economics as a first-class design decision, not a footnote.”

As cloud infrastructure choices can produce vendor lock-in, CIOs should use all the criteria at their disposal to plan and inform a neutral decision-making process. “Whatever path you choose — hyperscaler, alternative, sovereign, or some combination — the discipline that matters is vendor-agnostic, framework-led design,” adds Shanker. “Don’t let infrastructure choices constrain what’s possible.”

Where the market is heading

Neoclouds have made a mark for themselves by offering direct access to latest-generation hardware, which is important for AI-focused workloads requiring high performance. There’s also the argument that opting for alternative clouds aids a distributed multi-cloud strategy, which can benefit resilience and meet certain regional sovereign cloud mandates.

Nearly 90% of IT leaders say an organization should never commit to one cloud provider for their entire architecture, according to a HostingAdvice survey from last year. The same study found 73% of leaders use two or more alternative cloud providers, underscoring a clear interest in alternative clouds.

Still, while some industry reports are favorable, enterprise executives express more of a cautious reality of selective evaluation, not wholesale migration. For Soin, a top concern is the compliance posture and observability capabilities for alternative clouds, especially when hosting workloads that run AI inference. “The question isn’t just where inference happens but whether we can see what happened, explain it, and stand behind it,” he says. “That obligation shapes which providers are even in the conversation.”

While state-of-the-art cheap GPU compute is alluring, CIOs should keep an eye on the full governance picture when evaluating alternative clouds. “The neoclouds that earn more of our workload won’t just be the ones with the best GPUs,” says Soin. “They’ll be the ones that have seriously invested in model governance infrastructure and can demonstrate it. That’s a higher bar than most currently clear, but it’s where the market needs to go.”

A focus on inference

IDC forecasts that by next year, the computational demands of AI will force 80% of organizations to modernize legacy cloud environments by switching to platforms designed for AI workloads, with half of this being processed locally on endpoints or edge nodes by 2030.

“Enterprises are increasingly looking beyond major hyperscalers to avoid vendor lock-in and optimize specialized workloads,” says IDC’s McCarthy. “Rather than relying on a single, centralized infrastructure, organizations are adopting these alternatives into a broader portfolio.”

Much of this new computing paradigm will center on inference, or the post-training execution of AI models in production, using live customer or enterprise data. As inference moves into more business-critical workflows, decisions about where those workloads run, and what criteria guide those decisions, will have long-term implications.

Alt and neo clouds will likely have their place in inference, as well as in future sovereign and decentralized cloud models, and it’s not a decision CIOs should take lightly or without an informed evaluation framework. “Where workloads run becomes one of the most consequential decisions a leader makes,” says Shanker.