Agentic AI and Enterprise Software in 2026

State of the models and agent evolution

Michael Krigsman: A Goldman Sachs study that came out, enterprises are blowing through their token budgets at a year's worth of AI budget in 3 months. This is the notion of token maxing, which is as many tokens as you provide will get consumed as quickly as possible. Praveen Akkiraju of Insight Partners invests across the agentic AI stack. Praveen, what is the state of agent technology today?

Praveen Akkriraju: So if you take a step back and look at the evolution of just the models, the end of 2024 was one of the most seminal moments in the evolution of models. It was when the 4.0 model came out, which essentially introduced the concept of reasoning. And I think that was the first step towards truly making AI less of a chatbot and more of an agent. So from there we saw the introduction of DeepSeek in sort of early or late '24, early '25, and that fundamentally changed the economics of large language models.

And later part of last year was when we started to see the true sort of agentic capabilities in the model start to emerge. Coding became a huge use case and all of a sudden we started to now realize, wow, you could actually use models to fundamentally write code. And beginning of this year I think was sort of the real inflection point, both in terms of the capability that came forward from coding perspective, but also the ability for open source frameworks like OpenClaw to be able to use models to actually show us that work can be done, not just technical work like coding, but also just basic work.

So you see that arc of models and the evolution of these things, the pace has been dizzying, towards unlocking the true capability of these large language models to actually do work for us.

How models combine with harnesses

Michael Krigsman: So what is the state of AI agents today?

Praveen Akkriraju: Think about what agents is and agency is. Which is essentially the notion of being able to take a task, understand the context of the task, break it down into a plan, and then be able to use a set of tools to execute the task. That's essentially what the definition of agents and agency is. Now, the core of these agents is the large language models that we've talked about, the evolution of these things.

But fundamentally, you think of large language models as these kind of stateless machines. In the sense that they absorb all the information you give them, it's a compression algorithm. They essentially take all the world's information, compress them into weights. And are able to sort of reproduce that, or respond to prompts based on those compressed weights. Now, the issue here is that because they're stateless, they don't remember, or like humans do when we do tasks, the context of what the work that has been done before.

So the real sort of evolution of agents has been the combination of these really powerful large language models with these kind of things we call harnesses. And so a harness essentially is a set of tools, it's context, it's memory that is given to the model in order for it to perform a particular task. So we can think of these harnesses in the context of applications. So an application such as Claude Code. Has a very well-defined harness that gives it the appropriate tools, the memory, the kind of guardrails, if you will, in terms of coding practices and such like, that allow it to then deliver code.

So combine the model with the harness, give it a set of tools, and that's how you do work. And more recently, I think you started to see applications beyond coding. A ChatGPT in and of itself is an application, and OpenClaw essentially is a personal agent which created its own model. Its own, sorry, its own harness that attached to the model. And so what you can think of these as if large language models are stateless, powerful AI engines, you combine that with harnesses to give it sort of things such as in-context learning, so you can actually do work, remember, the context of work you're doing in a long horizon and actually execute tasks.

Jagged intelligence and the hype gap

Michael Krigsman: We have all of this opportunity, and there's been evolution among the tools, and we all see the promise, or at least we're told there's all of this promise out there. So what's real versus what is the hype in agentic AI right now? Can you help sort that out?

Praveen Akkriraju: When you think about just the models itself and going back to, because that's the core of a lot of what agents are, they have what's called jagged intelligence in the sense that they are state-of-the-art, amazing, surprise you with the capability that they have in terms of coding or in terms of being able to synthesize information. But at the same time, they make very common silly mistakes. Or they're easy to be tripped up when you change prompts. And so we're still on that. Frontier of jagged intelligence.

So I think when you think about agents, 2025 was sort of the year of agents, and rightly so because the models advanced. I think we had huge advancement in terms of computer use agents, browser use, things such as that, that enable these agents to be real. And so you saw this significant inflection in terms of deployment of agents. So sophisticated enterprises today have deployed over 1,000 agents in production for various different tasks.

At the same time, this jagged intelligence essentially means that you really need to do your homework in terms of defining this harness for your particular use case. Which essentially means that you have to make sure that the agent has the appropriate context, and that context essentially mean in an enterprise's use case, access to the appropriate data, the appropriate sort of guardrails, compliance, and security framework that enables it to then function within that particular use case. And today, most agents still do incorporate a human in the loop for most tasks as a way from a final sign-off perspective.

