LF Live Webinar: AI Can Write Your Infrastructure Code. Can It Govern and Heal What It Builds?

All right. Hi everyone. Thank you so much for joining today. Um, as Candace mentioned, I'm Maos. I'm a product marketing manager at Harness and I'm joined today by with my colleague Rohit uh who's a principal product manager at Harness. Uh, I would love for him to give an introduction to himself. >> Hey. Hey everyone. I'm Rohit and I lead uh product for infrastructures code management here at Harness. Nice to meet you all. >> Yeah, nice to meet you. Um so the premise of today is pretty simple. Uh AI has gotten really good at helping us create infrastructure as code and generating code and we can basically generate Terraform open tofu policies configurations a lot faster than we did before. Right? But creating more infrastructure faster creates a second question. Who is governing all of that infrastructure once it exists? And when something changes, drifts, uh, becomes risky and gets too expensive, can the system actually do something about it? And that's what we're going to dig in today. So, let's get started. So, you know, for years, I think we've progressively gotten at what we would like to call like day one operations, right? um Terraform and open tou has like given us a declarative infrastructure and then CI/CD and githops gave us repeatability and automation but the reality today is like much messier right we have so many tools multiple states console changes configuration changes and a gap between what our code says should exist and what is actually running and that's really the theme of today um and what we're talking about right the failure usually isn't just in provisioning infrastructure. It it's what happens next or what happens after. So Rohit, you you typically like deal with a lot of teams um and customers, right? Where do you typically see the gap start? Is it is it console changes? Is it drift? Is it disconnected tooling or something else? >> Yeah, I think it's I I I I think it's it's all of the above. But I think the single biggest gap that I see today is the disconnect between like what platform engineers put out there and what is being consumed. Um and again like that might also like have multiple tooling involved and multiple types of actual uh technologies involved. So there's like certain certain degree of disconnect and drift there. >> Yeah. uh when you say it's it's between what platform engineering could you could you dig a little deeper into that like give us an example from a customer >> absolutely so you know one of our customers they wanted to sort of set up paved paths and enforce uh the usage of these paved paths so now you have uh you some users consuming these paved paths and some who do not but you you now want to um take an inventory of what are the resources which are in fact in adurance to these pave parts and what are the resources which are not. So you know it is uh this is a very important sort of problem to solve uh which again like a control plane plays a very important role in in solving that problem. >> So kind of [snorts] in almost alluding to our next slide like infrastructure really does start to break when control is assumed right. Um and when we zoom out we I think I completely agree with you. You can see why that sort of happens because every part of this life cycle may be strong independently and the tooling may be strong independently. Um like your IC tool may know its declared state. Anible knows the configuration it needs to apply. CI/CD knows um what what it was asked to execute, right? And um security and governance tools know the policies they're responsible for, but none of these things inherently means the system as a whole is correct, right? That's that's kind of what ends up happening. Um, and then you may end up with like multiple sources of truth because the Terraform state that you have might not actually equal what the actual infrastructure is. Um, you know, and configurations can change without infrastructure context and CI/CD can execute what it receives. So, and policies might exist but only at like individual checkpoints, right? Um, so the issue isn't like necessarily that we need a better point tool. the issue seems like that the state is defined but it's not continuously enforced across the whole system. Is is that seem like an accurate description? >> Yeah. Yeah. Absolutely. And I think it just alludes to the point that sometimes like all of these handoffs happen across teams and across you know different um levels of the organization and it becomes very important to bring all of these together in in one unified platform. Actually just this week or last week, GitHub actually described this broader shift right of developers becoming sort of moving from being like primarily coders to becoming orchestrators and how AI you know designing how AI generated work is proposed, validated, reviewed and ultimately shipped. Um so do you see that shift in terms of infrastructure as code as well? Yeah, absolutely right. Like the code generation is just one aspect and part of it and you know like frontier models have sort of really accelerated that part of the story but again like how like the developers responsibilities are sort of blurring and they're taking on more and more responsibilities in terms of uh you know managing a lot more aspects of this life cycle and and it totally uh translates to the infrastructure side of things as well. But in this case, personas are slightly different, but it's it's the same fundamental philosophy. >> Absolutely. And one more thing that we've been seeing, you know, whether it's Terraform or whether it's open Tofu or honestly any sort of code that's being generated and tooling out there like Open Tofu 1.12 that released recently in May. Um they're starting to add capabilities like simultaneous like human readable and machine readable, right? agent readable output which is just another sign that infrastructure tooling is increasingly expected to sort of participate in this sort of large movement towards automated systems towards a single control pane and not just operate by itself. Um and that's something that's really just you know something that's important to highlight. And so the problem here that you know we want to take a step back is that it isn't that we need another point solution to provision or make automate these individual tooling and silos. It's that um if state gets defined but it isn't continuously enforced across this entire system and these different steps um you know we can see a huge disconnect in the system itself. So what do we do about it? Right? Uh the solution really is that the control that we've been talking must travel with this system and it leads to the entire shift we've been talking about. So today in a lot of organizations we already talked about the fact that control is assumed. So um with a control plane what changes is that desired state is like continuously reconciled. So the context, ownership, all of those things like travel with the change, right? Policies are enforced throughout the infrastructure life cycle from the time you provision it to the time that infrastructure retires. And interestingly, we're seeing this concept actually emerge across the industry. We've talked about GitHub, we've talked about Open Tofu, but even recently as last month, um you know, Hashi added like a beta HCL Terraform policy framework to HCP Terraform specifically aimed at enforcing policies across different stages of the infrastructure life cycle including initialization and that's something you know we are also doing at harness. So this is the idea of moving governance earlier and making it part of the life cycle itself um is becoming increasingly important and for me the most important outcome here is that um the the is that the only compliant systems should deploy right so when you show customers ro the transition from like showing them how control is assumed in systems to control is enforced um which of these changes is sort of get the biggest reaction from customers. Is it visibility? Is it enforcement? >> Yeah, I think like as again like uh going back to my earlier point like it is giving end users the ability to operate within like compliant frameworks. So it is like giving them the ability to operate within paved paths um and making that self-service very straightforward and also like having that governance layer across all of these components um in terms of the platform engineers being able to control what those frameworks look like if there is deviation from the pave paths and also like complete visibility and audit of any such occurrence of you know non-compliance And how do you prevent it proactively? And also if if there is certain incident where it was prevented uh how do you how do you have a complete audit so that you can then use that data to coach people uh to have like better uh developer self-service as an overarching you know outcome. >> Absolutely. So what would this like look like in practice? Like we've we've talked about in harness, you know, uh Rohit talked about these paved paths. There's golden paths that you can enforce for infrastructure, but this is an sort of example of things you can keep in mind while, you know, getting to your step one. Not everyone today is already at a point where, you know, they're in implementing golden paths and self-service for infrastructures code that has checks and balances, that has security checks in it, that has approval workflows. Um so this is sort of like your starting point and here as you can see instead of having governance sit beside or in parallel to the infrastructure workflow we actually make it part of the workflow. Here we initialize it. We can run something like check off TF Lint TFAG um and then we generate the plan we can run with scans post plan. We can understand policy and cost at this point. um we can introduce an approval when one is actually warranted and then we finally like apply the infrastructure changes. And the point of these is not uh not necessarily like the logos on the screen, right? Or to say that you this scan is better um or this is the ideal workflow. Your tooling may be different. The point here is um policy, security, cost, approval and deployment can all become part of a single governed workflow or pipeline as we call it at harness right and that's the difference between saying we have policies and saying our infrastructure cannot change or cannot bypass our policy cannot change without bypassing our policies and things like that. So let's take a look at something that we have here at harness which is sort of at the approval point cost context right um one of the big things as we're deploying more infrastructure and as we're creating more of these changes um for a human to you know approve changes or to understand what changes we're not asking someone to look at the Terraform output and make a judgment call right because um telling me that something changed from like an EC2 small to EC2 medium just tells me what changed um and what resources are affected. But the bigger thing that is probably more impactful for a human who's approving this is what is the cost impact? Did the policy checks pass? Is there drift involved? Right? Is this going to change from the actual state? Is this fixing a previous drift? Um so the human should really review this full decision and not be reconstructing the context themselves. So a lot of things that we do is provide context for them at the time of apply. Um and Rohit I I want to sort of pause here because there's a lot of discussion right now in the industry about agents taking more autonomous actions, right? Um, so how do you think about the boundary between like automatically enforce and what should still require human judgment? Do you see approvals like these still requiring a human judgment? >> Yeah, I think like there are there are a couple of um aspects to this. The first aspect is how do we enrich this approval to an extent that you know at some point like we can pass this off to the agents right like like we discussed like open tofu has been making changes to you know have them be human readable and machine readable so we're working towards like you know having these contextual approvals have more data more context um which eventually can be presented and pulled in a machine readable format as uh but at this point uh we are also leveraging agents to enhance the actual data a user gets at the point of approval. So you mentioned like cost aspects, security aspects u and there are a lot of other like semantics which potentially um can be inferred with agentic tasks like how can you look at the overall plan and like how uh these plans correlate with other resources in the ecosystem and how do you actually contextually you know bring that as a deployment risk analysis and enhance this approval. So there's two layers to this like one actually enhancing the approval itself with you know with agents and then like making this approval like both machine readable going forward u to you know have certain um you know levers to consume that data and automate the entire process. But at this point like we do see a lot of um our own customers like still have the human in the loop element. You know infrastructure changes are extremely important. You know they are they can they can cause significant outages as we all know here. So again like the intent is to enhance this metadata with agents today but also like move towards a world where this content is machine readable and you know eventually we get we get uh to a degree of confidence where it can be fully automated. >> Absolutely. And I think that's especially important with AI, right? Uh because automation shouldn't really mean removing humans everywhere. It should mean involving them where their judgment actually adds value. And I think that view is actually increasingly um mirrors agentic flow designs almost like um everywhere I've seen workflows being created. Um I saw like GitHub actually launch like their security architecture for agentic workflows a few months ago. Um and that that really emphasized this concept as well from like a thought leadership standpoint where it's like um isolation for agents running um constrained outputs, comprehensive logging and those are principles we carry into all parts of agent workflows that we create at harness because rather than simply giving an agent unrestricted execution privileges especially when it comes to something like infrastructure. So another thing I know Rohit mentioned earlier was uh self-service infrastructure with controls right because once you have all of these controls and checks and balances in place governance can actually become an enabler of faster self-service for developers rather than a blocker because um a developer today shouldn't really have to file a juro ticket and wait like one day or even two days to get infrastructure that the platform team has provisioned a 100 times before, Right? If the platform team can define an approved pattern with the right template, the right security controls, the right cost constraints and policies, then developers should be able to consume that pattern themselves and even agents should be able to consume that pattern themselves, right? Um so developers and agents alike get speed and platform teams get standardizations. Um and of course the finance and security teams don't have to discover what happened after the fact. Um so that's really like the paved uh road model or the paved path uh because that makes the safe path almost like the easiest path to use and that's that's really why having this sort of like templatized workflows is essential for infrastructure at scale. Now one thing I did want to talk about is um we we talked about this idea of multiple tools right and the concept of one platform a single uh control plane because infrastructure doesn't stop when terraform says apply complete right you can provision your infrastructure with terraform open tofu teragrron cdk and then maybe you have to configure it with anible after that right and ultimately the infrastructure is supporting some sort of application deployment So historically those can easily become three separate workflows but as we've seen as you go towards a more automated workflows for developers or for agents um and sort of the the context disappears when you have three different tools. We tend to see a better path forward with sort of one platform for all of these separate toolings. Um, Rohit, I'm curious from your end, what tends to break when provision, configuration, and deployment are treated as sort of three separate independent systems instead of one life cycle? >> Yeah. Again, like the handoffs are now across multiple teams, multiple potentially multiple tools and different role-based access controls, different ways to audit your u end toend workflow and also just the governance layer, right? like you you cannot just have policies in place across multiple like handoffs if if they are in fragmented tools. So that's typically like one of the biggest um you know sort of concerns that a lot of uh users that work with us bring up and are able to alleviate with this one unified um pipeline story. Um, so is the answer here and and I'm asking this as a person who knows the answer that you're going to give me, but is the answer here are we suggesting replace terraform or replace anible with a single control plane? >> No, absolutely not. Like you sort of like keep your tooling, but the orchestration happens in one single control plane. >> Yeah. And I and I think that was an important clarification because the answer isn't to replace Terraform or replace Anible. is to give give these tools that shared orchestration, governance and context um when you're going into sort of the world of AI and agents and with that um let's talk about sort of AI and how it comes into the picture especially for us at harness um the interesting thing um that I've seen is that the industry is moving very quickly beyond just code completion right or code generation um uh GitHub harness there's so many companies that have agentic workflows running inside um their CI and CD and you know almost every other company has some sort of MCP servers that lets AI systems access uh current registry information maybe even perform workspace operations right um open open AI actually describes MCP as an open protocol that is becoming an industry standard for connecting models with additional context or tools or and knowledge right So the question really is no longer um will AI agents interact with our SDLC in infrastructure. They probably already are, right? The more interesting question is what context and what controls surround these agents when they act. And that's how you you can start thinking about the architecture here that we've defined. um a query comes in to the unified harness agent and we can route it to our specific agents like our delivery agent or security agent um some infrastructure specific agents that we have that I've highlighted like the remediation and blast radius agent right but underneath them like what really makes all of these agents work is the context the knowledge graph understands the environment um enterprise rules and policies understand uh what's allowed um memory ies add context and relevant organizational and user context and because an agent without context um like may be powerful um an agent with the right context I would say is like useful right and that that's really the fundamentals of like what's uh what's behind harness AI so you know we've talked about MCP and um the reason MCP is really important is because we don't want to tell developers here's AI and it completely changes how you work right um developers today should still be able to stay in their environment like cursor like visual studio and ask for what they want and the request can inherit the enterprise context the governance behind it before an action ever even touches the infrastructure and this is becoming more and more as an established model um because we've like for example even in harness you can you know explicitly request information and context about in and around the infrastructure and that's exactly why context um matters more uh once once an AI agent like remediation or blast radius is capable of actually taking infrastructure actions u rather than just like maybe answering questions um like how does like you know blast radius and remediation become like the concept become more important do Do you want to help define that here? >> Yeah, I mean uh like one of the foundational aspects is the context. So what what is this infrastructure backing? Is it backing a production service? Is it backing you know a dev instance? like how do you bring that and layer that on top of like what your infrastructure is defining and that's where again like the unified platform becomes very important where you're able to like bring in the context of what is actually being deployed on these uh infrastructure components. How are these infrastructure components related to other infrastructure components that exist and um you know today potentially are treated in isolation. How do you um then like layer that and sort of set the stage for defining risk of an infrastructure change? So whenever you're making an infrastructure change, you sort of give agent this context, the actual context of the change and then are able to predict like is you know what is the blast radius of this and is it a risky change um and if it's a risky change you know what are my mitigation strategies like how do I go and make this less risky or do I need to add in more approvals um and then there's the other operational aspect of you know there are things that needs to be done from an infrastructure um chain standpoint to bring them into a compliant uh you know control plane, right? So how how do you like make make sure your infrastructure is cost compliant is compliant to security vulnerabilities and you know these things are constantly evolving and how do you how do you make sure the operational overhead of keeping up with these is minimal. So that's where like the remediation aspect is also very important where worker agents can sort of go and do that work for you but then give you a pull request to say hey like this is the work that I did based on this insight um that came in from the cost side or the security side uh do you agree and if you agree let's go ahead and merge this change which again kicks in a blast radius analysis to see if the change the second layer of you know u checking if the change is actually not risky or risky and then like completes that whole loop. >> Awesome. And and that's that's where the more capable the agent becomes, it sounds like the more important the governance layer and even governing agents become, right? Because we don't want to almost choose between powerful AI and safe infrastructure. The architecture has to kind of give us both. >> Yeah. >> Awesome. So, one thing we wanted to talk about is just a few of the agents that we have here at harness to um show you what u you know an autonomous uh a future towards an autonomous SDLC could look like. Um the DevOps agent here for example, it can create and edit workflows or pipelines um analyze and fix those errors. It can create OPA policies uh because if anyone of you have written OPA policies, they're not fun to write. And so having an agent do that is great. But again, the key word here is that it's all personalized to your organization and environment because if you remember a few slides ago, we talked about this agent acting on the context of your organization and your user. Um, so you know, you just don't need AI to know how to create a pipeline. Um, that of course TR GPT and Claude can probably spin up any YAML that does that, but you needed to understand how the organization you work in creates pipelines, right? What templates do we use? what approvals are required, what policies do you need to run, what environments are allowed and that transition from sort of a generic generation to almost context automation is extremely important. The second piece over here that we have is the security or appsec agent. Right? The same kind of constructs apply to security. Most organizations um I would say don't have a shortage of finding vulnerabilities. Right? the like we have a lot of scanners and a lot lot of ways to find problems but the real problem is going from detection to prioritization to remediation so without creating another massive manual backlog or queue. So the security agent here can actually understand the security contacts prioritize risk generated fixes and PRs and almost enforce policies um and monitor your security posture. um real like this is talking about application but like what really changes when AI moves from saying like here's a problem to actually being able to propose the fix especially from a security context. >> Yeah. again like we spoke about the operational aspect of it right like that today like in in many organizations like including uh to some extent harness right like pre the AI era like there's a lot of these sitting in backlog right like you have these vulnerabilities which have certain ETAs you have like cost optimization opportunities you have like performance optimization opportunities but u they not they do not always get prioritized because Again, there's like all other operational aspects which take precedence. But when the conversation moves from, hey, this needs to get prioritized to, hey, this needs to get approved. Here's already a change that I made for you, the the throughput like starts to starts to improve. And that whole feedback loop becomes uh you know like a close feedback loop which which has like a lot of room for uh a a larger throughput. >> Yeah, absolutely. And I think that's much more like useful when you think about model for like enterprise AI which is accelerate the remediation, preserve the control point and really get through your black lock and don't add to what already exists. Um and finally like let's talk about what we're here to talk about which is infrastructure automation agents right um we get to the two agents that are very relevant to today's conversation. We've been talking about this uh blast radius is fundamentally about uh before we make changes right before I make this specific infrastructure change what could it affect what uh depends on this resource what is the actual risk of applying it um is there a risk score and the remediation agent is fundamentally about after so after we've detected drift a cost issue or security or compliance problem instead of leaving just another alert or another backlog item in the queue. Can we determine can the agent determine the appropriate remediation and create the PR um so that I can approve the fix and my backlog is reviewing fixes rather than reviewing uh problems to solve right um so it really like goes from um like should I do this to something changed how do I safely get it back to uh where I should be and that's where the word heal uh starts becoming real right because we're moving beyond detection ing infrastructure problems to really closing uh the loop on that. Um and so rather than me just keep on describing this, I think it's the point where we've come to like show this off. So Rohit, can you just walk us through what this looks like end to end from a govern infrastructure change through understanding blast radius and into how an agent can actually like remediate drift and let's see autonomous infrastructure in action. >> Yeah, absolutely. Thanks. sharing my screen. Awesome. So, yeah, like I think like before we get into the actual meat of the agents, like I just want to set some context for, you know, where we are um from a harness perspective. So, this is a harness platform. Uh infrastructures, code management is one of the many components that harness offers and as you can see here, there's like a lot of other problems that we solve as a as a as an organization. Uh so right now we're looking at a specific you know a specific project. Everything in harness is organized into accounts and accounts have organizations and organizations have projects. This is to ensure that you know users have access to just the entities and uh pipelines that they need access to. So what you see here is a workspace uh a list of workspaces and again like a workspace is essentially a collection of resources. This can be backed by the technology of your choice. It can be open tofu, it can be terraform, it can be CDK. You know, we we offer like a wide range of um you know, tooling to actually back this infrastructure with the ISC of your choice. Um and again like uh if if you get into this specifics of a workspace, it manages a bunch of resources. Um and like like I said, like this is just managing a three- tier web app. In this case, uh there is opportunity to manage and maintain variables and there's governance built in whenever like certain entities change here and also when the actual uh infrastructure is changing in in the context of a pipeline. We also support configuration management and we natively integrate with anible. You can define your inventories and playbooks right within the platform. And then we have a native host explorer where you're able to see all the different hosts that are managing. Um, and these can also essentially come from the workspaces. And we have a native uh bridge between your provision resources within ISCN. And then how you configure them immediately after provisioning or whenever there's a change. And then you can get into a specific host and look at like the health of it, exactly what playbooks ran against it. Um the actual changes and down to the specifics of a given task. Uh and again how all of this sort of comes together is is is in this one unified pipeline. You can provision and configure and deploy uh in one pipeline. Again just to set context, our pipelines are our orchestration layer. uh the pipeline engine and harness spans across all the components that uh I just showed you here. And in this case like I'm surfacing a pipeline which is spread across infrastructure provisioning configuration and also the deployment aspect. So it's provisioning your infrastructure. It's using terraform and it's using open tofu in this case. We have an approval gate built in. This is again something that Reena alluded to and we show a lot of contextual information when a user is actually making this approval right from your cost your security u your uh you know the chain set uh and so on and then you you can then pipe that into your configuration layer where you can leverage anible to actually prep uh these machines for deployment and then you can actually deploy on these machines. So this is just to set the context of like what infrastructure as code management is and again we can get into the depths of this and this might you know uh take its own uh time but we want to focus on the AI aspects today. Now getting into the agent foundations right. So um as we discussed in the presentation there are two types of fundamental agents that we are looking at. There are expert agents that harness um offers. And again you see this little aski icon here. You know you can you can sort of like use this as your interface to uh you know construct your own pipelines to ask questions. And again this is exposed with via an MCP. So you don't necessarily have to come in here and do this in the platform. You can do this from the tool of your choice. And then we have this concept of worker agents which essentially give you the ability to create your own custom agents. Right? So specialized agents with a specific set of rules which can do a hyperfocused task. And as you can see there's a variety of agents here with you know very different um nuances and what they are tailored to do. So let's get into like what this uh expert agents can do. Like I've just run a few examples here in terms of like okay I just asked this hey what are the workspaces that need my attention. It's a non-contextual question and I just want to know what needs my attention. It's going and looping at looking at all of the different workspaces that exist and it tells me that hey like there are a few workspaces where an apply is needed which means a code change has been merged but we've not applied the change and there's a workspace where you know it's actually in a drifted condition. So we also offer like native drift detection it runs periodically flags drift down to the specific resource which is drifted and down to the specific attribute in the resource which is drifted. So now that I I I figured out that this workspace is drifted like I then asked it a follow-up question of like you know what are the percent what is the percentage of resources which are drifted and it it went into the next layer of detail got all the resources and then gave me a drift percentage. So again like this is this can be used for all sorts of operations to create entities and also like gather information in terms of like what needs attention, what needs to change and then I can follow this up with a prompt saying hey can we actually like you know rerun um a plan here which will then trigger a pipeline to actually remediate this drift. Now again drift remediation comes in two flavors. We either like sort of say you know the drifted resources that exist uh the drift that was introduced is invalid and we just like reset it to the state of truth which is the codebase or we say hey like the the drifted the drift is actually valid like you know users just leverage click ops to do this uh but the drift is valid. Now how do we take that into account and how do we then remediate that drift and in this case a remediation means to accept that drift and make certain code changes. Right? So let's look at that example. Uh so again as you see here we are back in the workspaces screen. We have these different insights. Um the insights are pulling in different actions of how we can improve the workspace. So it can be cost insight where you can optimize your cost. It can be a drift insight where you can actually remediate your drift and we have a worker agent which is dedicated to remediation. So as you see here like this I ran a pipeline ahead of time which essentially was triggered from a drifted uh a drifted uh drifted detection that ran on a specific resource. It then went ahead and triggered this remediation agent task. I'm going to show you the logs. It then went and like triggered off an agent which is a worker agent which is spec which is specialized in remediating infrastructure as code related uh issues and incidents. It can be cost related, security related, drift related in this case and then it went and did its thing and identified what was actually uh drifted and then it fixed three attributes and then raised a pull request. So I'm going to go in here, click on the pull request, and as you can see here, it just automatically tells me like what uh what was actually changed, the changes that were made. And if I go into the files changed, u it actually accepted the drift which occurred uh by clickops. So it was able to go into the actual context, look at what's in the cloud, what's in the code base, what is the delta, make this change, and now it's waiting for review. And if if this looks good to me, I'm just going to go ahead and merge it. It will trigger another pipeline which can actually go ahead and do a init plan, have an approval gate, and then apply, which is closed that entire loop of hey, I introduced drift and then like you know an agentic loop kicked in. It identified that there's drift. It triggered a remediation action. It gave me a pull request. And the moment I approve this pull request, it again triggers a closed loop of applying that change and uh going through the entire motions of grid. Uh and the second key thing that we we wanted to talk about is the blast radius, right? Like it is very important for us to understand like what is this change going to do? like and a lot of the times we look at the plan and the plans can be large. It can be across like hundreds of resources. How do we identify if a change is risky? So here's here's another uh of our agent which sits in line with your pipeline and it runs after your plan. It analyzes the change. It it then like uh runs an agentic loop on what is the risk of this specific change. And if I go into the resources section here, so in this case, it's telling me it's a low-risk change. It it gives me a score of how risky the change is. It classifies the risk between low, medium, high, and critical. And then it also tells me like it gives me a synopsis of, you know, what's h what's actually happening in this entire section. And this goes back to our conversation on how do we enhance the approval with more context to give the users the confidence and then eventually how do we make this machine readable for you know for us to create downstream closed loops uh with other agents. We not just have like a highle view but we also have a graphical view of this change and again in this case it was just four new resources that were created. So the change is less risky. Now let's go to another uh example here where the change is actually risky. So in this case it's telling me that it's a it's a 10 out of 10. It's a very risky change. It's telling me that uh this change is actually disabling public access blocks and deleting serverside encryption which is obviously something we do not want. So it's flagging that proactively as a high-risk change. And if we actually go into the graph view you see here that there are different treatments for different types of resources. So a resource which is deleted is in red. It gives the user a very clear uh picture of like what's getting deleted, what's unchanged, what's actually changed and also assessing risk at every node level. So it's going to give you risk at an indiv individual node level. In this case, this specific node is deleted. So it contributes to an overall risk factor of 10. We take into account how dense a specific node is, what type of a node it is and what type of a contextual change it is to sort of like overall assess the risk and come up with a broad um scoring for the entire pipeline. So that's on a very high level you know how we are leveraging both um worker type of agents and expert agents and sort of like giving users the flexibility to create their own worker agents operate within the the ecosystem that they are used to via IMCP and obviously there's a UI to sort of consume this for uh users who actually want to come into the platform but all of this data is sort of available where you are we meet you where you are We give you the ability to create your own agents. We have certain expert agents which specialize in certain uh nuance capabilities and are natively embedded into the workflows. Yeah, that's w that wraps up a quick demo um of these capabilities. >> Yeah, awesome. And I've shared some links about harness AI or infrastructure automation um and the platform itself. So, if anyone is, you know, wants a more in-depth demo, um, sort of like a better pro like end to-end product, uh, demo, feel free to, uh, hit us up, uh, book a demo, and we're happy to sort of walk you through a longer demo as well. Um, and I think we have a few minutes for questions. So, what I will do is switch it up here. Um and then let me open up our questions. So um there was a question here which is regarding improved developer experience with harness which I think was a slide um when we talked about uh uh cursor plus uh agents and harness AI. So how do you control drift once the application goes into production? um organic inter in integrations will evolve slowly over a long time and can create convolted architecture that no one really understands. That's why systems created in 1970s and 1980s are so difficult to work with today. Yeah, I I can I can address this right like again like I think we spoke spoken spoke in depth about like drift like we've seen like couple of approaches to you know maintaining and managing drift obviously like uh one is to just uh say that okay like we just block all click ops access and you know in a perfect world like everybody has to do everything through ISC which is obviously aspirational but u not we cannot completely prevent that. So drift is bound to happen. Now we can create systems and downstream actions to sort of uh take that into account and how do we create a closed loop around it. Right? So first aspect is actual detection and surfacing that data to the users in an audit auditable fashion like can I actually tell you how many resources are drifted in my entire estate like we saw an example of that with you know where harness I sort of answered that uh briefly right like in this pro context of this project 42% of the resources are drifted and then we take that to how do we how do we take action on this right we either remediate that drift by accepting it which is where the remediation agent comes in and it's able to like contextually look at like what has been drifted. uh does that make it does it make sense to accept that drift actually makes that change and surfaces the PR or we say hey like click ops is not allowed and you know we just have to uh reset it to the state and and IA that exists as a source of truth which which again like you can choose to do either either directions but again like as we discussed earlier we do not sort of force users with the tooling of choice and similarly we we offer tools and pathways. Uh we we we have like our own set of like best practices, but it's really up to you to handle how you want to handle certain scenarios, but we we offer like a wide range of u drift remediation techniques which which we discuss as part of this presentation. >> Awesome. And yeah, if you ever want to learn a little bit more, see see a thing, just sign up for a demo. We're always happy to show it. um you know um and the next question is sort of does the blast radius agent detect passive interfaces where downstream system reacts to change data but doesn't have a direct API connection to the source of the change uh we've seen this in cafka pub streams pub sub streams >> again so this is where uh like what Nina was mentioning about the knowledge graph becomes very very important so we are we are able to like correlate an infrastructure chain change back to the services that consume it. We also have a capability around resiliency testing which which then like uh folds into the same thing of hey like we are able to sort of create these u nodes and edges of not just like your infrastructure but build that in context of the knowledge graph which gives us a more enriched like you know blast blast detection capability and comes up with a more holistic score of uh how risk is analyzed and perceived. Awesome. [snorts] I think that's the, you know, scope of all of our questions. Um, just to bring this back to where we started, um, I would like to wrap it up, but, um, I think AI is making, um, it dramatically easier to create infrastructure. That's a given. The ecosystem is also becoming in increasingly machine readable with open tofu, terraform um the all of them releasing like MCP work and the broader sort of agentic workflows all are pointing in that direction which means the answer just can't be simply like you know manual review downstream or manual controls and automations. So as we're uh giving AI more like more ability to act, we need to be very intentional about where it can act autonomously and where humans stays in the loop. And that's kind of fundamentally where harness steps in to act as that control plane for your agents, for your infrastructure, and for your SDLC. Um with that, I really hope you guys had a wonderful afternoon. Thank you so much for spending your afternoon watching our webinar. And um if you have any follow-up questions, don't hesitate to reach out to Roadai on LinkedIn. Uh book a demo on the harness website and uh reach out to us on harness socials as well. Thank you so much. Thank you so much to our speakers and for everyone joining us today. As a reminder, this recording will be on the Linux Foundation's YouTube page later today. We hope you join us for future webinars. Have a wonderful day.