KubeCon 2026: AI Agent Security, AI SRE and the Governance Gap

Hey everyone. Good morning, good afternoon, maybe even good evening. I don't know where you are in the world, but I'm here in Salt Lake City and you're watching Techstrong Gang on Wednesday.

I'm joined here on Techstrong Gang with, well, these are a couple of our usuals. He's not up in New York though today, he's live here in person in Salt Lake City, Mike Vizard. And then joining us on our far left, he's a regular on the gang as well, analyst from Futurum Media.

Is it- Chief analyst at Futurum Media ... chief analyst at Futurum Media. Congratulations.

Thank you. Mike Kercher, welcome. Thank you, guys.

So, gentlemen, I got to tell you, I loved the buzz yesterday, the vibe coming... I'm not talking about vibe codec. But the vibe from the show yesterday, I felt a lot of energy.

The show floor goes on for what feels like ever. I don't know how many booths there are, but it's a big show floor. But it's filling up with people.

I also understand the sessions are pretty crowded. Mike, we spoke about it a little bit yesterday. According to CNCF, 40% of the people here are first timers.

Yeah, newbies. Which- But you know what? I think they bring the energy.

That's not unusual, I don't think. No, not for KubeCon. I remember a similar story kind of last year.

At Atlanta. There's a lot of shows I've been to this year that seem bigger than previous years. Not so much here, but I agree with you totally about the energy, and my sense, and Mike, I probably interrupted your- No, go ahead ...

your answer, right? But my sense, and I'm going to post about this later today, is the energy really has to do with all of this stuff getting more real than ever, more mainstream, bigger brands like Nvidia really jumping in, contributing, taking part, sponsoring more than we've really seen before. And also this sense of reality of we have enough experience and enough technology developed under our belt now that we can really start spreading this around instead of it being...

I wouldn't say it was ever esoteric. Mm-hmm. But we're talking about this.

I've seen more and more solutions applying to almost any enterprise scenario, and that's pretty new to me. I think everybody's here trying to figure out the same thing and it's we have these AI workloads now. Kubernetes is like the natural target for those workloads, but those AI workloads don't behave like any other workload you've ever seen.

And everybody's walking around trying to figure out, well, how do I manage this stuff? How does it work, and what are we going to do about that? And they're having the same conversation, let's jump into this first topic here, that they're having everywhere in the world, which is how to run these AI agents safely.

So you saw Nvidia this week contributed OpenShell to the CNCF, and then there's a bunch of vendors talking around how do we run these things safely? And Teleport's here talking about an ability to only give the agent privileges at the time that it's invoked as opposed to giving the agent some long-running privileges that they can then use to go and essentially go rogue, right? And to me, it's like we are all collectively living in an experiment together because we don't know how all this stuff really works, and we're all trying to figure out.

And there's a bunch of big tech companies that get it, and they can kind of throw all these engineers at it and they understand it, and there's 12 of them. " Well, let me channel Alan real quick and just say, let's get real here, because those 1,200 engineers you're talking about may think they get it, we may say they get it, but nobody really gets it yet. I agree with you.

Mm-hmm. I agree with you. I don't even think they get it.

I think they talk a good game because they don't want to be perceived as sort of not getting it, right? Oh. Which is the opposite of getting it.

Oh, you mean you don't think that people who deploy AI agents without network segmentation don't get it? I'm shocked. Well, so a lot of them are, but we have to remember that's not sufficient.

OpenShell's a good example of it, and I'm not knocking, I don't think any of us are knocking the really terrific engineering work being done and that I'm not saying it's not a step forward. It is a step forward. OpenShell and its contribution to the Linux Foundation, and open sourcing it is a great step forward.

What we're talking about really is we get sort of the first stage set of problems. Uh-huh. Sandboxing being like really important step forward.

But it doesn't take a whole lot of analysis to see that there's a whole lot of additional vulnerabilities simply through the unpredictable, let's say, action of AI. So it's not the solution yet. Right.

It's the step into the solution. That's all I'm really talking about. And it's- We just need to maintain awareness of this.

Knowing that there's a lot we don't know we don't know, it would be really helpful for everybody to- And I'll give you two examples ... to either fix that. Everybody's throwing around the term sandbox like it's something.

