How Enterprises Should Build AI Agents

ai Leadership Insight Series. I'm your host, Mike Vizard. ai, and we're having a little chat about, well, AI agents, because everybody's trying to build one, but building them may be the easiest thing of all of these challenges that we're about to face.

Raj, welcome to the show. Oh, thank you, Mike. Glad to be here.

It's still early days, and a lot of folks have experiments going on, and some folks have a lot of agents that they've deployed for different use cases, but maybe they're not all integrated with each other. But as you look at this whole thing, what are the challenges you're hearing from folks as we go forward? Because, well, I got a feeling that just building the AI agent is only the first step in a long series of things that we need to wrap our heads around.

No, absolutely. I think if you're working in a company, you're probably using ChatGPT or Claude or Perplexity or something for personal work to help you with your work, summarize something, generate something, whatever. I think that pretty much everybody's doing that.

But when it comes to how AI agents helps a business, and you need to look at the business processes. Whether a business is producing a product or a service, there's the creation of the product and the service, there's the marketing of it, there's the selling of it, there's the delivering of it, there's the support of it. Pretty much no matter what kind of company you are, you have those processes.

So I think overall, when I look at the use cases that businesses are trying to implement to improve a business outcome to get a ROI, it falls generally into three categories. One is what we call customer experience automation. The other one is employee experience and automation for employees to do their jobs more efficiently.

And the third one is process automation, which is where large amounts of data is being processed, business rules are being applied. There's a human in the loop as may be required in some cases, and you try to reduce the cycle time of processes, the cost of a process overall. So what we are seeing is the customer experience area is the first area that many, if not most companies, are embarking on.

And the simple reason for that is there's immediate ROI. ROI in the form of requiring less number of human contact center agents, improving the efficiency of those contact center agents, using AI to study the quality of those interactions with customers, being able to deploy a very interesting and enjoyable experience to those customers. And finally, improving customer satisfaction, which has tremendous ROI.

Employee experience is interesting. Measuring it is more difficult. " For him to calculate the value of that is going to be difficult.

So that is being implemented quite a bit, but the value realization is nebulous. Whereas process automation, I think there's a lot of scope in process automation. It's still early days.

People are still using workflow systems, RPA tools, for the most part. I think that over time is going to shift to reasoning-based agentic AI systems over time. So depending on the use case, the challenges are less so in customer experience, more so in process automation, and to some extent, in employee experience.

The challenges is always about how do I build this? What models do I use? How do I manage this?

How do I measure the ROI? How do I govern this? How do I trace what's going on?

Do I create this completely agentic, where the model is making a lot of decisions, or do I make it partly deterministic and partly agentic? These are decisions that is very dependent on the use case, dependent on whether you're a regulated entity or not. If you're a regulated entity, you don't want it to be completely reasoning based, but you still want the reasoning-based approach for delivering a more conversational experience.

To your point about deterministic, I think part of the issue seems, to me at least, is that a lot of processes need to be done the same way each time, every time, and generative AI never does the same thing the same way twice. Mm-hmm. And so that doesn't quite lend itself to a lot of the processes that businesses rely on.

And yet, if the more deterministic a process is, maybe the more I can automate it using something else. So are we just trying to find the right balance between automation frameworks and engines here so we can maybe have something that is the customer service part of a process be agentic while the rest of it is deterministic and using some sort of other automation engine? Is that how this is going to play?

No, I think it's not about something is going to be completely agentic or something is going to be completely deterministic. I think it's going to be a hybrid, and I'll tell you why. The experience needs to be naturalWhat people want, if I compare it to a traditional IVR, like a voice experience.

You're put through a menu. You press one, you do this, you press two, you press four. You go around a very restricted menu.

But the experience people want is to just naturally speak or naturally type, and let the application understand the context and produce the right response. So I think to deliver the experience that people want or just the modern application ought to be, you need to use LLMs to generate that response as opposed to having scripted responses. But then the business logic, whether you're a bank, you're a healthcare company, you're a government agency, whatever you are, your business rules need to be adhered to.

