Kubernetes, AI Agents and the Future of Platform Engineering

Hey everyone, welcome to Techstrong Gang live at KubeCon. We don't always get a chance to do it live while we're here at KubeCon, and then we have to figure out who's speaking when. And then you go from nothing to everything.

So we're going to do it a little different today. We have different people on each segment. We've got Mike Vizard warming up in the bullpen.

Getting that right arm ready. com, our friend Luca. But for our A segment, I want to introduce you to my good friend Rickey Zachary from Thoughtworks.

Ricky, welcome. Thank you. And my friend Sean O'Dell from Dynatrace.

Sean, welcome. Glad to be here. Thank you for being here.

So guys, look, so much going on in the world, but I wanted to open up today's Gang talking about yesterday's breakfast. We called it Futurum Summit. It's the first time we've done that.

Yeah. We combined Techstrong, the Tech Field Day, the Futurum media brands with some Futurum analyst stuff and kind of brought it all together. We had three great panels.

Yeah. All three panels get recorded. They'll be up on Techstrong TV.

But one of them we did was on observability and you were... No, you were on platform. Yes.

Sean was on observability, platform engineering observability, and then the panel I did was on cloud native stack is the AI stack. Yep. All three panels were amazing.

Incredible. Sean, let's start with you. For people who haven't seen the video yet, and they probably haven't because we didn't put it up yet.

Okay. Give them a what to expect from this video. Now, you know what's interesting is first of all, it was a great event.

I think, first of all, the food was good. Venue, I love the venue. It was very cool.

Don't get me wrong. But the content and the team, the panels themselves, I think it's actually what set the tone, right? I think opinions are important, but at the end of the day, there's commonality no matter what we're trying to do.

And I think as you get into the videos, be careful, you're going to be challenged a little bit, which I think was a valuable thing. But I think more importantly, we're all going through the same direction, same mark, but I don't think any of us know how we're going to get there. Yeah.

And/or what it's going to be like three days from now or three months from now. So it's good. Absolutely.

Ricky, what about you? On the platform engineering panel, me and Luca were really talking about this idea around how to accelerate adoption of some of these things, right? I think there's the building blocks.

I think CNCF is doing a great job of kind of filling in some of those gaps. Later on in the day, I was talking about agent gateways and where that looks like in that. But I think during the panel, I think it's really about how do we use platforms and platform engineering to kind of bundle these things up, provide the right abstractions to developers, and then drive adoption of AI, right?

With governance, with security, with the value proposition for enterprise organization. So I think we did our best job, right? Not knowing what's going to happen at the end of KubeCon in three days from now or three months or three years from now.

I think we did a pretty good job of kind of laying the state of platform engineering right now and how it leads to AI enablement and adoption. I agree. I think in my panel, the AI as a cloud native panel, I think the theme really was when you peel back anything that you're doing with AI, there's basically Kubernetes under the covers.

Yeah. And in a way, a lesson I learned years ago from my friend Brad Feld was 99% of what we do in tech is evolutionary. It builds on top of what came next.

And you have to ask yourself, would we be able to build these AI enabled applications as quickly as we have had we not had that cloud native stack scalable, distributed to build in on? And that was the takeaway. Well, I was going to say 10 years ago, I think it was my second KubeCon is probably what it was.

I don't think any of us saw where we would be today- No way ... with cloud native, with the ecosystem, with the projects that span anything from infrastructure to security and now obviously inference and so on, right? So I think that's the beauty of this evolution.

I think the second thing that's important in kind of the conversation is I would actually go back even a little bit further. If it wasn't for virtualization or even big data and ML, even if we had the cloud data pieces without that ML, without the big data, it kind of leaps and bounds, I would say I don't even know if we'd be there either. So it's almost a kind of dual prong if you want to go that approach, but it's been fun to watch over the past couple of years, especially from last KubeCon to this KubeCon.

Yeah. In and around that layer. Well, look...

Go ahead, Ricky. No, I was just going to agree and almost double down on that. I do think the virtualization stuff was an unlock.

I 100% agree with the data. I remember MapReduce- Oh, yeah ... all of those things, and it's just been kind of like this evolutionary build-out.