Walking around the show, I've encountered at least five different flavors of what a sandbox could be, and it can be anything from the container to the VM, to the micro VM to whatever this gVisor thing is that Google's talking about as well. Yeah, and nobody seems to have a handle about what the sandbox environment should look like and what it's going to take to secure these things. And then I was talking to some other folks and it's like not all AI agents are created equal, and some of them are on a spectrum, and there's like an AI coding agent is at the top of the spectrum in terms of its capabilities.

But most of the AI agents that your average enterprise are going to deploy are a very narrowly defined set of functions, and they don't need the same level of, per se, sandbox and security and everything that wraps around it. And so people are trying to figure out, I think soon we're going to see categories of AI agents that people are going to come up with, with different best practices for deploying and managing them. So let me give you the Shimmy take on this.

All right. I think what you guys are saying about AI and agents, we could say that at every single tech conference we go to throughout the year. It's the same story.

We're all dealing with what the heck to do with these AI agents. What brings it home for this show is the fact of it matter is all of these agents and the infrastructure they're running on, 99% of them are running a Kubernetes based stack. Huh.

So now this becomes the home of that agent stack, right? " AgentCon. AgentCon a couple weeks ago.

Mm-hmm. A lot of buzz around that event. I'm sorry I missed it, but I think it's important to remember that this community, this stack, the cloud native stack is the AI stack.

And that's why people are here looking for solutions to this stuff. Right. I think it's too early for solutions, quite frankly.

I think we're all sort of wandering in the wilderness of Sinai or whatever until we can find the Holy Land. But how does that make it too early for solutions? Like, one of the- I don't think it's baked.

I think things are changing so quickly. Yeah. But we all want to take advantage of it.

We want to move. Yes. And frankly, as the perpetual story, the main factor, the main risk factor is the human factor involved, right?

So if we are paying attention to that, like one of the bits of advice we're trying to give customers right now at Futurum is do something. Don't get caught in decision paralysis. Just focus on what you think you're going to accomplish.

I got a headline for you. They're all doing something. Everybody's experimenting.

Right? No one- Fair enough. But the decision paralysis is what do we do?

Which one of the thousand options? Well, the decision paralysis is, is what we're doing right? Mm-hmm.

Yes. Is there an ROI? Yes.

Am I opening myself up to a huge security incident? Am I going down the right path? But make no mistake that the train's left the station.

Right. But there's two big problems that people are trying to tackle, and they're talking about it here at the show. One was this framework that Google donated to the CNCF- Yes ...

a couple of weeks ago because Kubernetes wasn't designed for AI agents, and you can't allow an AI agent to lock up an entire pod because the infrastructure consumption will go through the roof. Mm-hmm. And so we won't be able to support that.

And then other people are talking about maybe we need to reinvent Kubernetes for this agentic AI era. There's CIQ is talking about a streamlined version of Kubernetes that they built, and I- And you know what? Rancher had K3s or was it K4s?

Well, those were, yeah, those were lightweight. That's not quite the same thing. We've been re-engineering Kubernetes for 15 years.

Well, yeah, and the Edge has been doing it for a little... Yeah. Well, why?

I think that this has become a more urgent issue because I don't think Kubernetes was really designed for AI agents, and it needs- Well, let me give you a factoid. Just because a Google, an Nvidia, or someone donates a project to the CNCF or the LF, doesn't mean it works, doesn't mean it's fully baked. No.

It's a work in progress. Almost by definition, actually. It is, right.

That's part of the whole point. It's not graduated. It goes through the whole- Yeah ...

process of an open source project, life cycle of an open source project. Now you come to an interesting point. I think- Thank you.

" Yeah, but that's Guy's point. So that's the human- Mm-hmm ... right?

Yes. The human element. Yes, exactly.

And I think that there's a bit of a scoping issue here. Mm-hmm. Which is to say, and that's more or less my decision paralysis point, which is first of all, the humility of knowing that there's a lot you don't know.

Mm-hmm. And second of all, saying we can't really know which step is the right step to take. Now I'm thinking in terms of enterprise.

It applies to an open source project just as much. And maybe that is also where there's this culture clash because I can see what you're talking about. The way open source programs since forever have been formed have been deliberative, inclusive- Yeah ...

consensus-based, all these human things that take time to play out. Yep. They don't- Fortunately, hold on.

Fortunately, and I think people sling arrows at the Linux Foundation and some of these other foundations for being overly commercialized in some ways. I don't take that as a critique at all. I don't think it's valid.