So I think the hype versus reality is that, are we seeing agents in production? Yes. Are they perfect? Are they completely autonomous, fully agentic? No. You need to do a ton of work in terms of defining these harnesses, defining these sort of guardrails, if you will, in order for you to get the appropriate output with a human in the loop.

And there are also significant areas of concern. I mean, security being one of them. But also how do you actually regulate how token use happens? Are these agents doing useful work? Do you actually have the right sort of governance of how you manage all these agents? If you have 1,000 agents in an organization, how do you ensure that they have access to the right tools, they're being governed properly? So there's a lot of these open questions which I think a lot of enterprises are still working through. But there's no denying the fact that just from a pure capability perspective, models, harnesses and such like, as well as from a deployment in the field, we've seen a huge step forward over the past year.

Where agents are delivering real value

Michael Krigsman: You have just laid out the agent world. Let's start unpacking this. Let's begin with applications. So where are you seeing real applications for autonomous agents that are effective, that are actually delivering real value? Let's start there.

Praveen Akkriraju: There's a spectrum here. So you can think of the spectrum as one end is what we as individuals experience in terms of agentic capabilities. And you can think of that as, you might be using a tool such as, maybe you built your own OpenClaw or something such as Manus. On the other end of the spectrum, you have enterprise class agents. And there's a whole set of things in the middle, where you have vendors building these very specific agents for specific kind of use cases.

So I think if you look across the spectrum, I think one thing that obviously was a huge seminal moment was OpenClaw, earlier this year. And the reason why OpenClaw burst out was. And if you go back in history of AI, there's been a lot of companies trying to build these personal agents, agents that you and I could basically deploy, give access to our contacts, our email, calendaring, et cetera, and have them do work for us. And OpenClaw was the first kind of open source framework that actually started to work because it was able to bring the appropriate sort of ability to understand the work, ability to remember work. An ability to take the right context and plug it back into the model in order for it to execute a task.

And I think that truly blew people's mind because it was so effective. And simple to execute. So you saw on the personal side, and I think all of us have been playing with Claude Code, either on the CLI or in the application itself and doing interesting workflows in a very seamless way. So I think the. So we've seen huge amount of personal productivity improvements. Most of these tend to be single use case, or more single user oriented agents.

The other end of the complexity is where you actually have an enterprise that's trying to build or buy an agent that needs to be deployed across thousands of employees. So here you're seeing, there's 2 aspects to it. So the first aspect is there are certain functional sort of agents. You can think of customer service, for example-Where you clearly have well-defined agents, that are effective, that are able to deflect a lot of first line kind of support calls and be able to demonstrate productivity in that context.

And so you're seeing the use cases where you're seeing clear fit is customer support, obviously coding. Coding I think has been the ultimate sort of AI use case. I think it's almost as if it's estimated about 3 billion in revenue right now from just coding agents. Customer support agents, I think is close to about 500 million in terms of revenue generated just for that sort of use case. I think search has been another one. It's less of an agent, I think it's more of a tool, but you've seen good traction, enterprise search, as a fundamental use case.

And if you think about sort of the specific sort of verticals where you're seeing good adoption and tools, clearly there's been a lot of momentum in the legal space, in healthcare, in tech forward companies are essentially deploying AI agents in a significant way. So I think when you look at the spectrum, you see significant advancements in the personal sort of single user, single use case kind of agents where you can build your own because the interfaces are become much more simpler. At the same time, enterprises are focusing on these specific sort of use cases where there's clear product market fit, clear value, and measurable ROI for these deployments.

The negligence problem with agents

Michael Krigsman: We have a very good question, interesting question from Anthony Scriffignano on Twitter, who is the former chief data scientist of Dun & Bradstreet. He's been a guest on CXOTalk a number of times, and he says this: "One of the big challenges with agency in the real world is negligence. Can you talk about the danger of AI agents acting in concert in a negligent way and the impact on the enabler?"

Praveen Akkriraju: When you think about models, fundamentally, I think they are prompt driven. And when you think about sort of the construct of an agent, you give it a task, it creates a plan, and it goes out and uses a bunch of tools to execute that task. So you're in that. There are many areas where you could potentially have this notion of, and the plan could be wrong, it could be using wrong tools, it could take the input from the tools and go down a different path, where it might actually do something malicious, or there might be a prompt injection attack that makes it do something malicious.

So I think this is the reason why this notion of a harness and guardrails is so critical. And almost say the agent is actually the harness. So the ability for you to create, define clear guardrails, clear constraints, and clear evaluation criteria for the agent is extremely important, and that's a fundamental aspect, where you need to spend a lot of time when you build these agents.

