Bart Farrell: All right, so first things first, who are you, what's your role, and where do you work?
Philippe Ensarguet: Hey Bart, very good to be with you. My name is Philippe Ensarguet, I'm VP Cloud and Software Engineering at Orange. I'm also Orange Fellow, and what I'm doing is quite simple. With my team, we are preparing the next generation of infrastructure that will carry connectivity and networking for consumer and enterprise. I'm evolving at the crossroads of virtualization, cloud native, automation, AI, and agentic AI. It's worth also to say that I'm strongly involved in the open source ecosystem. I'm representing Orange at the board of Linux Foundation Europe. I'm co-chairing the governing board of the Sylva project, that is one of the main open source projects to bring telco cloud-native infrastructure for cloud-native network functions, and we are integrating agentic AI in this. Yes, it's basically my history in digital, but I've spent the last three years in the telco industry.
Bart Farrell: Philippe, if an AI operator is helping diagnose a Kubernetes incident, what context does it really need beyond cluster state? Git changes, telemetry, dependencies, deployment history, ownership, anything else?
Philippe Ensarguet: It's a very good question to start with, Bart, because my first feeling here is to say that there is no magic spell. What does a human operator use to make the diagnostic and to diagnose whatever he needs to do? I would say like for instance a Kubernetes incident. The answer honestly will be almost the same for an AI agent. it's very important to start with this. Then for me the cluster state tells you what broke definitely but it almost never tells you why now, and the why is living in the change plane and the ownership plane, and both of all of this are living outside the cluster. So to hook with your question, I think that we should need a bit more than what you enumerated in your question. And if I want to be more precise, I think that we have multiple planes to consider. when you want to manage the Kubernetes incidents for an AI operator. The first one to start with that for me is perhaps not the one that everyone is thinking about is what I'm calling the change plane. I'm talking to be concrete about GitOps revision, pull request and author, and release history, image digest, feature flags, config drift. And I think that here, the highest value correlation an agent can perform is something like, hey, what has changed in the last N minutes inside the blast radius of this incident? According to what we are doing and talking with my industry peers here, I would say that most of the time here, we are having incidents that are change-induced. Well, agent context window contains zero change data. And I think that this is very, extremely important. Today, we could say that, okay, we got Git, but Git records what humans change most of the time. It doesn't record what changed, I would say, generated three reconciliation layers down. We trace the intent, not really the consequences. And without grabbing the consequences, I don't know how we could have, a proper diagnostic. first item, the change plane. The second one is, related to a part of what you announced. It's the telemetry plane. But here, according to what we cooked, I would say that it's something that is pre-processed, not raw. MELT is definitely the table stakes. And here, for instance, we are having interesting patterns that are emerging. The first one, using subagents that summarize the metrics, the logs, the timeline in something that is digestible before the orchestrator is doing the reasoning. And there is also another learning to manage the telemetry topic. is using something that could perhaps look not so agentic but a very classical shape: a deterministic pre-filter. You know the famous scikit-learn Python library for instance. And we could use an isolation forest to do some scoring of each sample. Telemetry is extremely important, but we absolutely need to do a pre-filter of it if we want to bring the ability of the agent to do a proper diagnostic. The third plane that I wanted to talk about is about the topology and the dependency plane. And here I'm talking about what is not in Kubernetes. I'm talking about service graph, about owner reference, about network policy, about what is upstream and downstream regarding the code and the configuration, and the criticality of the non-cluster dependencies. the DNS, the external TLS termination, the Cloud Load Balancer, the database. And most of the time, I would say that the agent only solves it when a human told it to look outside the cluster. So if we don't bring a topology that is given to the agent to make the diagnostic something that is more holistic, because you could have a perfect Kubernetes running. and having workload or orchestrator on top, that is absolutely not the case. And if you don't give the full picture, I would say, to your agent to manage the troubleshooting inside Kubernetes, it will struggle. The fourth one is about what I'm calling the ownership and the organizational plane. Here, I'm talking about the service owner, the on-call, the SLO, all those topics that could determine what the agent is permitted to do. And I think that this kind of governance plane is something that is not so easy to bring, but that brings a lot of value. And the final one that honestly is perhaps one of the most important in the work that we did, for instance, within the Sylva project, across all our ecosystem and community is about what I'm calling institutional memory. here I'm talking about incidents, postmortems, runbooks, everything that is bringing information where the agent is able to grab some hooks that will give something that take into account what happened. up to now and the state in which the cluster is. So for me, to answer your question, I think that it's important to consider those five planes. The change plane, the telemetry plane, the topology and dependency plane, the ownership and organizational plane, and the institutional memory plane. to end with your question, that there are three things super important, to highlight. The first one is definitely about something that I think is truly important. I'm talking about the intent. Here for me, a diagnosis without a stated intent is merely the detection of anomalies without meaning. And if you don't have the meaning, the reasoning will be much more narrow. the agent must know what the system is supposed to do. the SLOs, the intent-based operation, the GitOps. For instance, within the Sylva ecosystem project, we are heavy users and supporters of FluxCD. The idea is to use the graph of the GitOps actions that bring information about the intent. The second topic that I want to highlight is about what I'm calling the provenance, where the things are coming. Every piece of data used by an agent must have two things. a source and a timestamp. Otherwise, the root cause analysis is not auditable and it's merely a plausible narrative, but it's not working. In a regulated environment like we have in the telecom industry, this distinction is absolutely critical. And the last and final topic that is perhaps more related to the telecom industry, when you have a 5G core network that is making your phone running when you want to call whoever you want. Basically, the symptoms can emerge at the network service level, at the 3GPP specification level. And here, the causes lie really at the platform level. So the agent needs a mapping between the two. And this mapping is totally outside the scope of any Kubernetes API. So we need to take into account how to bring knowledge and meaning about what's working on top of the Kubernetes cluster. Otherwise, he will be half blind about making the diagnostic right.
Bart Farrell: And Philippe, what would an AI system have to prove before you would trust it to move from explaining and recommending to actually making a production change?
Philippe Ensarguet: It's a very good question. The first thing to start with is that trust is really a property of the system around the model. It's not the model. There are multiple items or topics to consider. The first one is really having measured diagnostic accuracy on your incidents. When you're talking with peers and friends, I observe on Kubernetes root cause analysis could be a bit low. But this is not a Kubernetes problem nor an argument against the agent. It's an argument about where you place them and how much you let them decide to move along. And when you're talking about a 50% or whatever the percentage is, the true question for me to ask is how stable your grader is. The accuracy number is downstream of the instrument and almost nobody publishes information about this. Calibration is my second point. The calibration for me is exactly the proof it knows when it doesn't know. When you are talking about trust, knowing that you don't know is something super important and not the default behavior of a model working inside the agent. And here, the escalation must be a first-class terminal state and not an error path, according to me. The third topic is about the proven reversibility before authority is granted. Every action class gets a tested rollback with a bounded time to revert. If you can't revert it inside what you're doing, inside your budget, the agent doesn't get to do it. The reversibility is perhaps something that is not sexy because it sounds like 80s or year 2000. But if I want to be very transparent with you, Bart, when we are talking about trust, most of the time you are hearing things around, hey, guardrails, hey, harnessing. But honestly, if you don't master the backup, the reversibility, then the harnessing, and then the guardrails, what do you have? You only have a factory that is managing faster errors that you're not able to fix. It's super important to do the job in the right order. Check that you are able to recover and to manage and that your backup is effective. Then validate your reversibility. How confident are you with the intent and declarative state of your infrastructure and the application that are living on top are able to recover and to reset the system in the proper way. Once you tackle those two, let's talk about harnessing, let's talk about guardrails. But I think we need to be very accurate on what we need to do in which order. Something that is also super important is to manage what I'm calling the containment. And this containment needs to be enforced outside the model according to me. Here I'm talking about the policy as code: use a dedicated service account, never a human kubeconfig, never cluster admin. What we got on Open Policy Agent and Kyverno admission rules are something that is extremely interesting that we should apply to manage the topic around the trust. Of course, you absolutely need to have an audit trail that you can attribute. I'm talking about who is accountable of what and my ability to prove that the agent did something. We absolutely need to have a per-agent workload identity. Here we could add something like a SPIFFE or dedicated service account for instance in the Kubernetes ecosystem. We need to be sure that we propagate proper traces through the entire reasoning chain and to be sure that everything that is prompts, tools, policies are versioned in Git and reconciled automatically by GitOps. And the last topic that is very important is of course the post-action verification to be sure and being able to prove that post-change health against the pre-change baseline. Before executing the plan, you need to have this post-action verification to be sure that you are able to compare the normal behavior of what your agent is doing and then raising the trust you may have in the system you're building. To close with this question, Bart, there are two topics that for me are very important to highlight. I really want to come back again because we are talking about agentic AI running in cloud-native environment. And I really want to spot again on this topic of we need backup, reversibility, harnessing, and guardrails. Reversibility is really the first topic with the declarative rollback. Then we have the harness with the observability and the attribution. And finally, the guardrails where we scope the boundaries and manage the blast radius limits and integrate when it's proper, human in the loop at proper checkpoint. So I think that this point is extremely important. The second one that is perhaps something that you don't expect, but when you are working in highly regulated environment, for instance, we have in Europe the EU AI Act, Article 14 highlights the human oversight and Article 15 about accuracy and robustness and cybersecurity that apply to autonomous agents in high-risk domains. And something that is super important is to say that Article 14 of the EU AI Act clearly states that the duty falls on the deploying party, not on the tool or the vendor. In an environment regulated like we have in the telecom industry, the audit trail isn't overhead. It's really the deliverable. We absolutely need to take this into account.
Bart Farrell: Now, Kubernetes controllers are deterministic while AI agents are probabilistic. Where do you think that boundary should sit in production operations?
Philippe Ensarguet: It's a very important question that you are bringing here. The probabilistic part proposes and the deterministic part disposes. Kubernetes already gave us the enforcement layer controller. The agent's job is to author the desired state, not to bypass it. To bring my feedback about this question on probabilistic versus deterministic, I need to break down into multiple pieces. The first one is to put the boundary inside the loop, not around the system. So we need a multi-stage process to tune up where the agent and controller may finally sit. And if I want to share my breakdown, it's quite simple. You start by observing. That is on bounded cost and latency, something that is calibrated. It's a collection that is deterministic. Once you observe, you need to orient and to manage some hypotheses. Here, we could open the door for having something that is probabilistic. Here it's exactly a place where we could embrace having an agent or using a model. And there is an interesting reason that at this stage, at orientation and raising the hypothesis, it's still cheap to be wrong. For me, at orientation and hypothesis, it's good for being probabilistic. Observe, orient, make the hypothesis, then you need to decide. And when I'm talking about decide, it's deciding what is permitted. Honestly, here in the context that we are talking today, it's 100% deterministic. What is the OPA or the Kyverno verdict? What is the policy bundle in Git? What do we need to test? We must be very cautious about only LLM judgment. We observe, we orient, we decide, and then we need to validate. To validate, and for me, the validation needs to be deterministic. And the idea here is to be schema and server-side dry-run oriented. So it means that you have prerequisites that are here. You have no unintended override, you have dependency ordering, and you are managing the idempotency. Observe deterministic, orient hypothesis making probabilistic, deciding deterministic, then you need to validate. This validation, like I said, is deterministic. Once you did the validation, you need to act because at a moment in time you need to do something. Acting, for me, is extremely deterministic because the agent does not call the API server, it emits an intent, a pull request, and I'm a strong supporter about the GitOps method. The agent doesn't need to fire and target directly the API. If we are cutting the pull request on the Git repo, we are losing the consistency and the coherency of the global ecosystem because you will have things that are human-based. stored in the Git, then the pull request and triggered by the GitOps process for reconciliation. But if you have agents that are targeting directly the API, you are breaking the consistency. The last one that for me is extremely important is the verification. And the verification, I'm talking about SLO gates, progressive delivery analysis, and automated rollback. I'm afraid that once again, it's deterministic. I don't know if it's only intuition or things that are emerging in our community. But if I just want to wrap up, observation, deterministic orientation could be probabilistic, but decision, validation, act and verification are also deterministic. And the very good news is that Kubernetes already solved the hard part. The controller pattern is deterministic and the convergence loop over the declared desired state. It's super important because it's bringing the idempotency, the rollback, and the audits that are totally built in. A correct integration could look like the agent sits upstream of the reconciliation, authoring and amending the desired state. It does not replace the reconciliation. The agent is the author of the intent. The controller is the enforcer. We need to inherit the determinism natively reinforced by the GitOps practices. At the end of the day, we are talking about deterministic versus probabilistic. And when we are considering safety, I'm not sure that it's always the right axis. Today, reversibility and blast radius regarding the observability of outcomes looks much better to me. A probabilistic agent restart, a stateless pod behind a load balancer is far safer than a deterministic script that will touch directly the etcd of the cluster.
Bart Farrell: And Philippe, with all the work that you've done and what you've been learning, the Sylva project as well as with FluxCD and also watching AI agents evolve so quickly, including this topic of guardrails, what's next? What's next for you? What are you going to be working on?
Philippe Ensarguet: Something that is totally related to the discussion we got today, Bart, is that on the Sylva ecosystem today, one of our priorities northbound is to add on top of Sylva core an agentic AI layer. The idea is to play the same runbook we manage on the infrastructure and grabbing all the right open source projects and components and to manage a proper integration to bring AI inference and agentic AI execution capability in the Sylva ecosystem. All the topics that were connected to the question you asked me are totally at the core of what we're doing. Something that also is very important to take into account. We met during the last Amsterdam KubeCon week, and this week we got, the Cloud Native Telco Day, that is a pre-day at KubeCon. Something that was very interesting is that the topic related to the question that you raised today was nearly number one topic, and we got multiple feedback from multiple operators and people that bring their thoughts and their experience. It's totally at the heart of what we are building up. If we are not able to manage the trust we have in the system, stepping up using agentic AI, we won't be able to manage our duty on the legal, on the regulation and on the quality of service. This is what we owe our customers, whether they are consumers or enterprises. Definitely, the topic of agentic AI for operation and easing the life of the people that are in the trenches for the operation is extremely important, but it needs to be driven by everything that I outlined during our conversation.
Bart Farrell: Excellent. And, Philippe, if people want to continue the conversation with you, what's the best way to get in touch with you?
Philippe Ensarguet: The easiest one is you could easily find me on LinkedIn. It will be the easiest channel to grab me and I would be more than happy to double click on the discussion I've got today with Bart. Hi, my name is Philippe and this is KubeFM.
