Birol
00:00:00.000
Of course, I wouldn't start with that, and that's not something I'm seeing as of today consistently, and I wouldn't even recommend it, that you run an agent that works exactly like that, fully autonomous, only pages you by exception. but I think that's where we're heading, that humans will only be paged for novel incidents when an agent gets stuck
Darin
00:01:25.890
Viktor, can you picture this? It's 3:00 AM. Your phone doesn't ring. In the morning, you wake up to a clean incident report. The system fixed itself, and there's a Slack message saying, "Hey, agent resolved the problem at 3:15."
Viktor
00:01:42.037
Oh, if you remove the incident report, from that story, then you're… I'm picturing my retirement
Darin
00:01:47.874
Don't you wish you could retire today, since I'm already retired? Would you trust it?
Viktor
00:01:53.071
Not initially, but I feel that that's the same as with people, right? I don't trust anything or anybody initially, and that includes the tools, the platforms, the services, whatever, right? trust is earned over time. But let's say that if you ask me would I trust it few months later and it didn't mess it up, then the answer is yes
Darin
00:02:29.807
here's the question. What's the difference between that, that we've been doing for years, and what everybody is pitching now? what makes a big difference? Because, we had self-healing back in the Tivoli days. For anybody that's not familiar with Tivoli, it's a really old thing
Birol
00:02:46.195
true. I, think difference is, the capabilities in, diagnosis. Those have changed. and applying the self-healing, I think, yes, I would agree that it's probably-- if you know what the underlying problem is, then that's something you could, you could have automate, right? And that's not the part where, that's, like, fundamentally different. I think what's fundamentally different is being able to, automatically diagnose the root cause and then knowing, like, what fix to apply
Viktor
00:03:15.902
I feel that the difference, Darin, that back to your statement is that self-healing we had or have still is based on predefined patterns, If you take Kubernetes kind of, oh, pod crashes, what do I do? What's self-healing? I bring it back up, what goes after the predefined pattern? So let's call it automation, right? You could have a script or a cron job that does the same. is then if predefined patterns do not match, then we evolve I'm going to call it today intelligence, which is, carbon, and now we are talking probably about silicon intelligence, but hey, something happened that is not in a list of predefined patterns that we figured out how to solve. is that close?
Darin
00:04:13.793
That seems too easy. You have a whole company around this. It's like, How does it even make a difference? Again, I'm, I'm still trying to get my head. I mean, I, I think back. Fortunately, Tivoli was right on the edge for me, but I'm thinking back to, I guess I am old, but I'm not that old. Well, actually I am. The problem with, What was the one? Elastic Beanstalk. Like, to me, Elastic Beanstalk was magic when it first came out in 2009, because I could just say, "Here. Here it is," and it takes care of everything for me. what is the big difference now? We also had this thing called AIOps a couple years ago. How is that different from what we're doing with AI SRE now? is it just yet another thing, a rebrand?
Birol
00:04:53.199
Elastic Beanstalk, that tells me something. It's not the autoscaling feature from Amazon, right? Is that Elastic Beans- Beanstalk?
Darin
00:04:59.043
It's not autoscaling, but it's… It was the, "Here's my app, go run it," and it would take care of all the autoscaling. If something went sick, it would go ahead and replace it. Yeah.
Birol
00:05:08.173
and didn't work out right. So I think that's a service that doesn't exist anymore.
Birol
00:05:25.448
We've never used it. I think in the beginning like I was personally looking at it, when we were setting up the infra for Alert, and I think we didn't have, the Kubernetes tool, back then. fair question. So what's the difference to, AIOps? first of all, it's like my assessment of AIOps and what we've been promised is, probably that never materialized, like that never didn't happen in the way it was promised. And AIOps is a, basically tells you that, "Okay, hey, we're gonna reduce like alert fatigue. We're gonna help you, build proactive systems, and learn from your data." but to answer your questions, what's the difference? The way I see it is, uh, like AIOps was mainly built on the foundation that you're training models based on your data, you can put it in the traditional machine learning, way of doing AI, right? Where you train models based on like maybe your data. with, the current approach, we're not training any model. were using foundational models from the Frontier Labs, we think those foundational models, they have, to a certain extent, human intuition codified when it comes to doing root cause analysis. And we have built an agent that, uses these foundational models. we've built a harness where we can leverage, these LLMs and, they are more effective about reasoning about a specific problem when you provide them with enough context. And those, the context would be the same things that, any SRE would do, right? Uh, so you look at telemetry data, you look at changes, look at the health of your, you know, maybe cloud infrastructure. the difference is, again, there are no pre-trained machine learning models involved. You have these large language models, used in a, highly contextualized manner, they run the investigation loop, and they present you with an, with a root cause analysis. And I would fully with, Viktor's initial, skepticism regarding, okay, would I let it run like that? I'm not getting paged at 3:00 a.m. in the morning at all. Instead, I'll have the agent diagnose, fix and verify the fix and not depend, on a human be paged. of Of course, I wouldn't start with that, and I'm, that's not something I'm seeing as of today consistently, and I wouldn't even recommend it, that you run an agent that works exactly like that, fully autonomous, only pages you by exception. but I think that's where we're heading, that humans will only be paged for novel incidents when an agent gets stuck
Viktor
00:07:58.063
You mentioned analyzes the incident and then additional steps. does it go before that Because when you tell me analyzes the incident, that means that something or somebody already discovered there is an incident, right? and usually we do that through predefined patterns. Oh, I know that it should be an incident if memory is over whatever, right? But does it do the first step or really do the first step kind of like, "Hey, I'm just monitoring the system and I'm going to let you know when there is a problem to begin with"?
Birol
00:08:29.455
think like in our case, there are a few ways to trigger, the automatic investigation by an agent. And in our case, it's, when a monitoring tool, when system before detects that, there is an anomaly and something is not working. for us, that's the case because, we are at its core an incident response management platform. So what we've started with is, waking people up in the middle of the night telling them, "Hey," that, "Hey, there is an, incident that we received from, Grafana, from Datadog." and, we would page people to reduce MTTA in the middle of the night, right? that's where, where we sit in between. We sit in between those, observability systems and the people who are, on call and, are responsible of receiving and fixing, these issues. that would be one possible trigger where, our investigation kicks in. That means we receive an alert from any of those 150 plus integrations that, we already have. But instead of paging the person right away, we run an investigation. Or right now, the way you would use it is you would have both in parallel, right? You would have an investigation if certain criteria, are met, and then in parallel, you would page the on-call person, and by the time that person is, looking at the alert, it doesn't look at a blank alert. It sees a complete investigation with recommended actions. So the human is still in the loop, right? and there is a path to autonomy, and it comes with what you said in the beginning, Viktor, which is, trust
Viktor
00:09:56.442
The slight issue I have with that is that, if I define alerts in advance, whatever the, the alerts are, that means that I know what the problem might be, very often, not always, if I know what the problem might be, I know what the solution should be, And then I don't need AI at all, meaning that, oh, when the-- when this happens, I restart this service, Because I know that happened before, I know what the solution is. I'm not saying always, but very often, right? so I'm kind of… That, that's why I asked the previous question because I feel that there is an opportunity to start solving unknowns with AI, not only can, "Oh, I know that this is happening, and I'm just too lazy to write a script that will fix it, so let the person, AI, something else fix it in
Birol
00:10:47.679
Yes, and I think that's a legitimate use case. So, I talk to people who have set up their own agent, using OpenClaw, and what they do is, they have OpenClaw check the health of the entire system once in an hour. And that person was saying, "Okay, I'm not on call anymore. my agent is on call now," right? so the point at which you can, leverage those capabilities, I think the triggering that totally makes sense. It's just something that we're not fully focused on right now. regarding the alerts, when you have an alert, you know what the solution is beforehand. I'm not sure about that. Like, even if you know that, okay, if I restart the service, it will probably fix it. there are still a lot of companies who still have people then who get paged, and then they do exactly that, right? restart the service or the most frequent root cause for incidents is, change, right? When you're a company and doing frequent changes, frequent deployments, what the actual fix is always doing a rollback, right? Because you deployed something and you broke it. those changes, they will manifest itself. And like it depends on like what exactly you're alerting, which metrics you're looking at. but they will break something and, it can be customers complaining. It can be your, I don't know, your, your database queries, taking longer than expected, which then will trigger alerts. It can be, error rate increases. For example, if you have an increase in 500 errors in your API, actually not sure like h- how you would be, able to automatically mitigate that. Like let's say you have a metric and looking at, latency and errors
Viktor
00:12:14.713
Oh yeah, definitely not all the time, right? Um, just I feel that there are still people whose job is to restart the service. I'm ridiculizing a bit now, but,
Viktor
00:12:25.201
what do you take into the account? W- what is the data that AI gets? Is it, only metrics, traces, logs, Because you mentioned, uh, earlier, new release. Does, does it have access to the code and can, uh, analyze, "Okay, so actually, why don't you change this line of code over there and make a new release?"
Birol
00:12:47.317
absolutely. that's ac-actually where, most of the value in building an agent, lies, right? Providing the right context to an agent so it can make its decision about the root cause analysis. It can synthesize a hypothesis and like the more relevant context there is, the better the diagnosis and the decisions of the agents will be. since already sit on top of observability, monitoring, and ticketing tools and already receive wh-when something is not working. Either it's support requests going high telemetry data triggering alerts. we let users give access to their CI/CD pipeline, to their software code, so then the agent can make its decision whether, okay, I'm seeing these symptoms and I'm seeing like out of these, 100 deployments that were made in the last, seven days, I've looked at these and for those five out of 100 deployments, I even checked the changes at a source code level. And then it can tell you exactly that. If you change this line or here I'm seeing a potential bug that is the reason why we're seeing these symptoms in your telemetry data.
Viktor
00:13:52.367
So i-in the story that Darin gave at the very beginning, 3:00 AM story, do I wake up with contextual analysis and solution? I don't know, an email or Slack or whatever it is, or do I wake up with a PR, and my job is to review and merge
Birol
00:14:15.174
If we look at the end goal where we think this is going is you don't get paged at 3:00 a.m., right? Instead you receive a report via email, via Slack with a potentially a PR telling you, "I've mitigated the incident, but only so far that it stopped the bleeding. It doesn't have business impact, but here is a PR for a long-term fix." And it could be something like that you just mentioned, right? I restarted the service and I was able to verify for, 60 minutes that it fixed the incident, and then I assume, okay, this is effective. Or I saw a different memory consumption pattern and I doubled the memory of, one pod and this will probably buy us another 18 hours. And here's a pull request that fixes the memory leak that was caused by the deployment three days ago. this is to complete the picture. This is the I think the end. N- not the end, but this is really where we think it's going. And I think we'll probably also see the same level of maturity that we reach with coding agents. If we talked six months ago about coding agents, we would probably have similar discussion, right? Do you really think that agents are going to write 90% of the code? So how is that possible and how will they do it? And with AI, with agents in production, it's different task. You have a a lot more data to deal with that you need to, process in a very short amount of time. And of course, it's something that you're more careful about. That's why it'll take some time. But yeah, I think it's hard to predict with AI, but I think by the end of this year we'll probably have these agents in production in, mainstream usage.
Viktor
00:15:43.931
I imagine that when we talk about data that AI needs, we are probably talking about three types, like operational data, metrics, logs, access to the cluster, what so not. There is source code, and then there is company knowledge, right? Wiki pages, documentations, et cetera, et cetera, et cetera. The, all the things that we're supposed to read when we join a company, we never do, but eventually it becomes a tribal knowledge. And I feel that's the blind spot that no company I've worked with actually has the knowledge of how they operate organized in a useful way, no matter whether it's a human or AI or anything else, right? Do you deal with those? And if you do, how do you deal? Like how do you teach AI how a company operates?
Birol
00:16:38.591
first of all, let's, look at the statement. So you're saying for an agent to operate effectively, it needs access to telemetry, to source codes, to, your infra in general, and then company knowledge. And I would argue that I think company knowledge is nice to have, and we know from our experience that the best documentation when it comes to operations and to software is the code itself, Because anything else gets outdated re-really quickly. And that's why we're not trying to rely on any documentation any kind of knowledge, like runbooks. In fact we don't even look at runbooks right now. we have no integration runbooks. But I think, once you get the basics right, once the agent is able to operate very effectively just with telemetry data. telemetry data goes even beyond okay, an incident has happened, now I check the telemetry data. It even starts before, I would say. Like for example, our agent, we have s-some sort of, I wouldn't call it pre-training, but call it like discovery. Our agents, they run discovery phases where based on live data and mainly we're talking about tracing data, it builds a service topology, So it has an understanding of your infrastructure on a macro and micro level just by consuming tracing data. And again, this doesn't rely on some, manually updated topology documentation. It is built from live data. Then you have the changes, then you have source code, which is if you know the, which branch is deployed of course you have the most up-to-date information. r-right now we're fully focused on that, and I think trying to build in company knowledge, it will become useful want to squeeze out more performance from the agent. a general premise, I wouldn't require that to be in place.
Viktor
00:18:32.292
The reason why I'm asking that is because I feel that there are some things that are discoverable, no matter whether we're talking about agents or humans, and some things that are not. If I point you to my Kubernetes cluster and that cluster happens to s- be synchronized with Argo CD you go to that cluster you analyze what's in that cluster, you find Argo CD applications, you know that you can follow the breadcrumbs, find the repository, and give me the PR that I mentioned earlier, right? But then if that something is managed, let's say, with CloudFormation or Terraform or something like that, th- there is no clear connection between what I'm looking at and how that something came into being, then the only option you have is to pass through gazillion of repos hoping that one of them will give you the clue that, oh, so is this Ansible something, That's what I'm supposed to give you as a solution to update so I'm just wondering how does AI d- come up with, "Oh, it's Ansible"? I know how it comes up with, "Hey, it's Argo CD," because the evidence is in the system, but not how, "Hey, this is Ansible
Birol
00:19:49.626
you mentioned these gazillions of, I'm not sure if you said queries but th-this reminds me of y- yeah, re-repos. Yeah, exactly. reminds me that if you look at like how an agent operates, like without that knowledge and we audit every single tool call input outputs that an agent does, right? If you look at how it operates you get the feeling that, okay, it's highly inefficient. it is true. It is making so many unnecessary queries because it doesn't have maybe some of that tribal knowledge that's you mentioned. Or the report, the alert, or the symptoms that you told the agent, they are like broadly generic. it makes a huge difference in its time it takes to find a root cause analysis. Y-yes, I think maybe to update my statements, like providing knowledge is like super useful, but I wouldn't make it the main center of the agent's capabilities. the way w-we're trying to build this, where you have some sort of a like long-term memory that we extract just from conversations and maybe also from documents that you can point at it. But it's, like I said it's not something that our agent's capability relies on that knowledge and then where we're paying a lot of attention to At the moment, at least
Darin
00:20:58.165
What happens when… Because I'm assuming iAlert is a charge plus usage for model interactions. Is it?
Darin
00:21:11.345
If-- it's… It is. Okay, great. Because then now I'm gonna say, all right, I'm running along, and then all of a sudden… And I've been paying, let's say, $100 a month, And then I have a really bad month. I have a lot of incidents, and that sort of boilerplate $100 a month, which I've been able to handle now goes to 100,000 for the month, And then now I'm out of business. What kind of guardrails do we have in place that we could put in place on my side, ignoring the iAlert side? What kind of guardrails could I put in place? Because it's one thing to, h-have a 10% bump, but again, mine was silly going from 100 to 100,000, but it could happen, right? I, okay, let's say it's normal. Let's g- I j- I just go from $100 a month to 10,000 one month. That's still a big chunk of something I hadn't planned for
Birol
00:22:00.233
Yeah. Absolutely. I mean, our case, it wouldn't happen. And we have experience with usage-based, not pricing because like pre-AI, all our usage was seat-based, right? But we still had components where based on the consumption, for example we make phone calls, we send SMSs, right? And We offer our customers unlimited notifications, including phone calls and SMS, and while our provider charges us for every single SMS and phone call that we make. But we still have guardrails in place that would prevent literally sending one phone call per second per device, right? So that wouldn't happen in our case. Now, your question is what if the burden is on the customer side because our customers are paying for AI credits the way we have handled this is right now we show you what your baseline credits are, and then you can decide, okay, what do I do if I exceed those credits? And since we're already good at getting human attention into problems you can just decide, okay, if I exceed my credits, I want a human in the loop, so I want my engineer on call to be paged because then I know, okay, I have an issue that where I might expect that my agent will take care of it, but it cannot because I ran out of my predefined budget limit.
Darin
00:23:20.337
So you're doing token management, which leads me actually to my next question, levels of trust. We talked about trust earlier to where agent suggests moving to agent acts with approval, human in the loop, to agent acts autonomously. What is the thing that sets us back to the agent suggests? What kind of fire has happened? Let's say we got-- we made it to either two or level three, and now we go back to level one. What kind of things made us go I still wanna use the agent for suggestions, but that's it"?
Birol
00:23:54.088
First of all, if you made it to level three, congratulations. And to be clear, we have no customer right now that uses our agents fully autonomously in production. Like all our customers are using the agents in observe-only mode exactly because of product is not GA yet, so we- we're working with selected customers to build these capabilities. And think to answer your question if something goes wrong and, trust is very binary, right? It, if even if it works three, four, five times and then the agent messes up, then, you lose trust and then you just s- strip all the write capabilities of the agent. But there is still a lot of benefits, like even if the agent is observe only if you think about it most of the time that you spend when you are fighting an incident is the root cause analysis part. Once you found the needle in the haystack, applying the actual fix is usually fast if you have, the appropriate knowledge. So having an agent just in observe only is totally legitimate and already provides a tremendous value because you're able to reduce time to RCA from maybe, depending on the incident, 20 to, 45 minutes down to a few minutes
Darin
00:25:06.882
That would be good if we can get it down. But I was listening to your whole setup of, if the AI agent really messes up, we can just strip it. I could replace agent with human, but would I fire the human because they made a mistake? Are we being too quick to fire… Okay. Are we being too quick to fire the AI agent, though? Just because the human messed up, we're not gonna fire them. Y- it could if it was really bad. But it's the same issue to me Again, that takes me back to trust. What do we do? if I'm paying money for this, just like I'm paying a salary to a human, I expect a certain level of failure rate and success rate
Birol
00:25:51.904
And also a certain like behavior when it comes to learning from failures, right? You don't wanna see a failure happen twice
Darin
00:26:00.032
Is that the part to where the machines and humans, that's the dividing fork? Is as humans, we are able to do that after action review amongst ourselves to come up with what we're going to do, runbook or runbook-ish, whereas an AI agent isn't going to do that unless we are having a, oh dear, after action review with our agent
Viktor
00:26:25.458
let me put myself there. Aren't we already doing that, Darin? I fired Cursor in favor of
Viktor
00:26:33.098
Claude? Code. I fired Gemini in f- in favor of GPT 5.5 and so on and so forth, right? If anything, actually, I've been firing Silicon intelligence much more frequently than human
Darin
00:26:53.039
Try that with a human, at least in the US and probably in Europe. We can't do that, right? I- is… Are you saying it's just easier to do it now?
Darin
00:27:04.257
There's no warm and fuzzies we have to do with? It's "Oh, we just stop paying your bill," and off we go?
Viktor
00:27:08.768
easier to fire or replace, let's say. I mean, You never fire a human without replacement either, unless the, you're doing cutting, right? You find a better engineer and then you fire, assuming that you're doing it the right way. And just easier for me to, "Hey, when a better model than Opus comes, Opus is out. Out."
Darin
00:27:31.934
Actually, triggered a question, so I, think I might be able to get it back on the rails. Let's say you've done the discovery up front, You woke up the agent, it's doing discovery, it gets everything. And then, as Viktor just said, we're cutting a whole segment of the business. Gone. But yet the agent, I'm assuming, still has all of that discovery from the initial pass. Is it auto-updating the auto-discovery over time? Or what happens? Because to me, things are changing all the time
Birol
00:28:06.433
Y-yes, that's actually the what I was trying to say, that it's better than relying on documented knowledge is having some sort of auto discovery of knowledge, which the most up-to-date knowledge is, telemetry data, is source code. And that's of course so our agent, it runs in discovery mode all the time. when it, for example, when it was, silent for two days and then it kicks off after two days and it discovers, okay the last time I've I ran discovery I updated the topology was two days ago. Let me check that again, right? And just consume tracing data and update my topology. And you can, I think th- there are no limits in how deep that not only topology, but how deep that model that you're building, like n- not model in the sense of a large language model, but that model that captures how your system behaves. It could be, I don't know, a Markdown document. It could be a JSON document. It could be a service topology. Because there is a lot of information captured in that data, in telemetry data in, in source code already
Darin
00:29:05.894
So if we're capturing all of that live, which is wonderful, shouldn't the agent be publishing it as something humans should know? Because magic hand wave, because this never happens in real life. We use Terraform or fill in the blank any other IaC tool to stand up everything, and then we still have access via the console, and people are pointing and clicking and adding things. So Terraform is not source of truth. The console is obviously source of truth, but we forgot about what's going on. Shouldn't the agent tell us, "Hey, you've got drift happening here. You might wanna check it"? But that takes us back to what we were saying earlier. That's a company rule. The company rule is everything goes through Terraform. But if we didn't tell you, the agent, that the rule is everything must go through Terraform, there must be zero drift, how would you know that Terraform, everything must go through Terraform, right? I'm getting to a circular Here.
Darin
00:30:07.272
Yeah. So I have to tell the agent, I have to give the agent some company rules, going back to Viktor's earlier comments
Birol
00:30:13.520
Yes. Yes. I think eventually I agree with Viktor and said, "Okay, there is usefulness in, in company knowledge
Darin
00:30:20.440
Probably not as much as he was thinking though. There's certain things I think that have to be there from day one though, because
Birol
00:30:27.684
The main reason why I was pushing back is when people talk about knowledge, the first things that they have in mind is, oh we have a Confluence wiki, we have a Notion wiki, we should probably feed that all into the agent. We have hundreds of runbooks, we should feed that into the agent, right? that approach causes more damage than it produces results
Viktor
00:30:49.728
that's where actually I was going previously with my question is some knowledge is required, but I'm fully aware that company documentation is Darin bleeped uh, g-garbage. Okay, I was, I was looking for a word that you would not bleep afterwards. It's garbage. And I feel that's a real problem, like code is not garbage. Code is what it is. Telemetry is not garbage. Telemetry is what it is. Company knowledge is garbage, and without it, I might get far, but not to the final destination, And in my head that, the question I, I don't have answer yet,
Darin
00:31:27.607
And my answer to that was the agent after its discovery publishes it all, and that is truth. That is the wiki then. And it's… And the humans are read-only on the wiki instead of the agent being read-only on, on the wiki.
Birol
00:31:39.073
Yeah, but we're actually trying something similar right now with our user-facing documentation. We haven't applied it broadly yet, but what we have now, and I think like probably many companies are doing this now we're updating the documentation with every release, with every PR that is being merged. And then you have an agent, checking that both documentation and the actual source code is in sync. And yeah, to come back to Darin's point you could apply the same principle to, okay, now that the agent is consuming this raw data, not let it publish some of that information to humans, right? And keep it up to date all the time. Yeah. That would be useful. ' Darin: Cause no human likes writing p- documentation that I know of. There are some, I will say, but, to keep it up, especially on a release-by-release basis would be insane Yes
Darin
00:32:29.191
I think some people could argue that this is just moving the failure mode, Having AI SRE there is just m-moving failure. So let's say we-- there were 30 tools called in the chain to figure out what was going on. One of those tools could fail silently. Curl's having a bad day for whatever reason, it happens. You could have retry loops without circuit breakers, so you get stuck. Or as what happened to me the other day, remediation against the wrong system, right? You think everything, this, "Hey, man, this is all burning down." Yeah, it's my dev system. I don't care. Because somewhere along the line, the pointer got lost. our solution for that? How do we deal with that?
Birol
00:33:14.799
there are a few aspects in your question. First is what do I do when some of the tool calls failed and when some systems are overloaded? And this is actually a legitimate problem because API traffic is increasing across the board, right? Because agents are now, using tools via the API. And especially for AI SRE agents, they're heavily relying on telemetry data, so they're sending a lot of queries to systems like Datadog like Grafana and other ops observability solutions. and sometimes you self-host them, sometimes you pay per consumption base, and you are worried that they might not fail. I think the answer to that is having a harness that can deal with failure. Just like you would design any good software with things like you mentioned, like a circuit breaker, you should have an agent harness that is able to deal with when one of the tool calls takes too long, doesn't respond render any meaningful insights, right? So there's no point in trying to get some useful insights after, I don't know, 50, 60 tool calls, huh? I think that the solution to that is having a harness that can deal with all these problems and can essentially make the best out of what's available. Then the second aspect of your question is accuracy, The agent can still make mistakes. The agent can still, I don't want to say hallucinate because that-- I think that's not in highly contextualized environments we don't see a lot of hallucinations in the sense that "Hey I'm seeing these symptoms." And usually somewhere in my knowledge, it says, "Okay, if I'm seeing these symptoms, then it's, it must be this root cause," right? That's not the case. The problem we're seeing is that the hypothesis that the agent makes, even with all its like reasoning steps outlined, sometimes it's just plain wrong. we started like trying to mitigate this by introducing a confidence level. Like we-- initially it was a score, then we made it discrete. So whenever the agent tells you, "Okay, this incident I have synthesized this this hypothesis, and I've verified it. This is the root cause." And then you see a, like a confidence level, whether the agent has high confidence, low confidence or medium confidence. And all the key findings we we link them with evidence, right? When the agent says, "I'm, like, I'm I think the deployment with release 13.2 introduced a a-an out of memory", then it would link to evidences. It would link the deployment that it's referring to, and it would link the log line that produced this, maybe this out of memory error, right? And this goes with all its key findings. So usually it has sometimes, five to six key findings and also a few things that it's ruling out. So you can f-fairly assess whether this makes sense or not, right? And hopefully quickly throw it away if the agent simply went into a wrong direction, whi-which can happen, right? You have s-symptoms that are expressed in an ambiguous way. And for example, We we have a status page product which is a customer-facing product, and that status page includes metrics. And we actually had a real incident. We had a real incident where those metrics they became stale. And when you go to an agent and tell it, tell the agent just "Metrics are not working anymore. We receive complaints that customers are telling us that metrics do not work or have become stale," then like without any, existing knowledge there is a chance that the agent might think, "Okay, are we talking about internal metrics? Should I check whether the, my, my Prometheus instance, whether all the metrics endpoint are healthy, whether something is wrong there?" And usually I make demos where the agent is still a-able to catch it despite that ambiguity. But yeah the bigger the search space the harder the problem gets. And when you have no starting point, then it can take longer and sometimes the agent gets stuck, and it's not very good at reversing all its previous steps and unstucking itself, basically. And then it's still able to draw a line between, "Okay, this is what I'm seeing, and this is what the root cause is," and it still can be plainly wrong So to answer a kind of a final answer, I have no-- that we have no solution to to always make sure that it's produces an accurate result. But the way we try to mitigate it and make human, make it easy for humans to assess whether it's wrong is by having this confidence label and key findings that are linked to evidence. So you can, as a human, you can able to s- to say you're able to say that this doesn't make sense, and I'll just do the request analysis myself, or I'll ask follow-up questions and, try to direct the agent in the right path
Darin
00:37:45.234
Who's accountable when the agent just makes it worse? You touched on it there because you're talking about hallucinating, not hallucinating, not using that word too strong. But we've got another system that we put in place to help us with the alert fatigue that was supposed to be silver bullet, right? The salespeople are really good. They don't say it that way, but it comes across to the C-levels that are buying. But now we've got it in. We are going to level one trust, just suggests, but even the suggests are incorrect based on how discovery went because our network and infrastructure is so screwed up, right? It's not the AI SRE's fault. It's our own problem. How can we make sure? So therefore, even that the SRE gives us, AI SRE gives us, is going to be incorrect based on what we thought everything was set up. Am I asking that in a very circular way? I think I am. Because whose head is going to be on the chopping block, right? Because somebody has to be, because we can say blameless postmortems, but come on, let's get real. The C-levels are not, they're always going to blame somebody. Sorry, since you're a C-level, but it's
Birol
00:39:10.460
I think you are already included the answer, or at least some of it. It can't be… Like, it needs to be human, right? It cannot be an agent that is accountable. Just like when you work with coding agents, even if I miss we I'm relying heavily on coding agents and the code is garbage. It doesn't mean that I'm not accountable because, hey I use Claude, the latest model and it must be Anthropic's fault, right? That's that's not the case. I think at the end it needs to be… Like we need accountable humans and agents are tools, right? And they can work well, and they cannot work well. Yeah. I'm not sure if that answers your question. But yeah, I would say like humans are accountable at the end. Now you can ask, okay, if you're selling this, is it the vendor's fault or is it the user's fault, right? That's also something you could ask as a follow-up question. Because I'm selling you fully autonomous agents, but now I'm trying to use it, but it's screwed up, right?
Darin
00:40:03.580
Wait, that leads me to the next question is, are you guys using your agent within your own infrastructure
Birol
00:40:15.220
W- we've moved from level one to level three to our staging environments, certainly. So that's I think that's s-something where everyone is comfortable doing that. But at the same time, there's a lot of noise i-in a staging environment, right? So it's it's not r-r-- at least in our staging environment, we just have one environment like one non-production environment. There, there is a lot of noise. But no, w-we haven't moved to level three. And there are even more there is something in between because level one is observe only, level two is human in the loop, level three is agent has approval for a class of actions where that-- where it has high confidence. And then level four is a-agent is in in, in YOLO mode can do everything, right? Yeah, so the idea is that for novel things you will-- you probably operate with level three and then you will-- you still wanna page an huma- a human by exception rather than the standard. But no we don't do that our-ourself, but we heavily rely on our own like usage of the agents because, yeah we're also operating a fairly large infrastructure with, components deployed across two, two, two, two regions and with lots of services involved. So I think we we are a good example where an agent has a fairly, large search space, and we can draw a lot of learnings from our own use cases. But of course, not everything that we still need to learn from customers and s-see how this how these capabilities work in environments that are not in our control.
Darin
00:41:47.880
So you say staging is noisy. I could argue that production is a lot more noisy than staging
Birol
00:41:53.216
True. True. The-- W-with respect to traffic and telemetry that is true. What I was referring to, I was referring to, deployment, someone breaking a service where in, in production it's much more there's much more order, I would say. Yeah.
Viktor
00:42:07.536
Is there some kind of feedback loop back to AI? Like positive, negative reinforcement? You did a g- did a good job, did a good job. This is bad type of situation after, s- something that would result eventually in five times good, just go. YOLO on this one
Birol
00:42:30.448
right now there is a feedback loop for our internal purposes, for our internal evaluation. But there is nothing that would teach the agent and take that feedback into account in a future iteration of an of a root cause investigation. But it's also something that probably makes sense, right? To to incorporate human feedback so the agent can learn from that. But this, again, is a question of how do you manage memory? Because feedback is nothing different than just memory and where the agent knows, "Okay, the next time I'll try to take that into account, that piece of knowledge."
Viktor
00:43:04.345
question I'm asking that is basically the mode three, if I got it correctly where you are partly autonomous, partly not, depending on the use cases, right? And I have a difficulty imagining the world in which actually I give detailed instructions of everything that some- somebody or something can do autonomously and what cannot be done because, every use case ends up being s- at least slightly different than the previous one, right? So I'm just wondering they get to mode three in a way. How do I decide this is okay for you to do alone and this is not okay, right? Wi- without spending eternity in defining that something, right?
Birol
00:43:48.852
Yeah, I think the entire point of autonomy is that you don't have to think in advance of every possible outcome and then, somehow provide proper instructions. when I was making the distinction between like level three and level four, I was referring to we as humans are not comfortable giving agents more power, we can maybe approve class of action such as maybe for us it's a no-brainer restart a service or to give a little bit more memory, maybe to double the memory or something like that for any given pod. Because we know we have enough room in the cluster or maybe do a rollback. Yes, so how we envision these class of pre-approved actions. And yeah, and if it's fully autonomous, then you would have to trust that the agent will figure it out. And if the agent is capable, and that's a very important part which we haven't talked about and also haven't emphasized is verification. If the agent is able to verify what it's doing, then you can always have, the option to page a human by exception, right? And you probably have experienced this with coding agents. When you let the agent verify its own work, then it's, able to come up with a satisfying solution much faster versus then the agent does something, you check the work, provide feedback, then the agent, incorporates that feedback. Yeah, and I think that's similar to RCA as When the agent has enough capabilities to understand that, okay, now the symptoms that were previously reported are not in place anymore and verification is successful, then key path in making sure that we have no, investigations and fixes that are not effective in the first place and an incident goes unnoticed entirely,
Viktor
00:45:37.676
I feel that in case of infrastructure, there is that discrepancy when compared with code because I can actually validate code is relatively easily without showing it to anybody or affecting anybody between And I feel that not many companies have production mirrors, let's call it like that, right? Where I can play around oh, this happens in production. I go to the production mirror of production in a way. I apply the fix, I validate it, it's all good. can go back to production, right? that seems to be more complicated or if not undoable because I personally, let me put disclaimer right away, I don't trust staging environments that are not really production-like for you to vali-validate anything
Birol
00:46:26.925
I would agree 100%. I was talking about verification I wasn't referring to some, some mirror of production where you validate something is working. But let's say you have an alert that is based on some metric going rogue, right? And then you have an agent deploying a fix and then observing that metric. If it goes down, then that's a verification or if the agent is triggered by an alert from an observability solution, from telemetry data and then agent applies a fix then waits for the resolution event coming from that system. That could be also a form of verification. if the underlying problem is I don't know, an uptime monitor telling that your API, your website, your app is not available just, by doing pings then again, the agent can also do that on its own. It can just verify, "Okay, no, I can log into the app again." This would be a catastrophic failure that the entire app is not available. But the verification will probably, differ based on just like we would do these verification. And even for us as humans, there is no recipe for root cause analysis, right? there are no steps that you can execute that will lead to guaranteed success. There's, it relies on tribal knowledge. It relies on, looking, searching looking at telemetry data and then looking at changes. And then the fix, what's the fix after an hour of, spending with, in a war room with 10 people? It's a rollback, right? Most of the time it's a rollback. It's not a massive change. It's more the search for the, underlying root cause which takes time.
Viktor
00:47:57.293
Where I was going with that is I feel that vast majority of companies are way behind at the tip of the industry, right? And what you're saying, I would completely a- agree with you if that hypothetical company is, for example, and I'm using one of many examples, is doing canary deployments for everything, right? And they have a real good system to validate whether actually, okay I'm rolling out 5%, I can validate, I can go through metrics, everything you just said, right? Without really screwing up with everybody. But the reality is that your customers might be running mainframe, right? Your hypothetical customers. Sorry. No, not real ones. I know that none of them are behind, right? So
Viktor
00:48:49.232
there we go. There we go, right? Uh, I, I wonder whether this will be the… We will soon reach the point where actually companies will realize that I cannot be that behind anymore if I want to leverage this fully. And when I say behind, I don't mean in AI adoption. What I'm trying to say is that AI adoption, success of AI adoption in any form of AI is actually very much related with where you are technologically
Birol
00:49:22.085
I actually thought about the same when you were, in the beginning when you were saying that why do we need these agents? We had, we have auto-healing, we have runbooks, we have this. And I think that also applies to mature companies that have these automations in place, that they think about every possible scenario, and then they have, auto-healing, they have these runbooks that can be automatically executed for each alerts, where each alerts was, properly thought out in the first place, and then a solution i-i-i-is in place that can be executed automatically. And that's also something that I think about a lot what's the level of maturity we require for a company to actually benefit AI. And I would agree that, yes probably it, it doesn't hurt if if you have a certain level of maturity to to benefit from it, then you probably will be left behind if everything is legacy or if you even maybe don't use AI in the first place for whatever reasons. one way how we try to mitigate this is, for example, let's take tracing as an example, right? Tracing sounds really cool. The data is super valuable. We can have an agent that learns automatically builds a topology from your system and understands the underlying architecture just from tracing data. But how many companies do you personally know that have instrumented their code with tracing data?
Viktor
00:50:39.174
Not many. Where I'm really going with this is, of course, we all, I'm also in the vendor space and so on and so forth, right? We all want to give our latest and greatest to our customers, but there comes a moment we don't say out loud that says, okay, you cannot skip these historical steps. move to Kubernetes first, right? Like move to containers first, move to canary deployments first. You can use what I'm giving you, but it's not going to be the thing. It's not-- it's going to be a thing. You're going to benefit and so on and so forth, but the benefits are negligible compared to how big benefits could be if you would live in present tense, not in 1999
Birol
00:51:24.130
Yeah. True. at the same time, we have to, accept the realities companies live in. And coming back to the tracing example, kind of mitigate this, we have built a gateway data where you can just throw in an eBPF-based collector, for example, in your Kubernetes cluster. And then with no instrumentation, we already have lots of tracing data, right? So that's one part where we try to accept the realities of our customer base and understand that, okay, not everybody is on the edge of, what's possible right now. then also benefits even don't have the full set of, possibilities when it comes to, the right context. It even gets harder when you, for example, have managed service providers. A managed service provider, they do root cause analysis completely different a tech company managing its own infrastructure. A managed service provider has, what does it have? It has tickets from customers. Sometimes it has access customer systems, but probably it's not so easy where it can just throw in an agent, our agent, and then our agent will, analyze the system of our customer's customer, So that's why we're, trying to build a purpose-built generalized agent that can work in multiple environments. at the same time, we have to accept the fact that if you haven't done any of your homeworks in the last, 15 to 20 years, probably now it's not the right time. There are different things that you should do first before adopting AI in prod. customers, they even don't have any kind of observability, right? And then they see all the marketing and all the, the promises around AI, and some of them have the expectation, okay, maybe we can just skip the observability part and then we have your agent, right? that doesn't work right, yeah. At least now.
Darin
00:53:17.886
So if you want to learn more about iLERT, you can find it at ilert.com. That's I-L-E-R-T.com. All of Beryl's information will be down in the episode description. Beryl, thanks for being with us today.