Because essentially, these large language models are steerable. I mean, they're very sensitive to prompts, and they react very immediately to the prompt that they're given. So the actual sort of constraints and the steering of this agent has to happen in the harness. So observability is extremely critical to be able to incorporate into these.

So one design aspect here that we're seeing is this notion of sandboxes. If your agent is essentially, let's say, writing code to execute specific tasks, what we're seeing from a design pattern perspective is, developers are spinning up these sort of ephemeral sandboxes to first make sure that the code that the AI agent has written is sandboxed, executed, is essentially measured against the guardrails to ensure that it confirms before you actually execute and push it out into production. So there are ways to address this, but it's absolutely a critical concern.

Data boundaries and context ownership

Michael Krigsman: We have a great question from Chris Petersen, and he says, "Giving agents access to our, quote-unquote, context is interesting, but how do we maintain boundaries between the context we own as individuals versus what belongs to others, friends, family, employer, and so on?"

Praveen Akkriraju: This is sort of one of those things where from a data access perspective, being able to design this thoughtfully is critically important. Again, when you look at sort of the way an agent accesses data, you're either giving it an API, or you're giving it access to an MCP server, or maybe you're using CLI if you essentially just giving it access to something that's running on your computer.

So an API app gives you the most granular ability to create an OAuth architecture that allows you to be very granular about the kind of information the API can access. MCP tends to be a little bit more abstracted in terms of what it returns because it's more of a generalized sort of access paradigm. So when you give-An agent access to data, I think you want to pick the right sort of interface that it uses in order for it to be able to get access to this particular data.

And again, I'll go back to this notion of creating the right guardrails. You have these tools, as I said, either using an API or the appropriate choice there. But also just in terms of policies, you can define these .md files that effectively tell the agent, "Hey, check to see if this data is PII." Or check to see if this data is sensitive before you actually use it. You can define what the agent does in these kind of .md files that are given as a specification for the agent when it gets started.

Observability and compounding errors

Michael Krigsman: Yeah, sure. Except when the agent ignores the instruction and gives you back something altogether different, and then you look at it and it's not right, and you say, "Well, you didn't do what I said." And the agent comes back and says, "Yes, you're right. I didn't do that. Here's what I should have done." And this is totally. And this is seamless, so there's no way to know unless you know something about the answer that you've been given. This is very dangerous.

Praveen Akkriraju: You give it the appropriate guardrails, you give it the appropriate data, it still produces a result that's not. That's incorrect. And so what we are seeing, again, from a design perspective, is, you need to create the right observability framework, so you're not just waiting for the output at the end of the agent's execution, but rather you're looking at the traces at every single step, and being able to sort of understand that.

And again, combining this with sandboxes, we have a company in this space called E2B that's been tremendously successful helping developers with this. To create observability at different stages of the agent's execution, so you can catch it. Because look, this is an important point. Errors compound. So if you have a multi-agent architecture and an agent makes an error and feeds it into another agent, you essentially have a compounding effect of error.

So it's really critical for you to be able to have this kind of granular observability and design the evals. Now, I. It's easy for me to say to design the evals, but that turns out to be one of the more challenging aspects of agentic design. And I think, you see the sophistication of something such as Cloud Code, or a customer support agent. It's actually the brilliance of the harness because they've actually done exactly this. They've created the observability, so it checks its answers. They create the eval, so it actually knows what is correct and what is wrong. And that's how you get to. And it's a fine-tuning process. And I think a lot of enterprises are actually going through this, which is to essentially start this process of building the agent and continually tweak it till you get to a point where you feel, okay, you've got the agent executing the way you want it.

Bolting agents onto legacy software

Michael Krigsman: Preethi Narayan, who asks a very interesting one, and she says: Most enterprises are built for AI assistance, that is tools that help humans decide. But agents actually make decisions and act on their own. That's a fundamentally different problem. So when the shakeout comes, and parenthetically, it's interesting that she's making the assumption that a shakeout will come. But when she. But she says, "When the shakeout comes, do the survivors rebuild or do the ones who bolted agents onto old infrastructure simply not survive?"

Praveen Akkriraju: The rate at which model capability is advancing is making a lot of the assumptions or sort of these notion of you can wrap things around a model and deliver value obsolete because that's been absorbed directly into the model. So I think the. So there's. If you take apart this question, there are a couple of things here. So the first thing is how, all the legacy software or the existing software that we have, how does that transition into this agentic era? And the second question is, agents have autonomy, and what does the future look like when effectively we do get all of these things figured out and get fully autonomous agents?