I think actually in this kind of case, that's the right kind of collaboration you're looking for because there are companies that are going to move, and they're not just big companies like Google and Nvidia, and contribute to open source and keep things moving along. I'll counter that. That's not a bad balance.

I'll counter that and say, look at Linux, where you essentially have a benevolent dictator who kind of drives all those decisions and responds quickly to change and needs and things that occur. And then I look at all these other projects, and they are run by a committee, and we all know who designed the committee and what they create. I want to challenge that.

I want to challenge that. Unfortunately, you people, what you're seeing the background here, there's one, two, three, four, five, six, seven, eight, nine, 10. There's about a dozen booths right in this row, and these rows go on for what seems like forever.

And I'm going to tell you that at 75% of these booths, you have a commercial entity who's built around an open source project. Exactly. Yeah, you're making the point I was going to make.

Yes. Great minds think alike, Don. Yeah.

Well, so we meet with these folks. " Right. Where's your value add over that?

What are you doing? Right? Yeah.

And sometimes it's tooling. In other words, more coding, more software. Sometimes it's services.

Often it's a managed service of some kind. So, you can do it yourself, we're going to contribute. You can come to us, you're just sales pipeline to us, and I had a vendor say that to me yesterday, if that's what you're going to do forever, more power to you, but at some point or other, you're going to turn to your own core business, whatever it is, and it's not software development, and that's where we're going to step in.

And it's not committee-based really. Committees are consensus around what a whole community is doing. Each member of this community is just acting on their own, man.

It's capitalism. What do you have against capitalism? There are people walking around this conference saying the following.

They're saying that some of these committees are too stacked by engineers who represent vendors, and as such, they don't make Kubernetes easy enough to deploy on its own because now I got to go buy an extra service or an extra tool or something from a vendor here when the natural process of the thing would be for the TOC to kind of work a little bit more on making Kubernetes more easily consumable, shall we say. You know what? People have been b******g and moaning about commercial interest in open source since the day open source was created.

I think the fact of the matter is the foundational model is the best thing we've come up with that lets otherwise competitors cooperate together, coopetition, and brings together a community. Is it perfect? Is there still money buying influence?

Yes. Mm-hmm. But it's a hell of a lot better than what we had before when you, in essence, had one company that owned, the big brother model.

That company owned that project. Are you saying democracy's messy, but it's the best government we have? It's the best of the worst.

Yeah, that's a good way to put it. But I think that to me, the story has been, and I haven't seen it here yet, but the story has been the stress put on the community managers. And the need for sponsorship of the community managers so that they can, or project managers if you will, so that they can do their work without worrying about their lifestyles, their compensation, and all that other sort of stuff.

That is a focal point to me to make all of this work go better because they tend to be over... And certain projects are small but extremely important to certain groups- Yes. We know that ...

where there isn't funding for those folks. Absolutely, and- That's something I would push on because there's lots of areas for improvement. But the model as a whole seems good.

Now let me tell you something. But an issue I've heard here from several people now is that with AI increasing the pace of code submissions- Oh, yeah ... vulnerabilities- Yep ...

and all of this stuff, the system is breaking. It can't handle AI scale, and that's something that the Linux Foundation CNCF is going to have to come to grips with, as well as these commercial entities. If they want these foundations and these TOCs and so forth to go forward, they're going to have to fund them better.

Not all the maintainers are the same either. The maintainers of Kubernetes are all funded by a large company. That's why I focus on the smaller projects.

Yeah. Most of the projects are a couple individuals who are getting overwhelmed and don't have the resources to go do that. There's 250 odd projects here.

Yes, there's the hotels and Kubernetes, and we tend to put in a lot of focus on them. But again, walk to the hundred booths that you see here. There's a lot of projects.

But you know what? We need to move on to our next topic, and as we've been doing here at Kubernetes, at Kubernetes, at KubeCon, we're going to bring in, we're going to go out to the bullpen, call up for the right-hander. We're going to bring in our friend Tucker from Nesmo, and we're going to talk about some more stuff here.

Give us a second to rejig our set. You're watching Techstrong Gang. Hey, everybody.

Welcome back to KubeCon + Cloud Native Con, and we're playing a little bit of musical chairs, so let me welcome Tucker. How you doing? Hey, great.

Thanks for having me. Welcome to the show. Yeah.

