AI Agents Turn IT From Blocker to Enabler

Hey guys, thanks for the throw. We're here with Tom Davies, who's Vice President of SaaS Operations for the newly formed Helix. They just got spun out of BMC with a little help with some private equity behind them.

But we're going to have a little chat about service ops and AI and where all this stuff is going. Tom, welcome to the show. Hey, thank you.

Appreciate the invite. Yeah. So where are we going from here?

We've had this concept of service ops for a while, and now we're adding AI to that, and as Helix kind of becomes its own independent company, where is all this going to wind up at some point and where is that fine line going to be between what the AI does and what the IT admin does? Well, I think it's interesting because ultimately what customers are really looking for is outcomes. They're looking for a result.

And what you've seen over the last probably couple of decades or so in technology is a lot of companies provide pieces, and then the customer has to lace those pieces together, either directly or they pull in PS to do it for them. And you end up with these very complex stacks trying to get to an outcome, and usually the human has to do some of the work, all of the work, or lace some of those pieces together. So with AI, we can do that lacing automatically, and we can also do some of the things that the human would normally do, usually faster, because AI can handle a much larger data set, and it can execute typically way quicker than the human can.

So the human can go focus on innovation of value while that toil or that hard execution is being done by the AI systems. And certainly, we're seeing that internally in our own organizations. One of the benefits of building these solutions and having to run a company is that we use our own products ourselves to run our business.

Most of the IT people I talk to are excited about how AI might be used to automate various tasks that they don't especially enjoy anyway, but they're still a little dubious about whether they can trust it or not, and to what degree. So where do you think we are on this journey? Trust is still coming.

I think one of the challenges with AI that we have right now, and the way AI's been pushing, is the risk of hallucination, where the AI system thinks something is accurate and it isn't, and that will improve with model development. It'll improve with trial and error. And one of the things that we're doing is looking very carefully at how we learn as we go through the process.

So one of the things we generally do, particularly in our environment where we provide services to our customers, is we'll use AI to guide and advise, but we don't typically use AI to execute. We're starting to evolve that now to where the execution isn't data destructive. So if it's adding a resource or adding capacity or making a shift in a service, we'll let AI take an action.

But if it's doing anything such as removing, deleting, we'll usually get it to go prompt a human. And we'll do that as we learn, and when we see reliability improve, we'll get there. So trust is building over time.

Right. So in that regard, it's basically I trust the AI enough to allow it to read things, but I may not trust it enough to write anything, right? If it's writing new, yes.

" Yes, for that we will. But if it's a case of, "Hey, we want to go vacuum or delete data," now, we still get the human to check that for now. But we're starting to see the areas where we may be able to let AI go a little bit further and try.

But again, we'll do that in our test and dev environments before we go anywhere near production data. Mm-hmm. But it's coming.

It is definitely coming. Now, it's also important, I think, for people to realize that there isn't one AI to rule them all, and in a lot of cases, I may have different models that I'm using for different tasks, and one of the benefits of having somebody else's platform is I don't have to go master all of that. So, how much of the heavy AI lifting are you guys assuming versus what the internal IT team may need to do?

Well, that's an interesting one with us because we offer both our own AI but also bring a model for customers where they can bring their own model and their own processing. So we allow customers to go both ways, and in fact, we generally encourage it, so the customer can pick what's right for them. But ultimately, models are continually improving.

The thing that I think will be interesting to see is whether models keep getting bigger and bigger and bigger and requiring more and more processing, or whether we'll start seeing specialist models that are smaller, more condensed, and very focused on specific use cases. But we'll see. I've been hoping that would be the case for several years now, and right now, brute force is winning the day because it's available.

Mm-hmm. Of course, everybody and his brother is talking about the "who moved my cheese" conversation and whether or not AI is going to eliminate IT jobs. But let me pose this to you.

In my experience, many organizations did not deploy nearly as many applications as they might have because simply they didn't have enough people to manage those things. So as you kind of look at AI, is the converse likely to be more true, where maybe we just keep the same number of IT people when we might end up deploying more applications per IT person because we can? Well, I would take a slightly different view to it, right?