You don't leave business rules adherence to a model, because that's where the hallucination may cause problems. So when you think about a workflow, you have generated responses, but certain parts of the workflow which are deterministic to ensure that business rules are being adhered to is the combination that needs to come in. So I think when you look at the world today and the experiments that you talked about, people jumped very quickly from completely deterministic applications like UI-based applications or workflow applications, which had no reasoning in them at all, to completely agentic, and then they realized that's a problem.

So the future is going to be platforms like ours, which give the ability for enterprises to create what needs to be deterministic deterministically and what needs to be reasoning-based or generative AI-based, where the experience is managed with that, basically. Is there a way to start thinking about that before I get started, or is this ultimately always going to be an exercise in trial and error? No, absolutely not.

You know your business rules. Whatever your business rules are, whether you're a bank or whatever kind of financial institution, or a healthcare company, or telecom company or whatever. So you've got to codify that into your application.

There's no choice in that. Now, at the same time, you can upfront decide what part of that workflow needs to be generated, through reasoning or through generation of text or voice or whatever, and what part of it needs to be a workflow that you control. So it's not a trial and error.

It is really a question about whether you design things well. And I think the problem right now is there's so much euphoria. Models are coming up with new capabilities so quickly that when you think about the people who design these new age applications, what we call AI agents, none of them have had the experience to design them.

This is new to everybody. So the same old saying, you design something well, you'll spend less time on development, you spend less time in testing, essentially. The same thing applies here.

So you need to learn agentic concepts. You need to learn limitations of models. You need to learn how to build this workflow, the right tools, and then have the ability to govern them after they go into production, basically.

So enablement education is the key right now to be able to design these things appropriately and then get value out of them. Are we going to need specialists for that? And I'm asking the question because historically, when we built an application, it was always kind of haphazard, shall we say, in the sense that the people who understood the workflow were in the business, the developers kind of understood the code, and they would go back and forth till they got to something that felt like a compromise that probably not everybody was exactly happy with anyway.

Is that going to change in this new era, or is this still going to be this kind of push-pull kind of process till we get something we like, or is there a new way to think about building software? Oh, that's already happening. It's all over the place, right?

Software, as you know how it was built is gone. It's going and gone. AI is going to build software.

You're not going to build software, basically. You are sort of the conductor, if you will, that's going to conduct the instructions to build the software, basically. So you said something poignant.

Business understands the business rules and process. Developers understand code. What's happening right now, and it's happening very rapidly, it's happening in the world of coding, but it's starting to happen in the world of business applications in the form of AI agents, which is AI builds the agent.

Actually, before that, AI designs the agent. It determines what piece has to be deterministic and what piece has to be reasoning-based. It then builds the agent.

Either it generates raw code or it generates some other type of higher-level language code. We've now come out with a new language called Agent Blueprint Language. So AI can generate that ABL which defines your application.

It can simulate the kind of users that will use that application, the population of users, the demographics. It could simulate everything that every user could ever say to the AI agent, basically. And so you'll get 100% test coverage, and it runs the tests, the evaluationsAnd then it knows where your infrastructure is.

Oh, you have this region in AWS, and you have this much infrastructure here. It optimally deploys the AI agent, depending on where your traffic is coming from. And then most importantly, after it goes into production, now you have real traffic for your AI agent.

It studies how that traffic is engaging with the AI agent, and it learns where things are not working well, and it regenerates the application. This one thing that AI can do now is the most important thing in the evolution of applications in general. Remember the days that, hey, I have this website or this web application, and my IT team said to make any changes to it or add to it is going to take six months.

Now imagine your AI agent is the application, and it's evolving every hour or every day as you would allow it to do and improving itself over time. So this is the world that we're going to live in. There's a thing about there's no-code platforms, there's completely pro code.