I see the world as a bit of a hybrid. And that's primarily because the challenge of actually allowing an agent to be fully autonomous is a fairly challenging task. I mean, in a bounded problem space, let's say coding, where you know what the output needs to look like. You can measure it, you can test it, and you can certify it. You. The convergence towards autonomy is likely to happen faster, and we see this today. I think if you talk to some of the large labs, they'll tell you that they feel coding is at AGI already, in the sense that it is a level above human capability and is able to actually work as well as humans do.

But in more sort of unbounded tasks or, I think, a task where there's a lot of dynamicity, let's say you're managing a supply chain in an enterprise and you have different SKUs, maybe a different geo, maybe a different set of supplier onboarding with various different criteria. The ability to generalize what the agent does across these new capabilities pretty much, again, comes down to how well your harness behaves. And so designing that is a lot more challenging than a bounded problem such as solving math, or being able to write good code. So I think that's the way I would think about this in terms of how do you spread these across bounded and unbounded?

So-For existing software, if you're just a bolt-on agent on top of software without fundamentally changing the way software interacts with data, with users, and being able to respond dynamically, then I think you clearly are going to lose that battle to potentially a newer version of software that's a lot more sort of agentic and dynamic. Ability to respond, take input, be able to do work and work. And be able to offload the human from a lot of the work that an existing platform would do.

However, I think I do see a future where we. And we are seeing this, and we have a number of companies obviously that are doing great work, being able to understand how an application works and figure out where can they insert an agentic step that accelerates the time to value for the customer. I'll give you one example. Stampli, which is one of our companies, they do accounts payable. They're a procure to pay company. So one of the challenging aspects of accounts payable workflow is reconciling invoices. And it essentially is a manual task because unless you reconcile the invoices, you can't approve the payment.

And so what the team's done is basically said, "Hey, let's understand the entire workflow of accounts payable and figure out where are the steps such as, potentially there's form filling or there's invoice reconciliation, where we can insert an agentic step to accelerate the time to value for the customer." I think that's a thoughtful way where you can actually take an existing software platform. And of course, it does require some surgery, to be able to insert these steps in the middle, but then you can accelerate dramatically the value for the customer because all of a sudden now you've eliminated days' worth of work of an invoice reconciliation. The AI does it for you, and then the human approves it. So that is real value in existing software paradigm.

At the same time, there are other examples where it makes sense to bottoms up, reconstruct sort of the workflow. So a lot of these sort of operations-oriented software, whether it's security operations, IT operations, et cetera, customer service operations, where you have a strong data platform that you're then able to now build an agent on top to essentially use one of the LLM's superpowers, which is discerning signal from noise. So I think that's why I believe this is a hybrid world where there will be companies that are doing things in a thoughtful manner to transform the existing software. At the same time, you have bottoms up AI native approaches, which clearly will either create new surface areas such as coding. Nobody thought coding engines would be a brand new kind of market space. It's $3 billion worth of revenue in that space right now.

Human in the loop versus full autonomy

Michael Krigsman: We have a question from LinkedIn, on LinkedIn from Swami Vaidyanathan. And Swami says, "How do you envision the target operating model? Number one, enterprise AI to be dominated by human in the loop by design or autonomous agentic enterprise with guardrails and governance, especially with the questions around AI reliability." And obviously the human in the loop is what everybody is doing now because it's a more conservative approach. But how do you see this shaking out?

Praveen Akkriraju: Human in the loop is the defined paradigm. And in a lot of ways, I think that, I go back to sort of my reference of bounded, unbounded problems. The more deterministic a particular workflow is, the more bounded, more well-defined the outcome is, I think the faster the opportunity for us to get to autonomy will be. I don't believe that we will, at least in the near term, be able to get to complete autonomy across the entire enterprise architecture. The enterprise is just way too complicated. You have a lot of very specific workflows that are unique to an enterprise, so you divide the spectrum of use cases. There's some standardized workflows, maybe front end facing workflows which are fairly standardized across multiple enterprises, where you could potentially get to a higher level of autonomy.

But the. It's a combination, I think, of 3 things. So the first thing is the nature of the workflow itself. And where you lie in the spectrum of bounded deterministic workflows versus dynamic sort of more unbounded workflows. The second aspect I think is there is a regulatory compliance aspect to a lot of these industries. So if you're in healthcare, for example, where there's been a lot of AI adoption in a space that typically has been challenging in terms of technology ramps, you see a lot more rapid adoption. But there is significant amount of regulatory and compliance based requirements that essentially requires a human in the loop, because you do need that sign-off and that accountability that is mandated.