Yeah. And you're starting to see more and more of those projects, the CNCF projects, the Linux Foundation projects, kind of fill in those gaps and innovate incrementally. I think that that's actually important for the state of the capital.

Agreed. I think one of the things that I've already started seeing is everyone's adding an MCP server to their repertoire, every project. Everyone has MCP.

It's the new API, if you will. Here's something that's interesting, though. Last year, they made a big deal about A2A.

Yes. Right? As sort of an alternative to MCP.

Yep. I don't hear much, and I'm not dissing it. Uh-oh.

Don't get me wrong. Didn't know we were going there that quick. No, but I'm not hearing much about A2A.

And it's interesting because I'm still hearing small little bits about A2A, primarily in production workload. Yeah. And I'm not going to diss anyone, but I'm going to say something that is early KubeCons, I think it's very similar to the Kubernetes Docker Swarm- Oh, yeah ...

Apache Mesos kind of conversation where I think MCP has kind of won out on ubiquity, particularly in the developer platforms, the engineering platforms, where it's really an API under the hood. It's really easy to connect. Yeah.

Really primarily very easy to manage, and A2A is kind of relegated to that production workload. Oh, we might do multi-agent orchestration across, I guess I'll use A2A for some of the agent communication. I do think that that's going to probably get supplanted by something else as a hypothesis.

Again, by the end of KubeCon, that could end and we could start hearing A2A again. Oh, yeah. But I think MCP has become the ubiquitous way to connect agents to different applications at the moment.

So I don't disagree. I agree with both of what you're saying. But I think here's the real beauty and strength of this CNCF Linux Foundation community.

This foundation is big enough for both of them. Oh, yeah. They have a lot of places.

They'll have different service mesh. Mm-hmm. Right?

You have different service mesh. You have almost 250 projects. Exactly.

So it's big enough to say, "Okay. Here's this one, here's that one. Your pick.

" Yep. So that's an interesting thing. I want to turn back to observability, though, because I think, and I do this every year at KubeCon, we get so caught up in the Kubernetes and the Docker and the GitOps and that whole piece that we forget really how big OTEL- Oh, yeah ...

and observability have become. And one could say, well, observability was big before this AI, but you know what? Observability is playing an increasingly important role in the AI piece of this, too.

Mm-hmm. Yeah. I think we've been in this long enough.

We remember the APM days. Yes. And really, we're kind of still in the APM days.

We just have matured, and we call it observability, right? I think that's the beauty. I think that the hard part is with, if you go back eight, 10 years, when the whole OpenTelemetry, the CNCF kind of got behind it.

We're going to go to one standard. We're not going to have two different competing standards. It has helped, I think you talked about evolution, so maturity in and around observability.

I think that the core part is every organization, every developer I talk to now is, "I need observability with every application, and not just in production. " And so observability, I believe, is that next phase that allows us to go from what is the problem to hopefully whether it's an MCP or an agent, like we at Dynatrace believe in both human-led and agent-led, depending on your use case. But observability is that intermediary to make that next decision, whether it's me as a human or letting an agent do its thing.

I think that's actually important. I remember a couple of years ago, a couple of KubeCons ago, people didn't know what OTEL was. Yep.

People had this very scattered observability ecosystem. Oh, yeah. And it was just very difficult for them to get a handle around application observability, around traces or logs, all of those things.

I think if we hadn't had that maturity around OTEL, just think about adding agents into the mix- ... and you have this agent swarm. Oh, yeah.

So I think observability has become the leading indicator of mature organizations that are ready to make the launch- Yeah ... with agents. And then now we were talking right before this, we were talking about now we've got that solidified for applications.

Oh, yeah. What does that mean for agents? Does that mean we're adding in evaluations, we're talking about Arrive, we're talking about some of the other open source tools that are in the market?

0 with agents or something like that? So that we've got that ubiquitousness. And then the human-led portion of that that you mentioned, extremely important, right?

What's the place for evals? What's the positioning for how humans now react to that observability data within the agents? It's going to be a lot more complexity there, but I think CNCF is going to give the ability for projects to come in and the best project to win, right?

Yeah. The community is going to lead us and say, "This is working. Ah, this is not working so much.