Today, there's a lot of euphoria about pro code, but then there are real problems because pro code is code at the end of the day. How do you manage that? You need to build yourself a whole infrastructure for traceability, observability, code management, all of that, basically.

So there's that middle space, which is where I think the sweet spot is, where part of what you're doing is no code. Where as a business person, you define the spec and what you want. AI does its job in the form of generating not end raw code, but an intermediary code, basically, which becomes your application.

And then if you do need to generate code for specific functions or whatever, you can generate that and have the AI agent use that. So absolutely, software as we know it has changed and will never go back. To your point about that, have we reached a point now where the software will bend more to the business?

Because if I look at historically, software applications, especially packaged applications, you would buy them and then bend your business to the way the software worked, and if you wanted to bend the software, you hired a small army of consultants to come in and created all this custom code around it that became difficult to support. But as I listen to you, it occurs to me that maybe as we go forward, the software's a little more, shall we say, disposable, and I can adjust as my business evolves almost on the fly. Yeah, absolutely.

Classic example is CRM, right? No single company, even within the same vertical, uses CRM the same way, basically, right? You have a contact object, an account object, an opportunity object, an activity object, whatever those are, right?

You get something from the packaged application out of the box. But almost everybody modifies that, basically. They need to have their custom fields, their custom objects to reflect their business.

So imagine there is no packaged application. Now you tell the platform that you may use, like one of ours, what kind of business you have, what are the parameters of your business, what are the metrics, what are the things that you want to track, and how does this process work? It will build a custom CRM for you, basically.

A custom CRM with a backend data store with your business logic. If you want, you can build UI screens or keep it completely conversational. So these applications that have been around for a while are all going to transform into conversational applications for the most part, basically.

But customization is not an afterthought. Customization is upfront when AI builds that application for you, basically. Another thing I think is going to happen is, when you take a large packaged application like a CRM, there are so many different modules, right?

There's opportunity management, account management, activity management. There's so many different things in it, basically. " And with A2A, with MCP, these standards that have come out, you build your own custom CRM by just buying or just generating that using AI.

So absolutely, I think, over time, amount of money you spend on a packaged application and then the amount of money that you spend on customizing it and extending it, you'll spend much lesser to build your own custom CRM, for example. And to your point about that, I don't think that what people are really trying to do is necessarily execute a task in a CRM. Most of the time, that application is part of a larger workflow, and it may be something part of, I don't know, order to cash, whatever it may be.

But are we going to start thinking about software by processes rather than by categories created by vendors who are trying to create something that can be used by multiple customers that they call a CRM, but for most customers, the CRM component is a piece of a larger thing? Yes and no. And I think, the yes part of it is over time, yes.

But it's going to take a long time. So in the future, 5 years from now, 10 years from nowYou may have an order to cash application with an orchestrator to deal with everything from receiving an order to processing an order to receiving the cash as sub-agents. Whether you buy those sub-agents or you build them or you generate them, that's up to you.

But today, the data stores behind these applications, whether it's SAP, it's Salesforce, whatever that may be there, are still predominantly the basis on which those businesses run. So I don't think the data stores are going to go away anytime soon, basically. And they may stay for a long time.

But the application layer, the business logic, and the UI layer is going to go through a transformation, basically. So you could choose to say that, "Hey, Salesforce is giving me a conversational application where much of the logic is in the conversational application, the business logic, and the experience layer, and I'm going to be able to customize that," basically. So that's one way you can go, or you can build your own, but still tie into an SAP or a Salesforce or whatever type of data store, essentially.

So I think it's not going to be a flip of a switch. I think it's going to take time. Those packaged application vendors are also providing add-ons or replacements to their own UI applications as well, basically.

So each company is going to go towards that eventual destination over time in a slow fashion is my belief. Is the experience of the end user going to fundamentally change in this era? And I ask the question because historically, I'd get a bunch of apps, and I was trying to correlate data across that to come up with some sense of ultimate truth.