And the third part of this is again, it's going back to the previous conversation we were having, is how-Well designed is your guardrail? How well designed is your governance framework? How well designed is your security architecture in order for you to have that confidence to let the model function? If you go back to the human way, listing coding as an example, you always had this notion of you write code, there's a PR, and then there's a code review in order for you to be able to before you push code to production. And so there's always sort of even in your traditional. You can take any workflow, I mean, it could be a legal workflow, it could be a finance workflow. There's sort of this amount of work done, and then there's one step of approval, could be a senior legal professional or finance professional who signs off on the work before it goes out. So that step of verification has always been built into a lot of these workflows.

And so the question is, is that step, is it worth eliminating that step? Or is, can. If you're able to get to increasing amount of accuracy on those, that is essentially what determines whether you can get there. So the quality of the harness design and the quality of the governance, and that'll be, I think, an experiential process. We're going to keep experimenting till we get to a point where we get more confidence and it's very much going to be use case dependent.

Shared libraries and third-party agents

Michael Krigsman: We have a really interesting question from Arsalan Khan on Twitter: "Are you aware of any libraries of AI agents that are accessible to all organizations? So organizations, all organizations have to do is provide the data, and could industries work together to create this?"

Praveen Akkriraju: Personally, I'm not aware of a public library of AI agents per se, other than those that might be available. I guess you could kind of. There's probably a library of different OpenClaw agents that folks have built and published that you might be able to access to. But again, that's one of those things where you really want to be very careful about deploying a third-party agent into your environment unless you truly have confidence.

So but what we are seeing obviously is within an enterprise, the notion of building agents and publishing those agents and making sure that the teams across an enterprise have access to the agencies is clearly the way enterprises are encouraging the transition to an agentic architecture. I think the broader question of, are there ways you can collaborate, and I think you're starting to see this in particularly areas such as security, for example. You can think of the Mythos release, whenever it's going to be publicly released, could be a very powerful tool for the community to be able to figure out how to protect themselves.

Of course, it's a double-edged sword, and that's, I think, the conundrum that we're dealing with, with this really capable model. I think I just saw an article from Mozilla, the latest version of Firefox. They found two hundred and seventy-one bugs, using Mythos, which is amazing. I think only 3 of them were probably CVEs, truly high severity. But still, the surface area of the power of that tool is obvious. So that is an example, maybe an imperfect example because it's a double-edged sword. But I do think that you will see some of these general purpose agents that will be out there that help the broader community. But I think, given the nondeterminism and so many kind of open questions around agentic architectures that we just talked about as governance and guardrails and such like, you should be very careful about just taking third-party agents and just using them. So there's. We're still not at that level of maturity.

Fixing processes and data in parallel

Michael Krigsman: We have an interesting question from Syeda Zeenath, and she asks, "Do we need to ensure that organizations, or do organizations need to ensure that they fix their processes that are not working properly before they integrate with agents, or can, to what extent can they work with existing processes?" And I'm going to ask you to keep your answer pretty short, Praveen.

Praveen Akkriraju: I'll take this as an example of the data architecture. So this is a typical conundrum because most data today in an enterprise is sort of pretty fragmented. Not everything has a nice clean little API that you can access it through. So the conundrum's always been: Should I first do a big data transformation project before I get started with my agentic transition? And I think what we're seeing enterprises do is they can't afford to wait. So. And you have interesting tools now such as computer use and browser use that actually enable agents to use your processes and your data and access your data as a human would. So it's sort of a. I think we've found these tools so you don't have to wait, and I don't think you can afford to wait to drive this huge transformation project before you go to AI. You'll need to do these things in parallel.

Michael Krigsman: So from that standpoint, it's somewhat different than historically implementing something such as ERP or CRM, where you really did have to clean up the data and or clean up your processes. It's what made sense.

Praveen Akkriraju: When you say processes, obviously the way, you have to rethink human-centric versus agent-centric policies. These are completely different sort of workflows, so there is a level of sort of architectural design of processes that does need to happen. And so you start off with a few workflows, and you assume that there's an agent in the loop and design your process for that, and you learn and you go along. So it-The answer here is really sort of it will be experimental. You're going to learn as you go along. But my broader point is that you. I don't think you can wait to do a process transformation or a data transformation. I think you need to pick a surface area and start to work on that. And ideally use the tools that these AI models provide you in order for you to accelerate that process.