" And I love, long time OpenTelemetry fan. Same. I think what the beauty is, is it's not just about logs, traces, metrics anymore, as you mentioned, whether it's the gen AI conventions, and I'm a fan of real user monitoring because I still believe that end users are very important in this conversation, right?

And so we continue to see advancements and improvements around OpenTelemetry, and I say let's all get on board. There are obviously multiple partners, multiple maintainers and contributors, and it's just been fun to watch and I'm excited to see where it goes. Yeah.

Absolutely. Hey, we got two, three minutes or so left. I want to turn to your panel now on platform engineering.

So there was a platform engineering day here yesterday, right? Yeah. Official CNCF.

A lot been going on there. And look, AI is disrupting everything, right? Yeah.

And AI is disrupting platform engineering- Very much so ... and forcing us to look at it differently. Yep.

Key takeaways for that. So from the day yesterday and from the panel, I think platform engineering started out of this evolution from, hey, someone's got to be managing the infrastructure, SRE, all of these things, and they need to be able to provide developers with the right interface to move quickly, reduce friction, all of those things, maintaining it as a product. I think the panel yesterday, two things have happened from the panel and from Platform Engineering Day.

Infrastructure is now expanded. It's not just application infrastructure. Yep.

Now it's agent infrastructure. How do we control MCPs? How do we control agents?

The front door for all of that agentic infrastructure, what does that look like? Is it going to be traditional IDPs or something that's vibe coded or a headless front door? Yep.

Where it's just, hey, your agents connect to the front door and your agents can do whatever they need to do. I think that that was one of the things that came from Platform Engineering Day, is this transformation of platform engineering to expand out. During the panel, one of the interesting things that we talked about was operationally that expanding to now talking about the value proposition and saying, "Hey, we have to make a case now about where and how platform engineering is going to accelerate AI through the organization," both from a developer standpoint as well as, hey, I've got to maintain these agents in production.

Yep. How does my platform engineering team support infrastructure, observability, security, governance, and then make an actual value proposition case for that? So we talked a lot about what is the value of platform engineering within an enterprise organization.

I think it's way beyond adoption now. I think we've passed that point, and now it's how do we marry all of these things together to actually get the impact that we want within an organization. Absolutely.

Very cool. Guys, unfortunately, we're at the 15-minute mark. We're going to take a quick break here on Techstrong Gang.

Sean, Ricky, thanks for joining us. Awesome. We're going to bring in the B team.

Appreciate it, yeah. And continue our Techstrong Gang here in just a minute. You're watching Techstrong Gang Live at KubeCon.

Hey, everybody, we're back at KubeCon and welcome to the second block, and I'm joined by my friend Ricky here, who was in the previous block, and we have a new player. Luka, how you doing, man? I'm good, man.

Good to see you guys. We're going to talk about a couple of the announcements at the show. So the first one up is this Red Hat thing where they announced Red Hat OpenShift 5.

And what's interesting about this is that it is connected to a thing they call Lightspeed, which is their AI agents. So now I can manage and provision my Kubernetes clusters environments using Lightspeed. Of course, it's the OpenShift flavor of Kubernetes, so it probably only works with their platform right now.

But my first question, I'm going to toss it to you. Go for it. Are we going to see AI agents become the new interface for managing these types of platforms, and will the complexity drop as a result?

And do we trust AI agents in the first place? Yeah. Very interesting.

Luka says he doesn't. I do think that we're going to start seeing more and more agent-based interfaces for managing a lot of these platforms, particularly because as an OpenShift user with some of the clients that I support, a lot of the interfaces for OpenShift are toil-based, right? I've got to write YAML, I've got to create templates, I've got to actually manage infrastructure, update things.

I think there's a lot of deterministic or semi-deterministic pathways where the agents can have very specific actions to take. Hey, write this YAML file, restart this cluster. I think based on the announcement from Red Hat, I think it's going to lead to more headless interfaces where agents are talking to other agents, and the human is just there for review, for guardrails, for interacting directly with the agents.

Instead of, hey, I've got to write all of this stuff and then send it to an agent. The agent can produce a lot of that content and manage a lot of the point-to-point tasks. Hey, I've got to restart things.

