The Agentic Shift in Observability

All righty. Hello everyone. Welcome to the eighth episode of Observability Unplugged. Super excited to have you all here. My name is Kunal. I'm working as a devil engineer at Randoli and I'm joined by Rajat founder and CTO at Randoli and today we are going to talk about agentic shift in observability and specifically about how AI agents are shaping the way and changing the way teams are detecting diagnosing and responding to production failures today and it's a topic that is very much happening right now and people are you know uh talking about AI in every aspect of it so we thought you know why don't we talk about AI agents in terms of observ ility, right? And we have got a very special guest to talk about this, Benjamin. Benjamin, thank you so much for taking out your time for this. Would you like to introduce yourself and tell everyone a bit more about you? >> Sure, thanks for having me. Yeah, my name is uh Benjamin Bangfort. I'm the co-founder of rotational labs. Um we build AI accountability tools uh focused mostly on computer vision and sort of largecale operational AI. Uh so you know our platform is part AI observability and monitoring part uh evaluation and prototyping and part sort of production grade uh operational grade uh AI implementations. >> Awesome. Yeah, I'm super excited to have you here and thank you so much for taking out your time. So before we start a couple of housekeeping things for everyone who's joining in. I see a couple of folks joining in. So I would recommend you can write a hi in the chat and let us know from where you are joining from. And because we are streaming live on YouTube and LinkedIn both. So if you would want to chat with us, this is a link to the YouTube live stream because LinkedIn sometimes lag and I wouldn't want you to have that kind of an experience. So if you want to chat with us and access all the links that we'll send been sending throughout the entire session, you can definitely you know head over to the YouTube live stream that you see right here and feel free to ask all of your questions. We will taking questions throughout the entire session. I'll be on the backstage noting down all your questions. You can share your experience and uh you know in the AI field and how you're using agent and observability. Right. So with that being said, Rajat, over to you. >> All right. Awesome. Uh let's get started. Um once again a big thank you to Benjamin uh for making time to uh you know do this uh podcast with us. Really happy to have you. Awesome. All right. Okay, Benjamin, let's uh start with some of the um the basics. Um you know, we'll start with a couple softball questions and we can we can crank it up. No, I'm just joking. But uh I I think uh you know um uh clearing up some um you know fundamentals would be helpful so we can bring everyone uh into the same page. Um let's start with what agentic really means. Um you know everyone's using the word agent or agentic. Uh what truly makes a a system agentic instead of um just being AI assistant? >> Wow. So, if that's the softball question, I uh I can't wait to see what the questions are coming in later. Yeah, you know, uh everyone is using the word agentic and and I got to tell you, in my research, I studied cognition and metacognition and so I I have a pretty formal definition of the word agent and and that definition does not seem to be what's being used uh in sort of the the AI marketing language that I'm seeing right now. it. But in order to be an agent, a computer system uh not just a program, but a system has to be autonomous. Uh and that uh uh auton autonomous nature needs to have, you know, goals. Uh it needs to decide. It needs to be able to send and receive messages. Uh perceive its environment, plan, uh evaluate plans, and then act. Uh and and so that definition of of goal, decision, planning, you know, reasoning, acting, and then, you know, if if you're really doing well, the metacognitive loop of evaluating the cognition to see how well and create new goals. Uh that's that's really what makes an agent an agent. And I think that LLMs are a very interesting tool to um do agentic things. And certainly we could see things like tool calling or MCP servers as potentially being uh acts or actions uh for for autonomous behavior. Um but you know I think that one of the really big things that's missing is specialization, right? You know agents do something very particular. They're not just open-ended broad can do whatever types of things. It's like that's not how we hire human employees, right? We hire human employees for specific jobs. And so for a system to be agentic and not AI assisted beyond that formal definition I think that they need to have a very specific task that they are well trained well tuned on or set of tasks that they are um and that we as humans have trust that that agent can act and that when it's unable to act that it will escalate um whatever uh it's in charge of in that very specific task. >> Great great start. That's a that's a very um um you know that's a really great explanation. I I loved it. See see I told you it's you know >> bringing in the computer science first thing here. Right. >> All right. So you you know you use the word autonomy um and and and that's very important uh you know in the context of an agent system. Uh with autonomy um there are other questions around it right like so um when when an agent has autonomy that means it can plan and execute certain things. Uh how should we structure this right like um you know where should autonomy stop and what decisions um you know um should be delegated uh to an agent versus when it should be escalating. uh how do we how do we think about that right I mean uh because that's at the sort of the heart of it right like people are on one hand uh unwilling to trust something that can think for itself and and make certain actions especially in the context of a production system >> how would you you know help us break this down and and and you know put some uh color to this Yeah. And and that's a great question. And I think that technically, culturally, philosophically, we aren't prepared for autonomous nonhuman agents, right? We can't reason about them. I think the biggest trap that organizations and developers fall into is they treat AI systems like they are deterministic software systems. And and they simply are not. um they are probabilistic. You know, I think that a lot of the conversation goes around confabulation and hallucination and those types of things, but even if something is not necessarily a confabulation, it will never be 100%. And that's by design, right? Uh when we communicate with LLM systems, it's through natural language, not a formal language like a programming language. Natural language by design is ambiguous, right? It's meant to bridge communication gaps between two brains that have different experiences. It's not meant to communicate very specific instructions that need to be followed. Um, that's what programming languages are for. So, if we are going to delegate communication in natural language, then my biggest piece of advice was treat agents like humans. you have to. And so instead of saying what do we need to do to trust an agent or when do we delegate to an agent or not delegate to an agent like let's look what we do in human systems right in human systems it's about uh segregation of responsibility right you're responsible for this you're responsible for this and this that limitation of responsibility gives you trust that you're not overloaded or you're not doing too many things it's about training uh you know the more proof that you have over time either from education, experience, training, the more responsibility that you're willing to give a person, the same should be true uh of an agentic system, the less trust that you have in an agent, right? Uh the more monitoring and the more uh attention you're paying uh to that person, the more supervision that you're given. Uh that's why we see hier hierarchal uh human organizations, right? where there's sort of management that gets you know you know at the large scale management at the bottom managing the people who are actually executing tasks so um if you start thinking about it in that way then you know these ideas about autonomy and delegation become a little bit easier I think right because at once if you're thinking about this like a human person you can say oh they're doing way too much a single agent should not be in charge of s sur for an entire data center because we wouldn't let a single human do that, right? Um, in terms of delegation of decisions, it's about how important is the decision, how much risk is there? And just in a human organization, the more risk, more important the decision, the higher up the chain it goes, right? And and we do we should do the same thing with uh with how we view our agentic systems as well. Only difference between an AI agent and a human employee is the tireless ability that an agent has to do repetitive, boring, inconsistent tasks over and over and over again, possibly at scale, possibly at speed, but you know, that's that's really the only difference. Um, otherwise the same amount of uh of cognition and trust and delegation we should put into our agents as we do it to into human agents. Um I I I love that explanation and and and love the analogy. I mean you know thinking about agents just like humans and um certainly with humans you still have the trust factor right? So for some people we trust more others we'll have to do a little bit more supervision. But the other uh point that I got from this you know you talked about the tireless factor like you know a human waking up at 2 a.m. certainly tired sleepy u versus an agent that's uh you know probably be able to operate at a slightly better capacity may not have the same I guess um depending on the context the same experience etc. But the the fact that uh it's always alert, it's always running and like you said at scale uh certainly can uh give an advantage. Um amazing start. Um now I have another question and I see two questions from Manoj. Manoj I'm going to take that on in a in a in a second. You did mention about probabilistic uh reasoning right? um what's the just for the you know folks who don't have a um you know a background in uh you know AI what's the difference between say probabilistic reasoning versus you know um causal um sort of reasoning how and and in most um I guess when you talk about things like um you know remediation of a production system people are generally don't want um you know random random um root causes or remediations being done right in that context if you can give a an example and explain the difference that will help uh folks who are not too familiar with the models. >> Absolutely. Yeah. So mathematically speaking there there are two types of of reasoning. There's symbolic reasoning and there's probabilistic reasoning. Um, I'm going to just say that for the most part LLMs don't reason. So, I know that there's a lot of marketing material coming out of Anthropic and OpenAI and Meta and others talking about reasoning and chain of thought. Those types of systems are actually augmentations onto the LLMs. It's not an LLM behavior in itself. All an LLM does is generate a sequence. Um, and that sequence is is usually language, right? Uh, that's that's all it does. You have to augment it with something else. Uh, generally speaking, probabilistic reasoning is a little bit easier. So, probabilistic reasoning in a mathematical form usually takes the form of like basian networks, right? where you sort of find the sort of maximum likelihood estimate of this is the probable cause based on these prior conditions that we've seen that propagates probabilities through these conditional probability networks and then you get these sort of probable causes those I mean for a long time in computer science we called those expert systems that type of probabilistic reasoning has been used in medical diagnostics car diagnostics aerospace space. Um, you know, there were simple versions of that in the Apollo space program. So, like that's that probabilistic reasoning has been around for a very long time. The difference now is that we're doing it much much bigger. And the thing with probabilistic reasoning is that probabilities can get very small and you end up having you know a float can only be so small or float 64 can only be so small and you end up with these very very small numbers especially when you have huge numbers of conditions and so that's when these LLM techniques really start to come into play with deep learning and and different types of things that they do. So that's the the probabilistic reasoning. there is something that's categorically different that's symbolic reasoning. Um and I would like to see that symbolic reasoning uh you know being used more and I think that there's a lot of people uh experimenting it with it. Now I know uh Yazakun for example is looking at world models that use ontological systems under the hood and ontology is a form of symbology that can use graph uh processing to do that types of symbolic reasoning reasoning. uh predicate you know logic you know you know modus ponins type inference that's another form of symbolic reasoning uh and lambda calculus is another form of symbolic reasoning and and in computer science in the academic space those are the tools that are generally used for reasoning the disconnect and I think what everyone's looking for right now is how do we bring that symbolic reasoning into the agentic space get it out of academia get it into a space that's sufficiently large enough that we can deal with it at scale. And I that's that's kind of the next frontier. And I think that once we hit that, we're going to see a fundamental change in the way that AI systems behave and they'll become a lot more trustworthy. And like I said, there's some very smart people working on that problem right now because reasoning is the clear gap in these AI systems. Even if you print out a chain of thought, you know, you you you still just always have questions about like, well, is that really the right thing? because it's generated, you know. >> No, great. That's again another um you know, PhD level answer. That's a really great Sorry about that. >> No, no, no. I I I meant that in a really good way. I think um you know, a lot of folks would benefit from uh that answer. I I loved it. Um and and and to your point, I think, correct me if I'm wrong. Um just kind of you know a little segue most like everyone was working on this symbolic uh branch and and um nobody took I guess Jeffon seriously when he was looking at the other other other branch and in fact u it took people a while to accept that and then suddenly that became more mainstream. Um, so just a little bit out of the topic, but why do you think that sort of happened? I was like, you know, people were for good reasons obviously wasn't very trustworthy of the the probabilistic approach or didn't see promise and now suddenly um you know that that that came into the spotlight and and you know blew everything uh up. Uh what are your thoughts on that? >> Well, it's it's uh it's a matter of application I think. um you know the tools that we use in the commercial space you know in the non-academic space focus on very specific domain problem solving um I think that the big opening for LLM systems in particular was moving away from just generating data to chat right and that gave everyone the opportunity to interact with these systems in in more of a meaningful way to really start to devise applications that could be built up on top of it and The ironic thing is like we're now moving away from chat like chat got us in the door but now it's like okay well we actually wanted to generate JSON right or we wanted to process these unstructured documents and and generate a structured representation for our application so we've moved away from chat to more domain specificity but that's I think chat is really what opened the door because like I said at the be you know earlier culturally technically philosophically you know We just aren't really ready for nonhuman autonomy and so we kind of have to dip our toes in slowly and chat was that slow to dipping in to sort of open the door to keep keep moving forward with these types of technologies. >> Again, great answer. Um Kunal, can we put Mano's second question? Um I I think Jeff Benjamin answered that to a to a to a large extent. U if there's anything more to add here. Uh it's a question from Maloj. >> Um I I think that an LLM is not the only part of an agentic infrastructure. So, you know, I I think that, you know, people sort of assume that, you know, uh, Claude or Bandit or any of these like there's just a single LLM that's running and that's not in fact true, right? It's actually probably several LLMs, some deep learning models, computer vision and multimodal models. There's probably some guard rails and deterministic structures in the back end. So, I'm not saying that an LLM is not the right thing for an agent. I'm just saying that an agent requires more than just an LLM, just like a human needs more than a frontal cortex, you know? So, it it might be a part of it. That said, I'm hoping that LLM start getting smaller, not bigger. Um, >> so small language models that are specialized, right? >> Yeah. uh that that would be you know I don't I think that we're starting to approach the the asmtote of parameters like increasing parameters increase more effect I think GPD5 was like the first signal of that that more parameters isn't necessarily better um an LLM is really a brute force solution uh to a state smoothing problem and better algorithms can absolutely do a better job with less energy and less compute. Um, so and if if there are those other algorithms that are more deterministic that are used to augment LLMs or to augment a network of LLMs, that's probably what we are going to recognize as agents in the next 10 years. that that sort certainly you know based on very little knowledge I have on the field that's sort of what I am sort of reading into as well and in fact we're taking some concrete steps on how to figure out we can build a small language model around that also your answer it reminds me of that conversation we had a couple of weeks back where we talked about specifically manu's question how do we take in you know you know that probabilistic model and or approach and then build some deterministic guard rails around it. Uh and again, you know, thanks for reinforcing that. So that's actually great. Um and you know, explains um how people can rein in some of the chaos and the hallucination around agents and and like and like you pointed out the LLM is just one part of an agent approach and that's also another key piece of information, you know. Yeah. Awesome. I have one more sort of theoretical question before we kind of jump into the practical aspects. Um, this is again, you know, me trying to get some answers from you on some some of the personal questions that I had as well, right? Um, you know, is an agent fundamentally just a control loop with the probabilistic reasoning layered on top of it. Uh, I know we've sort of talked about it a little bit, but maybe I should have asked this question a little bit early, but some people are like, you know, explaining this um as such. What are your thoughts on that? Um, you know, it it could be. It's not the way that I design uh agentic systems. Um, you know, the the way that we design agentic systems is is we create an agent that has a very specific domain. And that agent at its core is a a set of tasks, a set of discrete tasks. Um, we always give our agents names and descriptions to really specialize them. Um, and we also give them business aligned objectives. Uh, so we say like these are sort of the key performance indicators for you as as an agent. And all of that text and that input serves to guide the supervisory process >> um in the agent. And then the agent itself is a set of tasks, right? So we define a task as you know sort of a discrete input coming in uh some sort of context processing a prompt that's rendered on a per task basis and then that prompt is sent along with tools like MCP servers to a single LLM and then that LLM can decide if it wants to call those tools or not go back and forth and then produce some output and that that's a single loop of the task. Um, and and that's what the agent does. And and what that means is that the agent's not based on a single LLM because every task can have different LLM. So if you have a task that can take advantage of an 8 billion parameter model, absolutely you should do that. If you have another task that requires something a little bit more robust, then you use it for that task. But the agent is these collection of tasks. And then the agent has the tasks and all of the descriptions. So for any sort of incoming input, it can look at its set of tasks and say, you know, okay, I want to use this task. I want to use this task or it can combine those tasks into a workflow. And so when I frame it like that, the control loop is actually defined by us in terms of the tasks and the workflows, what MCP servers it has access to, what tools it has access to, what data sets it has access to, how the context processing goes, that is all deterministic, right? So you're asking if that's a deterministic control loop. It it is. And then when you surround that by guard rails, you know, you get a more robust system uh that can do very specialized work. But the key for us when we're building agents is if a piece of work comes in that none of those defined tasks fit with that piece of work, the agent must reject it. And I think that is the biggest problem with you know the whole idea of probabilistic reasoning with a control loop is that an LLM will not say I don't know or I'm unsure or give you a confidence estimate because all it's doing is generating text. Right. >> Yeah. And so that at the moment until those sort of reasoning systems that we talked about before are actually really influencing uh LLM or AI behavior. Uh you really have to put really strong controls on top of that control group. And you know I hopefully my description of how we build agents you know jives with what I was talking about before of what an agent is is you know very specialized specific domain engineered thing where the context is really richly creatively defined and evaluated on an independent uh basis. >> Awesome. I mean again I think this first you know 25 minutes was um really powerp packed with some very very good explanations. Thank you for that. >> All right, let's uh switch tracks and try to uh talk about some of the concrete applications of this especially in terms of um observability, right? Um just for more context um you know Benjamin also u runs a startup and like any startup founder u we sometimes have to do wear multiple hats and one of those hats um you know happens to be uh doing devops sari work right and and supporting the your your customers in production so he's uh definitely definitely qualified to talk about uh observability related issues um by actually living through the pain and and doing the work. Uh so just so that I set the context uh for our audience where he's coming from right now you know we've spent a decade um you know looking through u you know like the the telemetry right now what we have is not a lack of telemetry but sometimes more but you know that hasn't really we have observability you know through the roof but it hasn't really materially reduced the cognitive overload uh on on my s during an incident, right? In fact, the surveys show that uh MTDR is rising uh as the systems get more complex. So, it's definitely not a lack of telemetry u right um care to add your thoughts on that like you know let's start from there and then we'll build up. I mean I absolutely feel that pain and and I I would say not just in incident response but even just in like deployment >> deployment yeah >> development cycle yes >> development cycle yeah you know so uh yeah we uh you know like re mentioned we're we're a team of 10 right so we all have many hats and uh yeah my hat one of my hats includes DevOps and uh we're running clusters in in North America Europe Asia, you know, we've got sort of five Kubernetes clusters that are running. We have, you know, suites of applications that we're deploying for our customers and and uh it, you know, as a small team, you know, that that's absolutely a nightmare. And you're absolutely right, like everything we do has open telemetry built into it and open observe and, you know, we we uh we try to be sort of fully cloudnative and cloud agnostic. And that's sort of another source of pain is that we're across like multiple different clouds. So there's no easy button for us certainly when it when it comes to observability. And um yeah, it's just what I've noticed is that the definitions there's just huge amounts of YAML, huge amounts of log, huge amounts of spans, um lots of metrics, but the thing that went wrong or the thing that you need to change is one line, just a handful of characters somewhere in this very large system. And uh you know you're absolutely right. You have to funnel down all of this information to find that spot. And so to a certain extent you know spans and tracing allow us to you know find threads and pull on them. But you also got to find that thread. And so I can I really understand why the MTR is increasing >> as the amount of information that we have increases. So you you you really set me up for my next question. um you know that's about correlating the signals right like um if you find where to like I mean if you end up you know knowing where to look for it becomes easier but that's the harder part right >> so there's a lot of talk about u you know correlating between signals um you know and then there's also the the reasoning about them right like so um now let's put some um some of the I guess the the background material talked about right from a agentic perspective. Let's talk about correlating signals and and and reasoning and and sort of like what's the difference between them and you know how can these tools help. >> Yeah, absolutely. Um so one of the the main analogies that I like to use with incident response in large scale systems is immune systems. Um and there's actually a lot of computer science algorithms that use immune systems as a sort of metaphor or a model. So um you know I guess if you think about it any normal operations will always usually follow the same patterns right so you know you'll have these sort of web applications where there's like a login and a sequence of normal actions and you know those sequences of normal actions will cause backend uh actions and database queries and you know over time you can sort of learn what's normal normal, right? What's normal behavior uh in in the system? Um and you know, that's not necessarily an LLM thing. There's there's a lot of different machine learning tools that that can do this sort of autoimmune system. Um but by sort of building up this sort of idea of what's normal that helps you uh do anomaly detection, right? Like what is out of the normal um and that anomaly detection really should be what we're doing for sort of the primary alerting, right? like you know something is out of the normal here whether it's a bug or uh errors that are being thrown that weren't being thrown when on the last deployment uh you know or even if it's an attack uh of some sort. Um you're sort of creating that normal environment uh is is sort of the the pattern recognition part of of what you're saying. Now the reasoning comes after right like Go ahead. I'll let you finish. Let's go. >> Yeah. Just to finish up. The reason it comes after like once you've decided that something's abnormal, right, the question is, okay, well, now what do we do with this alert? And I think that's where agentic systems come in. Um because a lot of times knock operators get overloaded with alerts, right? And so a lot of their work is suppressing alerts in order to find the signal in the noise of alerts, right? Because you know abnormal things just they do happen, but that doesn't mean they're bad. So you got to suppress the signals. But if you put an agent into the middle and you don't suppress the signals and you have that reasoning component, that's where you might get some more effective uh S sur. So that's kind of where I would divide the line between an agentic approach to observability and just sort of that that pattern pattern recognition of of what's normal behavior and what's not. >> That again is a great insight in terms of using an agentic approach to look through all the the signals and and figure out which one's valuable, which one's not. Because um alert fatigue is a thing. Uh and what often happens is sometimes uh when you suppress these alerts, you tend to miss uh sometimes the the the right signal as well, right? Um and so yeah, this is actually, you know, great insight. One other thing that I wanted to kind of um touch upon. So we we talked about identifying the normal. That's also easier said than done because uh for some businesses it's um a little bit more predictable for others um completely unpredictable. uh so for example let's say a ride sharing app where you know I'm understanding better about these um different businesses as we onboard more customers where they have some predictable patterns like you know morning rush hour evening rush hour um you know or um some sort of a special location kind of happening but then you suddenly also have um a weather event or or some sort of um other event that is not very predictable and then everything goes haywire. So generally the humans are able to understand. So if I say I'm I'm I'm an S sur I'm I'm looking at it I can understand if a weather event is happening or something special happening because I you know I hear about it through the social channels or the weather app whatever. So I am able to look into that and figure it out right in in the context of a of an agent um or or a machine learning model that actually doing anomalous detection. It knows about the regular patterns right the morning rush hour evening rush hour and then you suddenly get hit with this. So these are things that are probably unavoidable but curious to know your thoughts on that. Well, yeah. I mean, it's I guess it's sort of an interesting question of of doesn't s sur need to know why, right? Which which is actually a fascinating question. Um I mean uh the pattern recognition anomaly detection system will detect like there's something abnormal going on in the case of a weather event. It won't necessarily come up with an explanation for that. Um, in order to come up with an explanation, you need to feed in way more context. >> Yes. >> That is, um, it's actually one of the things that separates humans from agents, right? Like humans always have too much context. Agents can operate more efficiently because they have less context, right? So, I think, you know, when you start to ask why questions, those types of questions might be better delegated to a a human rather than an agent. But that's not to say that you can't have an agent make suggestions about why uh something is happening as long as you're feeding it correct context. But that should be not a live system, but maybe a augmentation system for the knock uh as opposed to uh something that's running autonomously. >> Awesome. Again, you kind of set me up for the next question is when to bring the human into the loop. We're not talking about completely replacing humans. We're talking about humans and agents working together. I'd love like the way you explain that humans have too much context and that's why we are not as efficient as making decisions and agents are more efficient because the context is small. So how how would you like I mean again that that human in the loop is going to be very interesting. So when people are building agentic systems they have to think about this where should we bring in the human where should we delegate it to them you know where should we get their input is that um you know you want to because you are in the I guess your day-to-day life you're looking at this you advising customers can you give us a little bit more advice and some sort of uh I guess guard rails you know in designing agentic systems keeping this in mind >> yeah there are a lot of tasks that I do in DevOps that I don't think I should be doing. >> Yes. >> You know, generally speaking, the the line is, you know, what is the risk and, you know, what is what is the sort of beneficial impact and and sort of thinking about the trade-off between those two things. Um, as an example, one of one of the papers that I wrote uh in doing my research was um a self- augmenting system uh that used uh read and write patterns to to automatically determine replication behavior across a globally distributed network using multi-armed bandits, right? To figure out where to place objects and how to maximize consistency uh while minimizing network traffic and and storage load. And if that sounds boring to you, like that's exactly why you would use a multi-armmed bandit to do that, right? Because that's not something humans shouldn't be doing that, right? Humans shouldn't be defining replication patterns in underlying systems. Uh going to Kubernetes, why do I have to decide what the resource requests and limits are, right? like it feels like something should be looking at the usage patterns of all my pods and sort of allocating the resource and and limits uh you know correctly to my pods. That's not something I can come up with without some sort of analysis and I would happily delegate that to to an agent. Um, we recently had sort of a a spam attack on our registration system on on our website and it's like, yeah, no, if you shut that down, right, start collecting those IP addresses, that's absolutely something that I would allow an autonomous agent to like do, right? Uh, so, you know, there there's sort of a lot of different things when you start looking like farther down in the system at like the really like, you know, low-level things that absolutely that should be autonomous. it should be self-repairing. We're definitely headed that direction with with some of the systems that are being designed and and some of the newer distributed systems that are are are coming out of academia. Um and and we'll absolutely get there. Uh when the risk goes over the potential benefit, you know, if if the thing is doing things like changing passwords um or uh sending emails on your things, >> you know, that's that's when you enter that gray area. And then I think there's obviously a really clear like humans should make decisions about this things about why questions, right? Or or fundamental design changes, right? Those should be in the hands of human operators. >> Well, thanks. Um that that's a great answer and um you know I think a couple of weeks we discussed this um I got some advice from you on that that matter. Um when we experimented with sort of runbooks and that can be run automatically this was more or less kind of like our thinking as well like what's the the risk factor is this something uh that we would even delegate to like a junior s or not kind of thing right so that helps you inform what you can let an agent run automatically and which ones you want to prompt the u you know human to to execute um you those tasks like whether it's a runbook or some other sort of action. Great. Um we talked a little bit more about you know in the in the context of this uh conversation uh about pattern recognition and you know getting to sort of like the root cause analysis and you said the agent can potentially recommend or suggest right and and perhaps the human can then look at it and understand it. So to what extent the modern uh advances that we have that is u sort of available to the masses if you're build let's say you're building a root cause analysis um based on um you know pattern recognition and other things how would you think about um you know where would you draw the line um you know how would you how how do you design it? What do you what are your thoughts? again. Sorry for all the ramping it up a little bit, but >> no. Yeah, that's I mean it's absolutely a good question. Um, you know, the the the practice of root cause analysis is to find solutions that will prevent those problems from happening in the future. And I'm also just going to be a little bit honest here. Uh it's also to find blame, right? Uh because whether we like it or not, there will probably be a lawsuit. There will probably be repercussions for an event that has a root cause analysis associated with it. And and part of our system requires, you know, you know, a little bit of blame there. So uh I think that an autonomous system is very good at sifting through the observability meer to find those threads that you can start to pull on to find the root cause analysis. It's very good at finding patterns that can indicate systemic failure. I will say that in my experience most root causes are very unique, very exotic in terms of a pattern recognition. uh analysis and and that actually makes them even more well suited to an anomaly detection system, right? The more exotic it is, the the the easier it is to find. And then we also mentioned that potentially if you feed some extra context, you know, an agent can come up with recommendations of why, but those recommendations should always be a ranked list before you move on to the decision of what was the root cause analysis. only the human operators have the sort of understanding about what are the consequences, what is the litigation responsibility, you know, and and only they can really decide what the root cause analysis is as a result. So that's that's kind of the line of of actually saying this is it, this is what happened, you know, because humans can be wrong and agents can be wrong, but only humans are liable, right? Software systems are not liable until we give uh our legal system gives special recognition to uh an autonomous system as as being liable then uh the humans are always going to be liable again another great insight. Absolutely right at the end of the day the yeah the humans are going to be responsible and left holding the bag. Um there's an um you know interesting question if you can take a minute to answer from Manoj. Uh you know um here you go. Yeah. Uh there are a lot of different types of guardrails. Uh both deterministic and non-deterministic. Uh so uh yes observed by another specialized agent. There are a lot of systems where, you know, it's basically a prompt that wraps another prompt and you're asking the LLM, can you see a prompt injection attack in here? Can you see sensitive information here? Named uh named entity recognition in here. Uh so those are one form of guardrails. I think that llama guard is one of the best examples of the open source world of of that type of guardrail. Uh the the observed by another specialized agent by guardrail. Um but there are also deterministic guardrails. Uh so for example for sensitive information named entity recognition uh we use uh like gliner uh on our input prompts to sort of figure out if there's anything in in the prompt that could be uh you know sensitive information leak. Um there are uh uh fact-checking guard rails where you um basically have to have citation references uh in the guardrails and and so you sort of check to make sure that they're guardrails or even just like simple things like if you're expecting JSON generated output like you match it to a JSON schema like frankly that's that's a form of guardrail that's that's very deterministic. Um, so, so there's a lot of different guardrails. Guardrails tend to work like middleware, right? So, you send the input through these middleware guardrails to make sure it gets through before it gets to the LLM. The LLM produces output and then you send it through the, you know, the middleware output guardrails again to make sure that everything's safe. Uh, another very popular one is like content moderation. Um, so for example, for like an image, you know, if you want to make sure that it doesn't include um, you know, something that's NSFW, then you would create a text description using um, you know, a model like moonlight uh, of the image and then you would send that text description through like the AGIS classifier, which is the Aegis safety classifier to determine if it contains like violence or sexual content or or anything like that. So, lots of different types of guard drills, both deterministic and non-deterministic, not necessarily agentic, sometimes agentic, but always they should be used. >> Awesome. Yeah, that's actually a great um great piece of advice and and one of the things that we've noticed is that and and obviously we had some benefit of having this conversation some time back as well is um by validating and controlling the the inputs and the outputs that drastically improve the the correctness or the reliability of the the answer in in the whole root cost process. So that that's that's amazing. Thank you. Um all right, let's switch tracks a little bit and and I think again you kind of set us up for the for the you know for the this final segment. We'll talk about you know reliability, risk and governance. Uh you know we have to we have to do that. Um you already talked about my first question though which is about you know when some when you know when an agent make a recommendation some action is take who's accountable you know when it is wrong currently it will always end up being being the human or the organization because agent is not uh you know when strictly speaking from a liability legal liability perspective >> uh but you know how can we um setting aside the sort of like the whole legal aspect of it. When um when we build these systems, we have to almost build some sort of auditing capability but also some way of u providing the the users who are going to be in the loop or the humans in the loop to have some mechanism to understand where this reasoning came from or where this recommendations came from. and and that's that's something that's important. Can you talk to us a little bit more about how when we're building agent systems, what should we do to increase the the trust factor? And this is also extremely important in observability because you'll sometimes have to make decisions under pressure. Your systems are crashing. The agent is giving you this uh recommendations and suggesting you run these remediations. >> How do we build that trust factor? >> Yeah. Well, uh, you know, we, you know, in the systems that we build, governance is incredibly important. Um, auditing is actually one part, but like you said, explanability is the even bigger part of of that. So, um, in in our systems, we always have an audit log of specifically the agentic action. So, it's a little bit higher than higher level than traces might be in an observability context. Um but specifically you know what models being used any seed like random seeds any temperature variables like we want reproducibility from the audit logs and then we save all context all prompts everything in and out of the LLM at all steps of our task workflows. Um, and then any auxiliary data that comes along with it, like if you have like a chain of thought or uh if you have like an explanation prompt guardrail like explain why they came up with this, then we also save all of that information. Um, and you know, on some ways like observability, it's something that you have to have and you have to record in order to take remedial action. uh and it generates a huge amount of data that then may need another agent to to sort of look through all that data to to explain things. But uh but certainly for now that's incredibly important to to build up the trust. Um because you know like I said if you think about it like a human right you know we give authority to humans based on levels of trust and the same's got to be true for for an agent right so if if the agent is new you should fundamentally not trust it right you should test it and evaluate it and make sure that in as many situations as you can think of that it it is doing what you expect it to do before you even give a modicum of responsibility, right? Um, and you should try to refine it and specialize it to make it better at its job. It's exactly what we do with a human. Then you give it limited authority to do limited actions, right? And let it run for a long time. And as it gain more trust in the system, you can give it more authority authority to do more actions. Um so uh access control is incredibly important um you know for read and write operations because I mean honestly like what is an action or autonomous in in an agentic system is fundamentally calling an API and executing a command right that's fundamentally what it is. So read operations are generally not dangerous. It's the right operations that we have to be primarily concerned with. So really restricting on the permission side what an agent can do and not do will prevent tripping hazards, right? >> Yeah. >> Um and then the other part of that is and when do you bring the human in the loop, right? And again it is a balancing act because you don't want to just spam the user like the operator with I need you to make a decision on X, I need to make a decision on Y, right? Like the point of an agent is to alleviate that time and cognitive responsibility from the human so they can do other things. But at the same time it's so it's just like a junior employee, right? Like the more junior you are, the more time you have to spend. The more senior you are, the less time you have to spend. So that also comes into the alerting and and sort of the the you know create a human to make the decision um you know to to fundamentally take actions. >> Amazing. I I I I you know again a great um sort of explanation and um um you know let's uh um let's now uh jump into sort of like our final segment actually sorry I I missed one great question on this and given that you have a background in distributed systems so this is this is going to resonate I mean they are already complex as it is now we're adding agentic layers on top of it are we introducing more failure modes And we, you know, we kind of briefly talked about it. Perhaps add a few thoughts here before we jump into our final segment. >> I mean, simply said, yes, we are absolutely adding more failure modes. >> Yeah, >> we're adding more observability data, adding more information that we have to respond to. Um, so yes, is a simple answer. We're adding more failure modes and I I mean but again it's the same as as you get larger systems you have to have larger organizing principles and large larger means more failure modes. So um and we're just at the beginning of this right uh you know I think 2006 was kind of the first breakthrough with with language models deep learning models have been around for a very long time since the 1930s they've been used in air traffic control and long distance and you know but fundamentally this is all very new uh what's what's happening and uh we don't even understand all of the failure modes >> uh quite yet. Yeah. So, um, yeah, we are it's going to be an adventure. Just like the the beginning of the internet was an adventure. Right now, it's going to be an adventure with with what we offload and what with what we don't offload. But yeah, we're absolutely adding way more failure. >> Great, great comment. Um, yet again, you set me up for the sort of like the final mini segment. Uh, we generally talk about uh the trends and the next three to five years. So here are two more uh not so softball questions. So so the first one is um we got to talk about the human impact of it right. So going forward um do you see the role of an S sur evolving into supervising and managing a fleet of uh S sur agents who are like or agents that are acting like junior sres uh or rather than just directly debugging systems. So right now SRES have this you know I guess thankless task of sometimes getting their hands dirty like going deeper into telemetric figuring it out and then figure like you know figuring out the root causes then the remediation. Will that transform into where they will have an army of agents doing the heavy lifting of like you know doing the debugging and remediing out the remediations and and the job of their sorry is now about hey they're being the human in the loop to say yep let's do this let's not do this and you know being more of a I guess a human supervisor uh for these agents >> I mean I do and I hope so and not just sres I'm hoping that a lot of jobs become more like what you just described. >> I try to limit the can but >> I know you can't kind of know this. I think that the SR thing will happen sooner than say um you know manufacturing, right? Correct. Although >> you know my father-in-law worked for uh you know a big manufacturer and he supervised robots. So it's like that that's been happening for a long time already anyway. But yeah, I think the SR re thing and and I think developers are more prone to pick up these agentic tools more quickly because uh you know that's sort of in in our tech space. But you know, I would certainly like to see uh agents helping out in in legal and medical situations and and sort of augmenting any decision-m behavior like an S sur. That's that's what I'm hoping hoping to see. So um you know SRRES you know information technology is fundamentally going to underpin the economy. S SRRES need to be more effective at their work not more overburdened. So yes they should be managing an army of agents. I will say that the current algorithmic stack is not well suited to that. So I am not saying that this is a tomorrow thing or a today thing. I'm not saying this is next year thing. Right? We already talked about some of the developments like world models from from Yan Lun, different types of reasoning models that you know different types of planning and execution that need to happen uh in the agentic space before we can get to that point. But hopefully within 5 10 years that is what the experience of an S sur will look like as well as an X-ray technician right and uh you know a postal office worker and really you know a lot of people should be feeling like in 10 years that that will be their job. >> Awesome. Uh final question and u again slightly I guess on the controversial side. So right now teams are responsible for MTDR. A lot of organizations that are you know very much into this incident management culture religiously track MTDR and the teams are responsible for it. In fact um some managers compensation is tied to maintaining those SLAs and and you know maintaining those MTR numbers. When we shift to this that what we talked about will MTR become more of a measurable property of the the system itself or some sort of vendor that they purchase u rather than the team operating it or it'll be a shared responsibility >> who are you going to blame in you know uh when something happens. Yeah, it's a very interesting question. I mean, MTTR should be a property of the system. Uh, I think it's a human instinct to make it a measurement uh like a key performance indicator. Um, because there is a limit, right? Like at some point MTR is so quick that it's meaningless if it gets quicker, right? So I really do think it should become a property of of the system because it'll be like because it's so fast that it doesn't matter, right? >> Yes. >> Yes. Exactly. Thanks. I mean that's what I was thinking too because you know we will probably get to that point where it is going to be very quick that it is you know less meaningful than what it is today. Right. >> Yeah. Exactly. You measure it in hours, it matters and humans will evaluate each other. You measure it in minutes, maybe not so much. >> There you go. Awesome. That's a great sort of ending to our segment. Uh I Benjamin I it's been a real pleasure speaking with you and I think uh it was this is one of um one of the best segments that we've had. lots of great uh pieces of uh wisdom for us and uh lots of good explanations and u I hope the audience also found this very useful and you know thanks again uh Kunal you want to um you know get some final thoughts from Benjamin and we can close it out and for a change today we are on time too. Oh yes, I was just uh making a couple of notes on the side as well because there were a lot of interesting things you shared Benjamin. Um first of all I just loved all the points that you shared and I feel that this this particular topic is interesting because this whole discussion of AI agents and using AI in DevOps and observability is rel relatively new right and because it's new we are seeing a lot more interesting use cases and you know we'll see we are seeing a lot more interesting questions. It's sort of like how how things started when Kubernetes was introduced, right? People are experimenting with it, asking different questions, asking different use cases. So I think that is why this whole topic is pretty interesting and definitely I believe that you you both covered a lot of interesting stuff. Um but yeah, uh do you have any closing remarks for anyone who's watching till this till this particular point? >> Sure. I mean I just want to say thank you guys for having me. Uh, I I really enjoyed the questions. I I hope it wasn't uh too academic, but >> No, not at all. Not at all. >> You know, I I I do really enjoy talking about the philosophy behind these things, not just the the practical practical applications. So, I appreciate you guys giving me the chance to do it. Um, uh, if anyone's interested in building aic systems, uh, you know, we'd love to come visit us at at rotational.ai. Um and you know all of the things that we talked about the principles you know that's that's how we build things and and that's how our platform uh builds things as well and uh you know uh really enjoyed watching you guys build those types of things into into your platform uh as well with the the runbooks and that kind of stuff. Yeah, thank you and and thanks for being a you know an advisor and then also like some like the knowledge you shared today, you know, really really great. Um and and guys, yeah, please check out rotational.ai um Benjamin's uh Benjamin startup. They're doing some really really cool things and uh and if you haven't already, follow him on LinkedIn. uh he regularly shares his opinions uh on on on the topic and and I for one always keep an eye out for uh his posts. All right, >> Michelle. >> Yeah, definitely. And if you watch if anyone's watching the recording right now because I see a lot of people watch the recording. If you have any questions that you would want to ask to Benjamin, you know, feel free to drop them in the comments and we'll make sure that Benjamin answers those questions. We'll we'll catch him. But yeah, appreciate Benjamin and appreciate it Rajit. Uh, thank you so much everyone for watching and we'll see you in the next one. Bye-bye. >> Thank you very much. >> See you guys. Bye-bye.