But as you think about it, are we just going to talk to the business now through these AI agents and these conversational interfaces, and the business will talk back to us? And who knows, there might be a speech interface in the future, and we're just having a constant dialogue. Oh, well, there is a speech interface now.

We have three offerings, AI for service, which is customer service, where customers speak to the agent. AI for work, which is employee-facing, where employees speak to the agent, whether in speech or text. And AI for process, where an employee can trigger a process and review a process.

So when you look at that, I believe that every application is going to become conversational. And then you're going to have these orchestrators. Think of these as your managers, your directors, your vice presidents, your senior vice presidents that have these agents below them, basically, that will orchestrate the work and manage the context.

So the one thing that we humans have in our head is context. And we jump from one application to another today, basically. But if the context is managed by an orchestrator and it has cognizance of which agents can do which task and job and which data they have access to, basically, then yes.

You as a customer of a business, an employee of a business, you're just going to engage with that orchestrator to get your work done, basically. Now, there's a lot that goes under it, security, role-based access to data, all of that. That's the plumbing of the kind of platforms that we provide, basically.

But yes, that's the end state. Should we just get out a blank piece of paper and start over again and design the applications the way we want them? Or do we need to pull all these legacy systems with us forward because, well, we've had them for years and there's a lot of data sitting in them.

But I can't help but wonder if they might be holding us back. Well, they will. They will.

And you have competitive pressure. If your competition is pulling ahead with a nimbler way of developing and using applications, then you're going to fall behind. Either you have a pricing pressure, you have a speed to market pressure, whatever that may be.

Right? So the competitive pressure is going to pull you forward, but yet it's a crawl, walk, run, basically. I think people are crawling right now, and they're finding those jewels in their companies which generate the highest ROI right now, and they're tackling that.

And there'll be a time when they will walk, and then they'll briskly walk, and they'll run. So I think the legacy giving away to the new is a journey. It's going to take time.

What is your best advice then to organizations about how to start this journey? I think a lot of folks are looking at everything, and maybe some are overwhelmed and some are chasing every little shiny object that comes down the pipe. But is there a smart way to think about this?

Well, there are a few principles that enterprises have to think about and then make their selections of platforms and software to use to make the transformation. One principle, which is a golden principle, is you have to be model-agnostic. Models are changing too fast.

There are all size of models. Not every model fits your needs. There's the cost of models, there's the latency, there's the capability of the models.

So you need to have an infrastructure where you can adapt and adopt these models. You want to be cloud-agnostic, basically, because you don't want to put all your eggs in any basket, any one basket. Many companies have become multi-cloud.

Some companies are primarily a single cloudThe capabilities of these cloud providers are also changing. They are also dependent on model providers. They're building up infrastructure.

Infrastructure access is a limitation as of today, which may resolve itself over time, essentially. So you don't want to be tied to any one cloud infrastructure. You want your selection of software and tools to be able to build agents that can integrate with multiple data sources.

Because AI agents uniquely, probably for the first time in history, basically, are applications that function across data stores. And that's the value of AI agents. So you want to be data-agnostic.

And then finally, experience-agnostic. Do you want to provide this in text? Do you want to provide this in voice?

Do you want to deliver this through Microsoft Teams or Slack or WhatsApp or whatever? So there are so many endpoint channels where this can be delivered, essentially. So those are some of the basic principles.

And then you pick your tools, you pick your governance platform, which is a very important element because you want to be able to govern agents no matter which tools you build them on, which frameworks you build them on. And then you need to have an eye for the future, saying, "Look, I don't want to build an AI agent like how it was built in 2025. " So using AI to build AI.

AI with AI is a big theme that we believe in, and this new platform that we're releasing is all about don't build AI any other way, but with AI. Hey, folks, you heard it here. I think sometimes the most dangerous thing about AI isn't the AI itself, it's rather the legacy thinking that humans are bringing to these workflows.

Raj, thanks for being on the show. Thank you, Mike. AI Leadership Insights series.

You can find this episode and others on our website. We invite you to check them all out. Until then, we'll see you next time.