I've got to deploy in a very systemic way. I think the important part is what are the guardrails underneath and how do humans interact with those guardrails? I think that's where we're going to see that- And to your point, the agents don't always play nice with each other.

They don't. Right? They don't.

Yeah. As someone that's done that, it doesn't work all the time. Well, and I think we were talking about this yesterday in the Techstrong panel.

Ultimately, you can think about probabilistic paths, deterministic paths. There's what people are calling loop engineering, which is like a hybrid of both of those things. And I think what we said is, it's nice that now we can work with also non-technical business users, so-called citizen developers.

And they have their agents doing things. The problem is when you have agents compounding with agents. So if the way you manage your platform is also fully agent based and probabilistic, and then you have agents using paths on top of that, it becomes very risky.

" I actually think if you look at top-performing organizations that we talk with, it's 98% deterministic stuff that just harnesses around to make sure that you keep it under control. And one last thing about the Red Hat OpenShift announcement that I think is interesting, because the ecosystem and the platform within Red Hat OpenShift is so wide, you can do CI/CD within there, you can do deployments. It'll be interesting to see what the actual agent service is.

Are they just using it for primarily management of the Kubernetes clusters themselves? How far upstream does that allow you to inject things into those agent pathways? Can I do some of the conformance?

Can I do operators? Can I do admission controllers? It'll be interesting to get my hands on it and play around with it to see how much we can push the envelope with some of the agents.

I think that's a journey. I think that will just continue to evolve as we go along. Exactly.

I do. A lot of the folks I talk to who are deploying these AI agents early stages are struggling with the fact that the AI agents not only don't play nice with each other, but It seems like they require a lot of supervision. There isn't this notion that the AI agents are going to be deployed and then sit there idly waiting for you to talk to them.

If you do not talk to them, they go off and do strange things. Yes, they do. So at some point, I still need a human to supervise this stuff.

So, and I want to ask you both this, how do you see the role of IT teams evolving when I have these AI agents, some of which are behaving in a probabilistic manner, to your point- Yeah ... and these workflows are deterministic. Who manages this, and how does it evolve?

I am seeing more and more organizations, even at Thoughtworks, we are managing that with a shared platform engineering team, and then we're providing the right level of observability, evaluation, control, and guardrails directly to the application teams. And what that means is it kind of creates a hub and spoke model a bit, where there's core evaluations, core kind of pathways. I would even call them golden paths for the agentic workflows that are maintained by the platform engineering team.

But the developer or application teams that are maintaining those, I think it's their job to do two things. " We've seen you've got evaluation observability to show that the agent is gone out of its agent sandbox, if you're using agent sandboxes, and then to be able to corral it in. I just have a fail-safe, some sort of safety stop.

There's a bunch of these agentic techniques to stop and then redirect that's there. Those have to be provided by the platform team so that the actual application team, the product teams that are developing those, one, have the insight, the ability to constrain the problem, and then stop when things are kind of going off into a direction that they are not expecting. All right.

I don't think it's much of a secret to say that within the structure of IT organizations, there's a lot of snobbery at work. Mm-hmm. And the snobbery takes this form.

Your mere mortal IT administrator, who probably has no programming expertise, manages a lot of things, and they have a GUI interface to do that. Then there's a DevOps team that kind of is a bunch of engineers that are using scripts and are now evolving into maybe using AI agents. And then above that, there's a bunch of platform engineers who are using, what I would argue, are best DevOps practices to manage stuff at scale.

Yep. Can we reduce that noise and maybe all get along and maybe work together more closely as a team? What do you think?

Yeah, I think if the platform team replaces DevOps team-- No, I'm kidding. No, but I agree. What we're seeing is the platform team actually owning more and more of these conversations, right?

In fact, we're seeing an evolution of the platform team where we're seeing a convergence of more of the infrastructure elements and infrastructure teams, so specifically also data, MLOps teams, right, that are converging together with a traditional IT, cloud, ops into this kind of AI platform team that's moving down the stack from what is supporting all the dev tooling into this paths that we talked about, right? Both the probabilistic and deterministic, as well as all the agent infrastructure that ultimately doesn't change and can actually support multiple use cases, multiple agentic use cases, even beyond IT organizations, right? Because actually, it's all running on top of the same stuff, right?