Along the lines that you're raising. What are humans good at? We're good at innovating.

We're good at creating, at building tools and building things that are better. What do tools do? Tools execute toil.

So fundamentally, I think the AI shift is allowing us to have AI, A, take on toil to free humans up to do the innovation. But they're also providing acceleration to the humans trying to innovate. So if you think about the concepts of AI, you can use it to do code assist to build code faster.

You can use it to build your entire UI. If it knows what it's doing and you've mapped it out well, it'll build your UI. That means your developers can spend more time focusing on solving problems, right, and building features that actually deliver value to the customer versus just, for example, look and feel.

And then you have the autonomous agents executing known processes, but leveraging AI and inference to put a bit more thought in there. So a business owner or functional owner can build that AI agent or workflow themselves without needing the developers. So it makes that business owner able to run at their speed, not submitting a request to an IT team, waiting for a development team to be available, then having to explain to the team what they want, have them go write it.

For example, in our HAE solution, Helix Genetic Engineering, the business owner can literally go build their own AI-based tools and agents. So as a functional owner, if you want to go build or modify a function, you can do it yourself really quickly. You don't need a PS organization.

You don't need a development team. You can do it yourself. So we're letting the business owners, the knowledge owners, and process owners be a lot more productive.

And then the automated agents are running the backend system. So what it means is, potentially you'll spend a little bit less on IT, and you'll spend more on your innovation, wherever that innovation happens to be in your business. So will it necessarily cost jobs?

There's arguments, pros and cons. I think it will change the face of what we do, and we'll see more humans doing value creation and innovation work, and less just keeping the lights on. How about you?

But that's a lot more interesting. Yeah. " Yeah.

I think what you'll see is a shift where instead of IT being seen as the blocker, IT can go back to being the enabler. Much as they were way, way back in the day when computing first came out, you used to run manual services rooms full of clerks and accountants doing work. You brought the computer in, suddenly you could accelerate that, take some of those roles, put them into sales or manufacturing, whatever.

What I think you're going to start seeing now is the return to that, where IT enables you to go run at your speed and your pace, which is quite different from the way it's been the last X number of years. We've gone through various iterations of control. How we do IT, we'll control everything to massive releases, try and control everything, which actually slows things down.

But it's rather slightly better reliability. Here now, we have the ability to let the business run at their pace as fast as they want to run in a reasonably controlled environment. So it's more interesting for IT, and IT as an enabler helps the business, not only by allowing them to push more dollars there, but also, as I said, run at their pace.

It's a long time since a lot of businesses have been able to do that. We talked about service ops at the top of this, and when I look inside IT teams, I'll see 80% of the folks, I might call them administrators, and the other 20% are engineers, and engineers with a certain specialty, whether it's DevOps or data engineers, pick whatever engineering title you want to put in front of that. Is that going to change?

Because I think, with AI, maybe we're going to see a flattening of the IT processes, and what might the future of an IT team look like from your perspective? Oh, yeah. That's a crystal ball question.

I think it'll evolve. I think you'll see less administrators whose focus is simply making sure that a service is up, or a cluster service is up and running. I think we'll have systems that through service management will be able to run themselves.

When they do encounter issues, I think the AI will be able to jump in with autonomous agents and correct issues to keep the systems up and running, which will allow IT to spend more time focused on optimization. So helping the business understand how to optimize a process or optimize a tool, helping the business understand what is the right tool, and enabling the business to go consume that tool to deliver their workflows, their automation, rather than the backlog of work that you have. You build more servers, and you have to patch more servers.

You have to run security for more servers. There's an overhead to that. If we can execute that overhead through automation, delivered through AI, then those humans spend more time adding value or creating value.

I think that's a shift that we'll see. Will the percentage of data engineers versus DBAs change? Probably.

What it will end up, I think depends on the company and what the company needs. The number of administrators or traditional administrator roles I think will reduce, but I think those roles will actually go up a level to engineers, developers, creators. I think that's where you'll see a lot more value.

And I think the value of just keeping the lights on, that will come from systems. Some of that we got with scaled-out microservices, where you have multiple small instances. If one dies, you lose a little bit of capacity, not everything, and the systems can self-repair by and large.