And we're going to have a little chat about AI and DevOps and what's going on because you may find it surprising, but there's probably, I don't know, 100 announcements related to something to do with DevOps and AI at this show, and one of them I'll just call out is Cloudsmith does a thing where they're putting AI skills in a registry so that people can reuse that safely and not have all these things poisoned, and you guys have some stuff that you're working on in this space as well. Yep. And so there's this term now being kicked around, AI SRE, and nobody seems to know exactly what that means, though.

Everybody kind of nods their head and says yes. But from your perspective, what's going on and how does all this kind of feel different from what we did before? Yeah, it's an interesting one.

I think actually as in the vendor landscape, we all don't like the term. I've heard that. Which part?

SRE or SI? SI. Yeah.

Yeah. But I think we can't come up with a better one yet. The way we think about it ...

is increasingly more about production operations because an SRE is a role, and we're really thinking about how do we use AI to manage production operations autonomously. What's interesting about that, and as it relates to the skills registry, which we're a big fan of, the skills registry is really giving you more individual capabilities and helping improve the consistent state of individuals. But when you talk about the AI SRE concept or production operations, it's really a multiplayer game.

And so it's really more about how do I take a group of individuals and allow them to work together in a multiplayer way against production, which is super important because we are shipping more and more code that we don't understand into production, but production is still gated by human understanding. So to me, the term is like, how do we get prod caught up with dev to a point where we can scale production beyond human understanding? I have felt, and I think I even used this word last week at AI Infrastructure Field Day that the Futurum Group- Oh, okay.

Yeah ... puts on. Right?

Yeah. I have started to feel like AI, writ large, but the coding side in particular- Yeah ... is just kind of a Mandelbrot set of generation, if you like.

Yeah. And this is an example of that to me because there's so to speak, the content of what's being generated by your AI system as an- Yeah ... enterprise or an organization.

Yeah. Then there is the management of it- Yeah ... with its elements of AI to ensure that this code is inspected- Yeah ...

and it's proper- Yeah ... and it doesn't go into the library properly. But then there's the next set, which is the happy home and safe and secure home, which- Yeah ...

where we start to touch on the site reliability engineering- Right ... head of platform engineering. Yeah.

And I feel like that just goes on and on and on and on. So, where's the dividing line now? I think there's a big dividing line.

Especially if some of the code that you're generating is to manage the code that's being generated over here. Yeah. The interesting thing to me is I think the dividing line is really around the deploy.

And what's interesting is if you think about a- Deploying to any environment, just to be clear, through the life cycle. Through the life cycle, yeah. Starting with sandbox, ending with the- Yeah ...

old version of the word sandbox and ending with prod. The old version of the sandboard- Yeah ... yeah, into prod.

Because what's really interesting, this is kind of obvious, but sometimes stating the obvious is really helpful. There is a governance process that has existed for 40 years to get code into production safely. That's getting automated, but it hasn't fundamentally changed yet, right?

And so- Right ... when AI creates a file of code, it is deterministic from that point forward. And so the blast radius of that change being right or wrong as it goes through its governance process is virtually zero.

You can roll it back, you test it, you use Grep tile, you do all these things along the way to get it to a deploy. If now if you're trying to run something in production that you don't understand, and you're counting on AI to understand, when you hit that button to restart that pod, that is real life, it's ungoverned at that point. And so to me, I think that we move from this world of individuals getting incredible productivity gains and the skills where the skills play in, but then when we get into production, we have multiple people deploying, we have multiple people making changes, and the systems that sit behind the skills have to accommodate for a multiplayer environment.

Mm-hmm. And one of the challenges I have with the SRE space right now is I feel like we are trying to serve this group of builders, the SREs and the platform engineers, by giving them opaque contained outcomes, like SaaS solutions, for them to get AI SRE capabilities instead of giving them the building blocks that they need to build critical infrastructure. The people need to assemble and own their critical infrastructure in a multiplayer way, not just consume it from someone where they don't know what's really happening.

So the part that I get confused with, so if I look at the old way- Yep ... the DevOps loop. Yep.

And to your point, it was a fairly structured process of moving from left to right. Mm-hmm. In the world of AI agents, it seems to me like more of these things are now happening in parallel with each other.

It's not nearly as sequential in that these AI agents are doing various tasks continuously at the same time, and the cognitive load of managing that is going to be hard. It's impossible. So, if you go to our website now, it says we have to scale beyond human understanding.