So I think that's a really interesting thing. I think to your question earlier, we published on Weave Intelligence this four levels of how we think about the relationship between the human and the agents, going from human-in-the-loop, human-on-the-loop, to orchestrator, and then ultimately this level four would be sort of this constraint setter, where really as a human, you're just basically just worrying about what's the optimization function that you give to the system, and then the system can be self-healing, blah, blah, blah. Okay.

Nobody's on level four. That's kind of like- For now, maybe. Yeah, maybe.

Yeah. That's kind of the dream. Or you can be-- I think on an individual perspective, in some cases, you can be on level four, right?

For very simplistic kind of systems and use cases. But the moment you start having a team and an organization, it becomes very hard to move along that sort of scale. And the way you move along that scale is platform, right?

So I think you can correlate platform maturity with agentic maturity. And as you go along this agentic levels, you need a better platform, and you need a team that is able to support all those use cases. I kind of heard a slightly different variation of that, but it's similar.

So the platform engineering team manages the infrastructure and sets that up as a self-service. Yeah. But the application itself is gonna be managed by a software factory, and the factory is made up of a bunch of different agents, but each application has its own software factory.

There isn't this one software factory for them all. Does that make any sense? That does.

One of the things that we are talking to clients about, and one of the things where I'm personally experimenting with, is if you think about it as an actual traditional factory, hey, I'm going to have a factory. I may have assembly lines within that factory that are going to be specific to a particular make model of a car, a particular component that's gonna scale across multiple car points, car models, et cetera. We're thinking about it the same way, that, hey, I'm gonna have to set up factories for different types of applications, different arc types of applications.

Maybe there's a separate factory for modernizing existing applications from COBOL to Java or from Fortran to a new language. But then even within that, I may have full stack, I may have greenfield, I may have even sub-components within there, hey, I'm building an agent. So there's gonna have to be variations on the larger factory model.

There's gonna have to be componentry that's specific for those. I may not need the same componentry to build an agent that I would to build a full stack Angular application. But there may be commonality within those.

So the idea of identifying what are the common components within each one, and then the specialized agents for each one of those, what are the inputs and the outputs? And then I think to the point that I think we're all alluding to, what are the changes within the operating model to support those factories, the application teams? How do I converge my teams so that they're providing the best support across infrastructure, self-service, the platform as a product?

And then one thing that we've not talked about is operations, right? These things are going into a production environment. How are we going to own and operate them?

So- So here's the irony of all of this in my mind. So the agents are being organized much like the way we organize humans. Yeah.

And it's almost kind of the same kind of structure, and everybody winds up being a manager- Of agents. of these agentic DevOps teams. So despite what his shirt says, is DevOps alive and well?

I think it is. I think it's going to shift. I think that there's some areas where DevOps is going to have to-- What we traditionally define DevOps as, I think it's going to play a bigger role in operations on the production side, particularly because there's gonna be a lot of evolution in what we're calling AIOps, agents that are doing things that traditional identify, triage, learn loop that's there, that was in kind of some of the early Gene Kim books that was there.

Yeah. I think agentification of that is where we're gonna be moving to for the traditional DevOps teams. And the best DevOps engineers are going to build that out, I think fold into a platform engineering team to own and operate.

But we have to have those skills as a part of it. So I think it's not as dead as Luka and I used to believe. I'm gonna lump myself into the camp- Ah, okay ...

as what we used to believe, particularly because things are moving so fast, and we need those skills to be able to codify and operationalize what the agents need to do, what those AI operations need to look like, and then create a holistic front door for everything. And I think obviously the DevOps is dead has always been kind of like a more inflammatory thing than it should be, right? The reality is platform engineering is an evolution of DevOps.

It actually enables DevOps at scale, to your point, right? So, it enables true you build it, you run it, right? Where I think instead of shifting everything left, we're shifting everything down to the platform, and then people can actually be responsible for building and running their own agents, right?

But within the guardrails and the constraints of a platform and not just, hey, we shift everything left to some person, that then is shifting everything to their agent. And then it's like maybe agents are even more left than people, actually, right? Yep.