That I think will continue, but the changes when you require action. Again, AI can handle a much larger data set. It can do troubleshooting a lot faster if it has the context.

And one of the things we're driving is to ensure AI has access to all the relevant context, so it can go make those decisions. I think we'll see that rapidly accelerate over the next couple of years. And it's actually quite exciting, because it means that we drive more value, and we cease to become a-- It's almost like you're stopping a cost center.

You become an area of innovation and growth or enablers of innovation and growth, and that's a huge change for most IT organizations. Do you think it will be less stressful to be in IT? Because I think everybody who's in this business is aware of the fact that they might get a Slack message at 2:00 in the morning because something's not working the way it's supposed to, and maybe we could, I don't know, rest a little more peacefully because, hey, at least there's some AI out there that might give me enough time to get a full eight hours.

What do you think? Well, we've been hoping for that one for 60 years, right? I don't know.

What I will say is that as companies run better and they get better understanding of their environment, which is part of using CMDBs and understanding context better, you get better control, you get better foresight. m. calls.

Will they ever go away entirely? There's always going to be something new. If you think about a total stack, you have hundreds of millions of lines of code.

From the operating system through the switch layer, the routing layer, the services up to the applications, hundreds of millions of lines of code. There are always going to be things in there that cause problems. m.

calls will reduce. As long as the system knows what to do to kick when something gets jammed, yes, there's a potential. I don't think it'll ever go away fully, but I think we'll probably end up sleeping better at night, potentially.

But it's going to take time to get there, because again, you have to build knowledge, you have to build trust. A lot of the IT folks that I chat with, they are already using AI agents to a degree, mostly to summarize some sort of message or help out on their service desk. But when it comes to the next level of orchestration, a lot of them don't have the infrastructure needed to actually get to that.

They lack the orchestration frameworks. They don't have the sense of a knowledge graph. There's no notion of agents and identities.

So do we still have a lot of work to do on the plumbing to realize this vision? I think so. At the end of the day, if you think about it, AI needs knowledge, right?

You have the ability to take inference and do comparisons against a knowledge base or an LLM, but you still need access to the systems and services, and something you can apply it to. There's constraint in terms of compliance, there's constraint in terms of governance. Are companies happy to do that, or are they worried about their information going out to a public LLM?

Do they want to constrain it internally? We can have little roadblocks and barriers, but we've been through this. The migration to public cloud.

You go back 15, 16, 17 years, there were banks that said they would never touch public cloud. There are now banks that use them entirely. Mm-hmm.

It's a case of like any new technology. People will use it. You'll start to build trust.

You'll start to see, okay, I need to do certain things to enable this tool. One of the things that's beneficial from us is we provide a lot of those tools within our application stack and framework. So you don't have to go elsewhere to buy those pieces.

You implement it and go. So that gives me an advantage that I get it from the product set. Yes, it will take time.

The model you described first is the typical one. It's you use AI as an assistant to you, as a tool to help you do your job, but you're still the one doing your job. Maybe it's checking your email.

" Some people have it write the response for them. Yeah, sometimes that's an interesting output. The real key is when you turn around and say, "Hey, I want to go do a thing.

" So for example, for us, we started off with a tool we use on our SRE bridges, where AI goes and looks at relevant data and presents it. The second iteration, it now only presents data specific to the problem we're analyzing. So it's not presenting data that we don't need to make it confusing, and it's starting to propose potential solutions.

So as it learns, eventually, you're going to let it run autonomously. And that's the big difference, where AI is not just your personal assistant, whether you treat it as a toy or you use it heavily to look after your entire life. But it's letting AI do things completely autonomously without you being present, right?

In some places, we're using that. Some people are using it more than others. To do this as a result.

There have also been some pretty big saves as a result. So the value is there. It's just ensuring that you have a governance framework, and you don't ask it to do more than it's capable of or before it's ready.

And that usually means before it has the information and knowledge to act in your environment, not because the tool itself is flawed. It's like anything. Did you train it properly?