Building on quicksand of changing technology

Michael Krigsman: It's a really, really good point because the technology is changing so much more rapidly than anything in the past. I mean, ERP systems didn't change from one week to the next. They were stable, and so you had. It was not a moving target in the way that the current AI technology is.

Praveen Akkriraju: It almost feels as if we're building on quicksand right now. Because, just given the rate at which model capability is advancing or, new capabilities are being unlocked, you need to be able to be more dynamic. And that's part of, I think, the challenge. I think this is called the Red Queen effect. Which is effectively every enterprise, every knowledge worker, every professional today, we all feel the same sense of urgency that if we don't change, if we don't evolve, we're not going to keep up. We're worried about getting ahead. Just to keep up, you have to keep changing and keep evolving, and that's the state of things, where we are.

How hiring and roles are changing

Michael Krigsman: Another question again from LinkedIn, and this is from Benyawarath "Yaa" Nithithanatchinnapat, who says, "You've watched dozens of agentic AI companies hire. What's a skill that mattered a lot in new grad hiring 2 years ago that you now see hiring managers have stopped caring about?"

Praveen Akkriraju: If you go back 2 years, they were clearly defined roles. You had a software engineer, essentially proficiency on code, had all these, elaborate coding exams that you had to get through, designing, walk a tree, these kind of things that were kind of bars for you to get through that. There were product manager roles, there were forward deploy. there were sort of field roles, in a well-defined sort of architecture of what an organization looks like.

Today, if you actually look at a lot of startups, all these roles are mashed together. There is no clear product manager. A software engineer today is on site with the customer, actually working with them, deploying code, learning from them, developing almost. Be with the customer in the morning, develop code at night, go back to the customer. The iteration loop has gotten much faster, and it's broken down the silos. So if you're a new grad coming out, essentially that is what you're expected to do.

You're not going to be given a project and saying, "Okay, here's a project. Okay, learn the code base and then produce something or fix a few bugs before you write code." You're essentially going to be dropped into a customer site and say, "Okay, let's go build a product and iterate fast." And I think that means that you have to be sort of a software engineer, a product manager, a forward deployed engineer, all of this stuff rolled into one. I'm talking about a startup context, of course. If you're a large organization, some of these roles might be further more well-defined given sort of the complexity of what that particular company might deliver. But I think that's what we're seeing. These roles in startups are hybrid. And close to the customer and close to the code is what differentiates engineers now.

Democratizing work through coding harnesses

Michael Krigsman: I had conversations during the past week with CIOs from two very, very large insurance companies, with thousands or tens of thousands of employees, separate conversations, and one of the things that became clear is this melding of roles, the dropping of boundaries between product design, software development, DevOps. These are all merging together. Now, these particular folks are highly, highly advanced and highly innovative, but it's a glimpse into the future where, Praveen, what you just described will take place inside very large companies as well. It's not just the startups, at least going into the future.

Praveen Akkriraju: If you think about what we saw with Claude Cowork. Claude Cowork essentially was a realization in Anthropic, as well as some other labs as well, that this coding harness that we built to write code can actually do work. Can actually do non-coding work as well. And so what that means is that if you're a business analyst, or a financial analyst or, support engineer, whatever, you now have a very powerful model that you can use to define your workflow and create your own sort of application agent, if you will, to get your work done.

And that's sort of the democratization of that AI has enabled. In the past, you probably needed to go to an IT team and say, "Hey, here's what I need to get built," and there's a certain amount of time. So now if you're a business analyst, you just say, "Okay, I just need to, whatever, get all this information, synthesize this, put this into a particular spreadsheet, run this particular analysis," and I could create that entire workflow myself, and the AI would be writing code in order for me to do that. So that is actually the true power of agents. It's democratized coding. It's democratized the ability for knowledge workers, whether you are an engineer or an analyst, to be able to get your work done.

The SaaSpocalypse debate

Michael Krigsman: Let's talk about the SaaS apocalypse, the SaaSpocalypse. Do you believe that-AI agents are going to replace software such as Salesforce, such as Workday. Where do you fall down on the SaaSpocalypse argument?

Praveen Akkriraju: We talked about this a little bit in the previous question as well, where we were sort of talking about how you take existing software and be able to transform it, in a thoughtful way. Essentially looking at where can AI accelerate work that is being done, and accelerate value to the customer. So I gave the example of invoice reconciliation in an accounts payable or procure-to-pay platform such as Stampli. I think, look, system of records are not going anywhere, in my opinion. And because fundamentally, the one question we haven't talked about is there's a real cost to agentic software.