I think so. And then it just goes way too far. See that?

I'm gonna leave this here, but I kind of look at all this and I equate it to my dance moves. They're so old, they're new again. Yeah.

Yeah. I think so. I agree.

I agree with that. I agree with that. I agree with that.

I mean, we were talking yesterday about people basically now are thinking about purchasing bigger computers, right? Yeah. And it's like we're going back to enterprise IT instead of everything to the cloud, and it's like, yeah, the old is new again.

Yeah, the old is new. Hybrid cloud for inference is the new hot topic. It's the new thing.

All right. There was a second topic yesterday. Roncon was talking about launching a sandbox project with the CNCF, where they were gonna create a conformance standard for cloud-native applications deployed on the clusters.

There's a conformance standard for the clusters themselves, which is mainly for OEMs. But this seems a little more ambitious To create something that is a conformance standard for AppSec that are going to be distributed somewhere and everywhere. And then as part of that, they added, I guess Broadcom and VMware have long had this API for provisioning infrastructure.

They're now making that available to everybody because they want to make VMs finally a first-class citizen in the land of DevOps. Go figure. Yeah.

I think that that was an interesting announcement for a couple of reasons. One of which we were just mentioning at the end of that first discussion, which is a lot of organizations are now trying to figure out what their hybrid inference strategy is. Right?

How much inference is going to be in the traditional cloud service providers? How much inference am I pulling back and actually running within my own local hardware in a data center that's there? Or distributed data center- Or distributed- Under everyone's desk ...

yes. Or distributed data center implementation. My inference engine in my pocket, right?

Exactly. So I think that that announcement was very interesting as we need more of the larger kind of players to lean into, hey, we're going to have to have more hybrid strategies. I don't want to call it the return of the VM, but I do think it's a return of local virtualization to be able to run in the banking and financial services industry, local fraud detection, local meaning on-prem fraud detection, and local risk management, local claims identification and management.

Those are things that I'm seeing more and more of the large BFSI enterprises trying to pull back in. That's happening in healthcare. That's happening in government.

So we're starting to see this idea of a hybrid strategy. And without kind of a, I don't want to say blanket, but a more ubiquitous or standardized way to roll those things out, you're going to have a lot of fracturization. You're going to have people doing everything differently, and that's not really within the spirit of CNCF.

And I mentioned this in the earlier panel. If the standard is not good, the developers won't adopt it, and we'll be back to the starting board, and we'll have to come up with a new standard. But I do think it's a pretty good attempt to move forward and start standardizing what that should look like.

I think eventually the standard will be good. It's just a question of how long- How long it's going to take ... it's going to take to get there.

Yeah. Let me ask you this, though. Are we getting any better at making the IT infrastructure less of a snowflake?

And I ask this question because when I go visit shops, everybody's got a setup that's slightly different. And then the applications don't run exactly the same when they move them from different platforms. So is this conformance specification a step towards let's actually finally standardize this infrastructure in a way that I don't have to keep tweaking my app every time I move it or shift it to somewhere else?

Is that fair? It's fair. I think it's a movement in that direction.

Will it actually solve that problem? No. I think that there's just something inherent in engineers and developers and in platform and DevOps engineers that is, well, I have to tweak this in my area because for some reason we're unique.

I think what the standard does is that it does allow for some level of portability, right? There's going to be some things underneath the iceberg that we say, okay, those things all look fairly standard. I don't think it provides enough to say, oh, I'm not using Helm over here.

I'm using something that's more standard. Oh, we're using customize over here. So I think as we start moving up the stack, there's going to be more and more standardization because I think that that's going to be important because the agents, the inference, all of those things are moving so fast, we have to have standardization somewhere.

Right. But to your point about that, are the AI agents getting smart enough to reason across the standards to get close enough so that they can figure out how to move stuff more so than we could? Because we humans would get caught up in all these little things.

Biases and those things. I mean, maybe, but at the end of the day, I think the old is new, right? We've seen this before where it's like everyone thinks they're a special snowflake.

And so of course this is now happening again in just a slightly different flavor. I still don't think we're at a stage where you can rely on agents to fix something like this because for everybody that has used skills, every single time you get a slightly different output. So to hope that as they communicate with one another, they go through different tools and standards, that is actually not getting worse but better.