Because we're basically in the cycle. The cycle's kind of working the way it's always worked, just really fast. The problem is the things it's deploying, we don't understand anymore, or we don't understand it in the depth that we do when we used to handcraft these things.

Right? I think there is still understanding, but the depth of that understanding and figuring out all these interdependencies that you have in a production environment are really hard to do now. And so we have to actually leverage AI to do that.

You can't develop with AI and not run production with AI. It has to go beyond what a human can understand because right now we're basically shifting, we're using AI to suggest RCAs, to make recommendations, but it's still gated on a human. Right?

A human still has to look at it and say, "I understand what's happening. " And that's just not going to work when you have this avalanche of code coming your way for production. So I have a bad feeling in the pit of my stomach about this first rev of generation of all this because I talk to people and a lot of them are saying, "I'm overwhelmed.

I got too much code. I can't review it all. " And that seems like a recipe for a bad thing to happen.

Yeah. Something bad's going to happen. It's going to happen.

Can I pile on that just a little bit? Yeah. 5 moment in late- Yeah ...

2022, has been that the advantage here with AI is actually not quantity, it's quality. It's not productivity, it's quality. You can measure productivity as, for example, number of cycles through- Yeah ...

a given bit of code before- Yeah ... before the push or pull, right? Yeah.

But that in research, in testing, in like all kinds of ways, you can do a whole lot more with that piece than before, and I'm just wondering if this massive quantity, that pressure for massive quantity is just the wrong focus. Could be. Yeah, it very much could be.

I think one of the things we're going to see, either via the improvement in quality or the increased velocity, is the nature of an incident is going to become more and more complex. Right? So if it does what you said, we'll probably have fewer incidents, but the incidents we have will be infinitely more complex.

Which is a good thing. Right? We had this interesting conversation with one of the SREs from Google, and the increase in incident time in a way is actually a positive, assuming that it's because you've solved all the easy ones already.

You know what I mean? Like you could- Yes ... you're automatically solving the easy ones, so necessarily you're getting more novel failures, and that is much harder to solve for.

And so that could be true. And it- Can I just say that that sounds a lot more fun? Totally.

Yeah, it sure does. For the humans involved. Yeah.

Yeah. I just want to say that. Yeah.

Like granting the seriousness of breaches and security issues- Yeah ... that's kind of what we want, is an up level of our human activity. So- An up le- yeah, so I very much agree with that, and we very much think about how do we empower people to...

Like this kind of notion that some of these roles are going to go away is ridiculous. We're actually empowering these roles to be more productive, to think about more novel failures- Mm-hmm ... to think more ahead, and take away some of the routine work away from them and give that to agents.

But the very hard thing is, how do you set policy for that? So one of the things we've created as a runtime policy enforcement, so that as the agent goes, it can go check policy in real time and make a decision, can I elevate my authority to be autonomous, or do I need to downgrade it based on the current state of the system? So.

So, what is the role of the software engineer look like going forward? Because I've talked to some folks, and they're fairly advanced, but they're describing a world where they're building a software factory using AI agents. Mm-hmm.

But the AI agents themselves, they're kind of like children. They squabble, they get jealous. If you don't pay enough attention to them, they go off and start doing things on their own.

That requires a significant amount of effort to manage. One of them tells me he has company meetings with his AI agents now to kind of define roles. Is that where we're headed with this?

Is every software engineer about to become a "manager"? I don't have a strong opinion on the dev side of it, but what I can say is I feel like this is one of those moments where the complexity that exists in the world is the complexity that exists in the world. And if you shove it down from one area, it's going to blow up in the other.

Mm-hmm. So there are wild productivity gains we're going to get, but then there's also so much we need to manage about that. So if you have all these agents doing all these things, you've got to manage their memory.

Right? You can't just leave their memory... Memory poisoning, if you've done anything on over any period of time, like the things that my agent thinks that I think, or like I just ask it a random question, and now all of a sudden it has this whole opinion about me, and I don't know how to get that memory out of there.

Right? And so that's one of the things we've built, too, is in order to do this... So that you shift, though, you shift from doing the work into, I need to manage the memories.

I need to manage how they think about semantic and episodic memory and things like that. So while you might be guiding those agents, it becomes more complex in the sense that I need to very carefully curate the brains of those agents all the time. But isn't this a human problem again?

I mean, isn't this partly like what your company's doing? Yeah. Which is to say that a lot of times what we wind up advising customers and vendors is- Mm ...