Did you give it access and control? Right. And it almost seems to me that there's going to be different degrees of AI agents, some of which are extensions of the IT administrator or the engineer, some of which are performing a task autonomously on behalf of the whole organization.

And we're going to have to figure out how to have a meaningful conversation between these things so that they don't step on each other or, like my kids in the back of the car, wind up arguing with each other. Is that fair? It is, yeah.

I worked in AI maybe 10 years ago on a different model. Anything the human does, and you really can. What I suspect we'll see is rather than huge agents that do 50,000 things, we'll have lots of little agents, almost like a microservice architecture, doing specific things.

And those agents will call other agents when they want information or they want data, and they'll work together. But again, they need access to data. They need to understand context.

What kinds of things will they do? Everything. We have agents right now helping the sales team look at potential deals, look at what customers are looking for.

We have agents that look at RFPs to ensure, hey, can we respond to the things they want? So pure business. We're looking at agents in legal to assist on contracts.

Right? We have agents... Any task that a human does.

And maybe the way to look at it is any task that a human does that's repetitive, or any task that's critical that requires access and analysis of a lot of data, an agent could do. Whether you allow it to run autonomously or not depends on how well it runs, your level of trust, and the level of data that you give it, and also the potential fallout if it breaks. If it goes and breaks something.

But again, we have agents that respond to outages and issues. So if one agent breaks it, another agent may fix it. You'll go back and look at the audit and say, "Okay.

See why it took that action. " That's no different to a human. It's no different to training a human team.

The only difference is the agent will execute faster, so you need to be on your toes. Right. So what's your best advice to organizations who are rolling out AI and these agents?

Because, well, to your point, things do operate at machine speed, and it might be harder to undo things. So there's one way. One said to me, "It's one thing to be wrong.

" So how do I avoid that? The same way when you're training someone. Limit what it can access, understand what you want it to do, define it, learn how to use the tool.

So anyone who's not playing with AI, sorry, go play with it. Go build an app. Go build an agent.

Go think of a business function that you need to run. I would suggest immediately streamline that function and then go look at the agent building it, because they're less complex, the less chance it's going to go wrong. And try it in your test and dev environments.

That why we have them. Right? Pick a test environment you don't mind destroying.

Maybe you'll break it the first few times. That's okay. As long as you learn, and then the agent will get better and better.

And try it. And when you find agents that really provide value, it's like the light bulb goes off, and you start to realize, "Hey, it's not a threat. " And I think someone made the quote, I forget who, and I apologize for not knowing, but it's a very good quote, is that people won't lose their jobs to AI.

They'll lose their jobs to people who know how to use AI. So go learn how to use AI. And it's no different to when we went from mainframe to x86.

People thought it was a joke, it was never going to happen. Dominate the world. I mean, largely took over risk.

Virtualization, AI was a fun toy thing in the lab. Things are virtualized, and not long after that, we went to containers. Technology evolves.

AI is here. AI is now usable. One of the biggest challenges in AI 10 years ago was it cost millions and millions to even touch it.

You had to build an ontology. It took forever, $20 million to build an ontology to even have this little use case. Now you can tap in and use it against these large LLMs for a lot of functions.

Go use it, go try it, go play with it. Do it in a ring fence, make sure it's safe, and then try it. You'll think you'll surprise yourself.

We certainly have. The things we're finding that our customers are building in HAE, the things that we're building, we're seeing a huge amount of value from it. Now, you do have to think about tokenomics, right?

So bear that in mind. It's very easy to go off the rails. So think about how you control that, but start thinking about the outcome you want.

Don't build an agent because you want to build an agent. What is the outcome you want? Either business or technology.

Then work it back and understand, okay, what's the agent? What does it need to do? You can build them fast.

You can build agents really quickly, and you can build really useful tools really quickly. Go try. It's not that big, scary beastie.

It's actually quite a cool thing to do. All right, folks. You heard it here.

AI agents are here, and they might even be your next best friend. Whether you choose to give them a name or not is up to you, but ignoring them is a bad idea. Hey, Thomas, thanks for being on the show.

Hey, my pleasure. Have a good one. Be safe.

All right. And back to you guys in studio.