Bart Farrell: So first things first, who are you, what's your role, and where do you work?
Jorge Valenzuela Jiménez: I'm Jorge Valenzuela. My role is leading the pre-sales team for Iberia in Nutanix. Happy to be here with you, Bart, and the community.
Bart Farrell: As AI agents move from answering questions to operating infrastructure, what Kubernetes design principles, whether it's reconciliation loops, desired state, controllers, become useful models for building reliable agents?
Jorge Valenzuela Jiménez: This question could take a lot of time to answer, because there is not just one answer. But from my point of view and my experience, I think that the most useful principle from Kubernetes that we can see or we can reuse is probably the reconciliation loop. And let me explain why. Because when we are working with Kubernetes, one of the things that make Kubernetes like a magic tool or the beauty of this tool is that you put or you specify what you need, what is your desired state and the reconciliation loop just works for trying to reconcile the difference between the real state and the state that you want to. So if we move that principle to AI, to the AI world and more specifically to the agents world. So from my point of view, the agent should work in the same way as Kubernetes. The agent should be able to take action through the desired state. So we should be able to say to an agent, okay, this is my wanted state or my final state. So the agent should be able to look at the system and say, hey, what's the real status now and what action do I need to take to move from point A to get to point B. So that's where the reconciliation loop is for me the most important one. And if we talk about the reconciliation loop, from my point of view also, we need to talk about the principle of idempotency. Because it's very important. It's something that when we work with Kubernetes, it does not just execute an action and just take for granted that the action has been okay. Kubernetes is continuously looking at the real status and comparing and then still taking action until the gap between point B and A is as close as possible or is the same. So an agent should be the same. I always put an example to people working in this area that I say, okay, imagine an agent that is telling that the application that we are running needs to have three replicas. And imagine that the agent runs this twice. I don't want the application having six replicas. I just want three. So we need to be sure that each action, even if the agent is repeating the action, it's not changing the result. So we need to rely on that principle, and I think that there is a tendency to use or to move the idempotency principle to the APIs that are called from the agent and more in the agent side what we need to do is to take control of the action that we have run by having a log of the tasks that have been executed so we are sure that we have not executed two or three times the same task because imagine we need to restart a pod and the agent restarted then in the next action it also decides that because it didn't work it needs to restart again the pod so it could become a loop just restarting the pod but the result will be the same so we need also to take some action to log those in some place. From my point of view, I'm seeing that we are moving towards that direction, I would say.
Bart Farrell: Now, for an AI agent that's troubleshooting Kubernetes, what operational context does it actually need before its recommendations become trustworthy? Metrics, logs, events, topology, deployment history, policy state, anything else?
Jorge Valenzuela Jiménez: I think all of them are needed for sure. And the key word here is context, as you mentioned. Because the agent needs to understand what is happening and what's the real status and so on. I think that metrics, logs, even traces are needed to understand even in Kubernetes, where we are working with distributed systems, we need distributed tracing systems also to understand what happened and we are able to follow the course or the path of a specific event. But I would also add one thing that is application intent. So from my point of view, if we are using an agent to operate our infrastructure, we need that agent to understand what the application health status means for me as a user or what's the service level objective for that application because it is not just that the agent checks if the desired state is okay or not, but whether Kubernetes is adding a replica for example, whether it is needed, whether it is aligned with the SLO for the application or the SLA. The other thing that I think is really important is understanding the context and having the information about the policies and policy enforcement that could be preventing the desired result. Because imagine that the agent is telling you, that you need to execute this action. Or I as an agent, I need to execute this action. But if one thing is, okay, I want to execute it. The other thing is, okay, am I allowed from a security perspective. Also we need to understand what's the context where we are running as an agent because sometimes we need to understand what's the policies, what are the constraints that we are operating in. So these kinds of things are important. So I will add the ones that you mentioned, but also application intent and everything related to policy enforcement and security.
Bart Farrell: And Jorge, where should the boundaries sit between an agent diagnosing a Kubernetes problem and actually taking action? What guardrails would you require before allowing an agent to change production state?
Jorge Valenzuela Jiménez: That's the main fear that we are seeing in the industry. And I think we are moving to a world where we are delegating more tasks to an agent. But I don't think that there is a real boundary itself. I prefer to say that the boundary will depend on what's the risk, even if the action that the agent is taking is reversible or not. I see it as a progression. First of all, what I advise to some customers doing this right now or starting to do this not in production because production will probably be the next step. But the first thing is, okay, let the agent understand what is happening and describe it to you. So that will be the first step. Then maybe you can move to, okay, let the agent see what is happening. Let the agent explain to you what is happening and let the agent explain what will be the action that the agent will take to fix the issue. That will be the next step. And then after having some time doing this, I will move to, okay, let the agent propose the plan and have human verification or human review. And then after that, I think that we can take two or three tasks that we are confident that we know very well what's the boundary and context, then allow the agent to take autonomous action. But I see it as a progression, so it is not 100% or zero. So I think that we need to understand how the agent behaves before allowing him or allowing it to take real action. So the boundary will be that. So risk, confidence, whether your action is reversible or not. And then I will make sure that the platform has some guardrails. So even if the agent wants to execute something, as I said in the previous question, so we need some guardrails that we are sure that the agent has no permission to do whatever it wants. So we need the least privilege, the minimum privilege action or using RBAC or whatever action we need to do it. We need also to be sure that we have minimized the blast radius in case the agent does a harmful action. So that would be the guardrails really that will give me the necessary trust to let the agent execute things. So I think it's a progression from my point of view and for sure I will still rely on the platform to be sure that even if the agent wants to execute or is able to execute things, I need to be sure that I have constrained the execution, the environment, the scope and this kind of things. So for me the platform is key in this case.
Bart Farrell: Now, Jorge, what's next for you? With all the changes going on in the AI world, what are the things that you're looking at? What are the things that you're excited about?
Jorge Valenzuela Jiménez: One of the things that I am working on right now is trying to set up kind of a framework to help companies, big companies, how to govern and to set up a proper governance framework for AI. Meaning agents, copilots, MCP servers, MCP clients, whatever we can call it. That's one of the things that I'm working inside of the Chief Architecture Forum of IASA. I'm happy about that. The other thing that I work on also, and I'm very active is how developers or how the inside of the CI/CD pipeline, how are these kind of pipelines impacted by agents and how the agents should behave. When we are in a cloud native environment where we are using continuous integration and continuous deployment. We are seeing that we are moving from static flows to on-the-fly pipelines created by agents. So how do we ensure that from platform engineering teams, we are able to provide the guardrails and this kind of thing. So all related to governance somehow, but one from the development area and the other one at a higher level from a big company. How do I organize all the AI assets that I have? And how can I be sure that we are avoiding shadow AI and this kind of thing? A lot of work to do. As you know, it is moving super fast. And a lot to learn also from the field.
Bart Farrell: Absolutely. And if people want to get in touch with you, what's the best way to do that?
Jorge Valenzuela Jiménez: The easiest way is through LinkedIn. I'm very active on LinkedIn and anyone can reach out to me and probably it could take one day or a couple of days to answer, but I promise that I will answer people. I think that's the easiest way. I will also be happy to comment or to have conversations with people interested in this area. But I think that we'll have a lot of growth in the following years, to be honest, because infrastructure or having AI operating infrastructure and reliable systems and distributed systems is going to be fun, but it's also going to be a lot of learning effort for us. And I will be happy to have fun with anyone that wants to reach out.