And this is basically there's a variable cost to software. So every time you are writing code or using a tool, or doing reasoning, you're burning tokens. And sure, I mean, the token costs have gone down dramatically, over the years as these model capabilities have advanced. But, it is still fundamental cost that you have to now think about when you start initiating a project.

So does it make sense for an enterprise to say, "You know what? I'm just going to bottoms up build a brand new CRM, or bottoms up build a new ERP"? Is that worth the amount of tokens that you would spend, to go do that? Versus, where is the real value for you as an enterprise? Which is basically accelerating your business, your use case, if you're whatever, insurance provider, bank, whatever, manufacturer. That's where you want to spend your tokens as opposed to going down to the infrastructure level and saying, "Well, let me just go reinvent the wheel just because I can."

Can you build it? Of course, you can. And it's interesting because in a previous cycle, companies such as Tesla essentially rebuilt their ERPs because they felt the existing ERPs did not fit the kind of model that Tesla wanted, the fully vertically integrated car production systems. And so that makes sense. I mean, there might be certain use cases where it logically makes sense. But I just, I don't buy the fact that you're going to go and reinvent the wheel here and try to take some of these really complex, must be super reliable kind of infrastructure pieces and software and redo them.

Shifting budgets and pricing pressure

Michael Krigsman: Oh, I totally agree. I mean, I personally, I think it would be insane. Who's going to try to rebuild their Oracle or SAP or Workday systems? Now, there's going to be nibbling at the edges, for sure, but we have a question relating to specifically this from Lisbeth Shaw on Twitter, who says, "How is agentic AI pressuring existing enterprise software pricing and business models?" Which is really the question.

Praveen Akkriraju: We clearly are seeing budgets shifting in enterprises, from traditional SaaS, per seat pricing to more sort of agentic tools. And a big part of that is in some ways just sort of a cleanup, if you will. There's a lot of sort of excess, seats or excess sort of software buys that have happened, which are being reconciled now based on usage, and that budget's being redeployed for AI experiments.

The one thing I'll say, and it's important, a lot of this is we're observing this in real time. None of this is, none of what I'm sharing or, the conversation we're having is absolute truth. With-- It's kind of a point in time, this is where things are, and it's a big part of where we are as an industry right now, which is given the rate of evolution, we're trying to connect the dots and extrapolate. But, we are still early in this journey towards sort of agentic architectures.

So I believe that, today where enterprises are, they are very aggressively leaning into this notion of an agentic transformation for the whole architecture. At the same time, I think what we are also seeing is that most enterprises are running experiments, around, where does an agentic solution make sense? How much is it going to cost us? What is the true ROI? How do we govern these things? So these are all questions that are being answered in real time.

In certain use cases, obviously, the answer is obvious. Customer support, obviously we're seeing a huge amount of traction there. Writing, marketing collateral, those kind of use cases are clearly demonstrating a lot of value. A lot of operations use cases where you have a ton of logs or a ton of data and you're trying to discern signal from noise, those use cases make sense. But I still. We're still sort of in this early stage of adoption of agentic architectures and, still have a number of significant questions to be answered. So we're not quite across the line yet.

Build versus buy for agents

Michael Krigsman: How should CIOs make the build versus buy decision regarding agents?

Praveen Akkriraju: In talking to a lot of enterprises, what we see is sort of the build versus buy is breaking down around the front end versus back end kind of line. So a lot of front end customer facing tools where the workflow's perhaps a little bit more standardized. You are, enterprises are leaning towards a buy kind of decision. So it could be something such as customer support. It could be something that's, a standardized workflow. If you have a finance workflow, you're-You're running your finance statements. It's done the same way in most organizations.

In the back end, there's a lot more variability depending on your industry, depending on sort of the compliance and regulations that you have to abide by, and also, there's a lot of data that you have. So bringing those things together is where we're seeing the buy, enterprises leaning towards the buy side of decisions. So using frameworks, using these model capabilities to build their own sort of customized agent. So at a high level, that's where the line is. But again, we're early in this journey, so it's something that we need to keep following.

When to remove humans from the loop

Michael Krigsman: Where can CIOs safely remove humans from the loop and where not? In other words, where does autonomous operation actually make sense?