your people need to do X, Y, and Z better. Ah. Because when you describe that memory problem, I'm like, well, you got to tell the thing not to remember that anymore.

Yep. Right? But to do that effectively requires a certain skill level in prompt engineering, if you like.

And I think what vendors like you are trying to do is to take some of that requirement out of the workforce, so they can just do their work and institutionalize it. Right? Give them the systems that they need to do that, to have systems work on their behalf.

Right, so that they can- But it's still a human problem. It... Yes.

Right. But even if I tell AI agent not to remember something, this other AI agent that it talks to does remember that thing. In fact, they left messages for each other, and it just relearns that thing over again.

And that's exactly why I talk about it as a multiplayer game versus an individual game. Mm. Mm-hmm.

Right? So, like our memory service, let's say you have five agents working on prod, we don't let them generate their own context. We curate the context, and so that context is created consistently- Right ...

and distributed to the agents. So you can't get... If you're doing an individual work against a shared environment, that's just not going to work.

Right? So you need to curate the context to ensure the context is engineered for all agents equally, that the memories are shared and things like that, so that when you improve a memory, you improve it for all the people working on prod. This is what I meant by an institutional- Yeah ...

solution. Yes. Instead of a everybody needs to learn better how to do these things- Yes ...

solution, which you can't rely on as an organization. Yeah. Guys, we got to move on to our next segment, but I would just say a theme for the day is starting to emerge, which is there's more unknown than known.

So thanks. Thanks for having me on. Yeah.

Yeah, nice to meet you. Yeah, that was great. Yeah.

All right Hey, folks, we're back here at KubeCon + CloudNativeCon North America 2026. Boy, that rolls right off the tongue, doesn't it? Bang plant.

We are here talking about, and again, AI agents. Our friend Abhinav's joining us from SUSE. Hi, Mike.

How you guys doing? We were talking in the last two segments about AI agents and how to manage them, and how the function of an SRE is going to change, how the function of the development team has changed, and there's more unknown than known. But what's your assessment of what's going on here?

Because a lot of these workflows on the IT side are deterministic, and a lot of the AI agents are probabilistic, and we're- Yeah ... trying to marry these things together. And, I need the IT thing to be done the same way every time.

Yeah. That's absolutely correct. Let's take a step back.

Everyone has implemented chatbots one way or the other in their organizations. Now, in my view, the era of chatbots is over. It's how you implement autonomous agents to deliver productivity in your environment.

And these agents, unlike chatbots, can do damage because when a chatbot goes wrong, you'll probably get what? A poorly written paragraph. When an agent goes wrong, we're talking about failed deployments.

We're talking about leaked API keys. We're talking about another thousand agents also doing something wrong. Something same.

Yeah. Exactly. And then comes the whole conversation around sandboxing, which I believe is absolutely essential.

NVIDIA donated the OpenShell to CNCF. SUSE, from our perspective, we've integrated OpenShell with SUSE AI Factory to ensure the isolation of these agents is controlled. So sandboxing is absolutely essential.

That's one way. Now you extend that. That's not, in my opinion, enough.

You extend that because sandboxing caps your potential damage. However, you also need to know exactly what happened and why it happened in the first place. So you need to have an ability with these agents, one, a hundred, a thousand, to trace, to audit who performed an action.

What kind of authority did they have? So I think that's the era we live in, and that's what we need to work for in this industry right now. We were just talking about this issue about the memory of the AI agents, and part of the challenge seems to be, A, once they learn something, they don't forget it, and sometimes we want them to forget it.

And other times, when we tell them to forget something, the AI agent talks to another AI agent and relearns the thing we told them to forget anyway. Yeah. So how do we manage this thing and wrap our arms around that?

Yeah. The way I think it is, I abbreviate to a four-verb test, which abbreviates RAMR, replay, audit, move, and patch. As a CIO, when you are thinking about implementing agents in your organization, you need to understand whether you have the ability to do all four of these.

Let's start with the first one, which is replay. Can you reconstruct exactly what the agent saw, which model versions it ran, which tools it invoked? And to your point, Mike, you may not get the same identical output every single time.

It's not deterministic. However, you need to focus on replaying the execution flow, much like a flight recorder. You don't refly the plane every time.

Instead, you inspect the black box. Well, let me see if I can clarify this for me. Yeah.

You actually don't know what runs- Yeah ... by the nature of this system. Unlike three years ago, let's say, you don't know the sequence of steps necessarily because that's being determined by an agent to begin with.