I think it's just wishful thinking right now. But I think this is also why, again, it's a cultural question of how do you enforce these standards and what is the ownership? What is the team that ultimately needs to try and drive this standardization by design across the team?

The workflows, again, I think often falls onto the shoulders of the platform team. And this is also why we often emphasize that so much of the job is this last mile optimization as opposed to try to rebuild the entire stack from scratch every time. Try to rely wherever possible on CNCF standards, open source standards, and so on.

But then you do need to do that last mile optimization and that glue because everybody thinks they're a special snowflake. And I'm going to answer that question in the same way, but slightly differently. I think one of the key areas where we're seeing it be important for the standards to come in so that if you are using agents, they can kind of help with that is most organizations we're driving towards building some sort of enterprise context library where the standards are actually in there that say, hey, here's the standards that we want to go and use to build infrastructure.

Agent, you're going to pull consistently from those standards. And so that at least gives the agent some sort of knowledge source that says- Yeah ... all right, yeah, they want me to use this particular CNCF standard for building out infrastructure, or they want Kubernetes clusters to look like this.

I think that combined with human review, humans kind of guiding those things in will allow us to, at least within an enterprise, have a bit more conformity because everyone is coming and approving that context library and saying, hey, we're going to have Broadcom's conformance standard in there, and that's how we're going to deploy local clusters for that or whatever those are going to be. So playing that out to the Nth degree, is there going to be an AI agent functioning like a platform engineer and leaving notes for other AI agents that say, "Do not touch this. Everything will break"?

I'm not going to predict three years or even three months. I think if it's a very deterministic AI agent, then maybe yes. Or a very deterministic pathway.

2, yeah ... a new Mythos yesterday? Yeah.

With the kind of six-month cycle of these models constantly getting pumped out, it's possible. It's certainly possible. But I think right now in the short term, the answer is they're still leaving notes for humans to come in and say, "Hey, please review this before I go hand it off to another agent," particularly in the more probabilistic pathway.

Last question. We're here at KubeCon. Kubernetes has always had this reputation of being a powerful platform, difficult to manage.

Are we going to get past that in the age of AI? Can we look forward to maybe using AI to streamline Kubernetes and make it a little more accessible? What do you think?

In the panel yesterday, so please see the first panel about cloud native and CNCF and architectures, Jon Willis, I'm going to put him on the spot here. He said something that I actually agreed with, and it's a very controversial take, even more controversial than any of Luka's takes. And his Luka T-shirts.

And T-shirts as well. I honestly think that the introduction of agents is going to end up creating a new version of Kubernetes, something completely new, because I do not think that agents are going to help manage the complexity of Kubernetes. What I've historically noticed is when we introduce agents into an ecosystem, it only amplifies the complexity, amplifies technical debt.

I think what the agents are going to do is there's going to be small optimizations in Kubernetes that allow us to manage it a bit more effectively. But ultimately, I think it's going to drive us to some new way to manage infrastructure in maybe the next four to five years. Somebody- Son of Kubernetes?

Son of Kubernetes. Yeah. Somebody said it in one of the roundtable conversations we had in the last three weeks.

I don't know. But they're like, "Oh, I'm just waiting for this new standard, this new Kubernetes to drop. " Yep.

And I think that makes sense. It's like we're in a completely new paradigm. So I don't think it's about just taking the old stuff and trying to agentify like everyone else is mostly trying to do.

It's like what is the new thing that- What is the new thing? What is the new thing that we-- Yeah. And I think nobody knows.

No one knows. No one knows. All right.

Well, we do know one thing for sure. I think most likely that even though it may not look like Kubernetes as we know it, we're probably still going to call it Kubernetes in one way or another. At least I hope so.

Maybe for the next show I'm going to have a Kubernetes is dead T-shirt. Oh, well. I won't be able to sit next to you then.

That is rough. Gentlemen, thanks for coming by. Thanks so much.

Thank you so much. Enjoyed the chat. All right.

Guys, that's it for today, and we'll be back with another Techstrong Gang episode tomorrow. But in the meantime, we're going to record some other episodes here, and we'll talk to you then.