Praveen Akkriraju: It really comes down to sort of the harness that you're able to build around this agent. And what I mean by that, again, is the ability to create a well-defined reasoning, and a well-defined sort of decisioning process for the agent. And so the context that you provide to the agent in terms of the data it has access to, the guardrails, the tools it can use, the parameters of how those tools can be used, I think defining that, being able to have very granular observability and evaluation frameworks in order for you to make sure that as the agent's progressing, you're able to understand, and catch any drift in its performance and, being able to have a well-defined set of criteria of what good looks like.

This sort of, again, the bounded, unbounded sort of spectrum, if you will, of workflows that give you confidence to allow the agent to be able to execute on its own. So the answer to that question again is there's no, there's the ability for the organization for, the team to be able to define these criteria, I think will is what enables, that dial of autonomy, if you will. I think, we are, we're still, at least what we see today is still sort of significant amount of human in the loop, and that's probably going to be the case till we get to an inflection point in, the accuracy of these harnesses.

Managing token costs and prioritization

Michael Krigsman: What practical advice do you have for CIOs on managing cost, risk, unpredictability, the variability of inference costs, your token costs going out of control? What can CIOs do? What should they do?

Praveen Akkriraju: Let me focus on the cost aspect of things. We've talked about sort of governance and, the ability to deal with the unpredictability of large language models. I think, as we said earlier, you have to. Software now has a variable cost. And I think it's important to understand what that means. So, you've seen a lot of things in the press or, on X where you say, "Oh, I'm measuring my team by how many tokens they've used." And that's sort of, engineers are measured by what their token consumption is.

The one thing we've clearly seen is in organizations, and there's some data point, I think there was a Goldman Sachs study that came out, that basically said that, enterprises are blowing through their token budgets a year's worth of AI budget in three months. It's, this is the notion of token maxing, which is, as many tokens as you provide will get consumed as quickly as possible. So we're still in the stage where, I think CIOs need to sit, take a step back and say, "Okay, I have X number of projects." Because we've unleashed the beast, everybody now has access to build their own agents. How do you prioritize these? And, just old school sort of making sure that you're investing your tokens in the most highest priority projects.

I think that's, what we've always done, historically in terms of defining software projects is just because you're able to build your own agent, doesn't mean that you should. Again, going back to the example of do you want to go build your own ERP or your CRM? Is it worth it? So I think prioritization, clearly understanding sort of token costs because now you have multiple agents. It's not just token costs, by the way. You might be using APIs to go access different tools. So, those tools may have their own particular cost. So for an agent to actually execute, you have to now break down the cost of the platform, the tokens, the tool uses, all of these things composite to figure out, and then weigh that against your ROI criteria. Are you actually getting better productivity? How do you measure productivity in granular terms? Is it, calls deflected if you're in a customer support area, or is it the speed to reconciling, accounts payable, in the previous example? So creating those kind of business level metrics, matching them to the cost of what it takes for an agent to execute, I think is important.

Now, I do think that, models are going to get better, more efficient from a token use perspective, and you already see that happening, all the way from Opus 4.5 to the 4.7 or even the GPT 5.5. They are getting much, much more efficient in terms of token use, and I think that's important. But also, being creative in the way you use memory and being able to use smart ways to ensure that you're putting the right context in. These are the kind of things that are design principles that help you optimize token costs. But, weighing the token cost versus the ROI I think is a critical lens in addition to the other things we talked about.

Pricing agents as fractional FTEs

Michael Krigsman: Bridget Ejegi, on LinkedIn says, "How can selling companies charge for their AI solutions?" Just in a sentence.

Praveen Akkriraju: There's a spectrum of do you go to consumption-based pricing? I think we've actually done some work at Insight, our pricing team. And I think one way we're thinking about this is perhaps you think of this as a fractional FTE. Or a fractional headcount because I think we are going to this notion of a hybrid human agent workforce where, each of us as employees will have our own agent. And maybe the way to think about this even from a pricing perspective is to price it as a partial FTE, particularly if it's doing, specific work. But, this is a point of experimentation again. There. This is a longer answer, but you said 10 seconds, so let me just leave it at that.

Michael Krigsman: All right. Praveen Akkiraju, Managing Director of Insight Partners. Thank you so much for being a guest today, Praveen, on CXOTalk. I'm very grateful to you once again. And thank you to everybody who watched. 

Before you go, subscribe to the CXOTalk newsletter, go to cxotalk.com, and we have great shows coming up. Our next show is with the Chief Technology Officer of Mozilla, so check it out. Thanks, everybody. Have a great day.