So you need to be able to know what those steps are and be able to replay those exact steps- Exactly ... as opposed to the next run that might follow different steps, even if for the same purpose. Exactly.

Okay. Precisely. Because inevitably, when something goes wrong, your organization's auditor is going to ask what exactly ran.

And if you have the ability to replay, you can answer that question. So that's part one of the four-verb test. Part two is audit.

Do you know which agent acted and on whose behalf? Right? Because at the end of the- Or what's behalf.

Or what's behalf. Exactly. If you look at the standard audit logs today, you'll see effectively a general service account indicating that a pod performed an action, and not necessarily telling you on which agent instance's behalf it did that.

Yeah. So your postmortem logs, if you think about it, they end up concluding that something with elevated rights performed an action. So that's the second thing from a CIO's lens, the RAMR test.

Replay done, audit done. The third angle is about move. So today, do you have the ability to move your entire stack on a completely different cluster, in a completely different environment, even on premise if you need to, next week?

And to do that in the world of agents, you need to ensure actually that your models, your weights- Yeah ... your container policies- Sure ... your governance policies, they're all portable.

Data. Yeah. Exactly.

Yeah. So are we talking about, I'm going to have a small army of AI agents performing tasks- Yeah ... and I don't think a human's going to be able to keep track of that, so I'm going to have another set of AI agents that are essentially performing the governance function and monitoring those AI agents, and it's a checks and balance kind of thing?

Somewhat. What you'll see is, one, MCP gateways coming into play, which will start governing, at the end of the day, what your agents can do. So what can they do?

Who can they reach? On whose behalf can they act? On who stops them?

When does a human come into the loop? So you'll see a whole thread of agent governance come up in the next... It's already being talked about right now.

It'll come into mainstream and production environments in the coming months. So you guys at the show were talking about, you already have Liz, which is kind of an AI interface or an assistant. Yeah.

And now you've added an AI crew, which is a bunch of agents that sit underneath that, that perform a specific task. How big is that crew going to get? Yeah.

So from Suse's perspective, the technologies that Suse brings to the table, whether it is around observability, whether it is around security, we've enabled Liz, our assistant, to interface with them. So that's one part of the agentic crew. At the same time, we've also enabled Liz to talk to any MCP endpoint.

So from our customer's lens, if they have their own MCP servers that they would like Liz to drive automated actions with, they can connect it to the Liz, and then the army of agents is actually our customer's choice. If they want an army of 10, if they want an army of 100, we allow them to scale. That's how we've built the agentic crew with Liz.

All right. Will the agents, are they going to live forever and we're going to give them names, or are they going to be more intermittent and come and go because over time they get new skills and new capabilities? How does that kind of flow?

Which agents are we talking about? If I have an agent that's assigned a task for observability, say, at some point, that AI agent that I trained, its skills start to fall off because- Drift. Yeah ...

there's drift, there's also new capabilities or the environment changes. So how dynamically am I kind of retraining the AI agents and should I get attached to them or should I consider them to be more like cattle than pets? Yeah.

So I would consider them more like cattle than pets. So that would be my- We all want them to be more like cattle than pets. How do we ensure whether they, whichever one we bucket we put them in, we need that cattle-like control.

Yeah. You know. The way I see this evolving actually is that we need to start treating CIOs and IT teams, will need to start treating an agent force like their human workforce with identities, with supervision, with controlling and tracking what they can access, how they can act.

That is the way I see this going forward. Mm. And those organizations who are able to scale this in a safe manner by providing the agents the right identity will be the ones who can actually win and who can actually see return on their investments that are going to put in.

That's my take. So what does the future of the IT department look like in that construct? Because today we've got IT administrators using GUI interfaces to manage VMs.

We've got DevOps teams with programming skills to manage infrastructure and the application development, and I even have a hierarchy above that, platform engineering teams that are doing stuff with DevOps at higher levels of scale. Does that collapse? Does that stack become flatter, or what does it look like?

So my view on this, Mike, is that your current platform teams will have to be upskilled, and they'll start becoming a governor of agents. And this is the way that it's going to move towards. So it's not like, because right now the reality is that there is a shortage of talent, there is a shortage of skilled workforce who can actually implement this at scale, at enterprise level, in a safe and secure manner, in a cost controlled manner.

So you'll not get, in my opinion, a skilled workforce that you can hire on the spot for hundreds of enterprises tomorrow. So you'll need to reskill your existing platform teams who'll start to act as a governor of agents. That's where we are headed, and all CIOs and IT leads should be thinking on how can they upskill their existing workforce in order to tackle this situation of tomorrow.

Well, let me ask the same question as a little bit of pushback on that, just to maybe uplevel the strategy here. Because one of the trends right now in coding specifically, or software engineering specifically, is a bit of a decline in demand for the software engineering side and an increase in demand for the product manager side of things. Mm-hmm.

And when you think about the core functionality of a product manager, you can call it strategic, that's vague. The idea is setting requirements, figuring out how to approach them, prioritizing them, ensuring an appropriate architecture, all of those sorts of things that can create a good, in this case, application. Mm-hmm.

Or, yeah, application, I guess, is the right word. Mm-hmm. I don't see why you can't generally apply that.

It's not upscale, upscale is one way of putting it, but- Yeah ... wouldn't you see that whether it's in SRE platform engineering, IT operations, or what have you, this sort of, let's call it a product approach - Yeah ... product development approach- Yeah ...

might be more like what we're talking about. Yeah. An orchestration of human and non-human and technological resources.

Yeah. So what are the odds that a product manager is going to have the foundation in good software engineering practices to execute that without a software engineer? So what I've seen is that I'm seeing the number of developers in an organization may go up and down, but more organizations seem to be starting to realize that that whole back end isn't going to magically happen on its own, and the product managers are not skilled enough to understand how the IT workflow works.

So I think that the current structure stays, but the roles change. I don't know. Yeah.

I think there'll be a balance because what you said directionally, I tend to agree What you said, I also tend to agree with. So there's a balance, and what, how I see- I'm saying this is a quantum question, and two things can be true at once. It will be, and here is why.

Because code creation today, it's not difficult. It's easy, and that's no longer the bottleneck. To your point, anyone could create an application.

With the right logic, you can write code good things today. That is not difficult. What is going to be challenging is how you scale that safely and how you maintain what you have created.

How do you ensure the security of the supply chain of what actually went into that code, and do that at an enterprise level? And that is where things start getting trickier. Yes.

That is where the roles of the platform teams become important and relevant, however, with a different skill set. That's how I see it. Do we need to maybe take a breath?

" And then I feel like there's two gates starting to show up. One is, we have security issues, and we need to clearly resolve that. But third, and I think what people aren't really talking about, the rate of change is accelerating to the point now where I think many organizations are unable to absorb new features and new capabilities into software systems every other day.

Yeah. So, at what point does this thing kind of get where the velocity is too much, and we need to kind of throttle? Yeah.

So, I was talking about the RAMP test at the time, right? Yeah. Remind us what the P is.

The four-part test. Yeah. Yeah.

And this actually is an excellent segue, and Mike and I didn't talk about it, but this is exactly where the P comes in. The P is the patch. Patch.

Exactly. So when a critical vulnerability hits our kernel or runtime, how long does it take for a team to completely update their fleet, and who controls that timeline? And now comes the part of speed.

Most organizations, even today, have scheduled maintenance windows where they update their environment. That is the reality of enterprise organizations today. However, in this era of long-running AI agents that can hold sensitive credentials, that strategy will not last long.

So at an organizational level, companies will need to start thinking on how can they evolve and get more nimble in protecting and patching their environment. And as I see it, most organizations today do not pass all the four tests, replay, audit, move, and patch, simultaneously. So that's a take on what we just discussed.

I think, to some degree, we were more like talking about, again, the human factor, scope of expectations. There is a market pressure, essentially, to produce more faster. If you are a first mover, there's a general feeling that that's innovative, that is differentiating, that makes you stand out, whether as an individual or as an organization.

Yeah. So, what you're talking about is a way to manage the speed. I think we also need to acknowledge that speed is something to measure itself as well.

So the faster you can go safely and well, great. Yeah. But I think that was more...

All right. We got to end this. I want to thank you for coming by.

Thank you. Yeah. Thank you.

It was a pleasure. I would also just point out, the faster you go and the more you hit something, the more it hurts. So just keep that in mind.

And you say that from experience, I assume. There you go. Great way to go out.

Hey, I want to thank you all for watching the Techstrong gang today. It's been another special edition from the show. We'll be back again tomorrow with some more guests, and we'll see you then.