**Tom Wilkie:** \[00:00\] Hello, I'm Tom Wilkie, and welcome to Grafana's Big Tent, the podcast all about the people, community, tools, and tech around observability. I'm here with Manoj Acharya, who is our VP of Engineering for Observability at Grafana Labs. Cyril Tovena, who is our Principal Engineer on the Grafana Assistant team, and Spiros Xanthos, founder and CEO of Resolve AI. Thank you all of you for joining. Hey, Spiros, how's things over in California?

**Spiros Xanthos:** It's great weather, it's nice, but you know, too much work. I don't know if you know this is my first startup. I never worked this hard before.

**Tom Wilkie:** Yeah, no, thank you for coming. I didn't realize this was your first startup. I thought there was one pre-Splunk.

**Spiros Xanthos:** Fourth startup.

**Tom Wilkie:** Oh, fourth startup, yeah, that makes more sense, yeah. Well, thanks for inviting me. Big fan of your work and the podcast.

**Spiros Xanthos:** No, thank you. We're big fans as well. So, you're welcome.

**Tom Wilkie:** And Manoj, you're also in California somewhere, aren't you?

**Manoj Acharya:** I am. I'm not too far from Spiros. I live in East Bay, which is about 30 miles east of where Spiros is.

**Tom Wilkie:** But you work from home, so?

**Manoj Acharya:** Yeah, thanks to Grafana. And even better weather than in San Francisco.

**Tom Wilkie:** Oh, is it? Oh, nice. East Bay is nice. Very cool. Yeah, and I guess you don't have the morning commute problems. I'm currently in South Africa on a little holiday with my wife, and it's like, I don't know what it is in Freedom Units, but it's like 25 degrees outside. It's absolutely beautiful, bright blue sky. It's lovely. Cyril, lastly, but by no means least, you're in the south of France somewhere, right?

**Cyril Tovena:** Yeah, I'm trying to stay close to where the wine is the best.

**Tom Wilkie:** Ah, yeah. And the wine in South Africa is quite nice.

**Cyril Tovena:** Yeah, I wasn't talking about South Africa. I was talking about California.

**Tom Wilkie:** Oh, okay. I think that's something we can agree on. You know, I went to Franschhoek yesterday, oh, a day before yesterday in South Africa. And it's all French wine. It's all French grape varieties, French, you know, everything around there is all French. I think there was some, you know, colonial past there.

**Cyril Tovena:** \[02:00\] Nice. Did you like it?

**Tom Wilkie:** Yeah, no, the wine was lovely. Yeah, are you going to be on your best behavior? Are you going to not have any words we have to bleep today?

**Cyril Tovena:** I think, yeah, we'll be fine. I'll try to stay away from the F-word.

**Tom Wilkie:** Thank you. You like it, actually. Yeah. The first episode we had Cyril on, I think we got a few complaints because it sounds different in his French accent. But hey, so today we are talking about agentic AI and observability, you know, and more specifically about automated root cause analysis, right? Because there's so many use cases for agentic AI and observability. You know, my first question is really kind of useful. Like you mentioned you started this new company, Resolve AI. You know, what's the Resolve AI story? What's this all about?

**Spiros Xanthos:** Yes. Like you folks, I worked for a long time in observability. Started two companies before, a log analytics platform. We got acquired by VMware. And then Yuri Shkuro and I, who's my co-founder here, co-created OpenTelemetry in 2018 and built a company around it. We ended up getting acquired by Splunk. And then there I also ran a pretty large software engineering team and production system. And so like firsthand, the other side of the equation, right? What happens when you need to do that. And you know, my realization was that despite having unlimited access to our own tools, we didn't have to worry about the cost. The majority of our time at scale was actually spent in running and debugging and maintaining the system. So we, Yuri Shkuro and I, two years ago decided maybe to try to think what is the way to do this in an AI-first way. Essentially trying to build the agents that are not trying to replace the existing tools, but rather work alongside humans in using these tools to, let's say, improve reliability of production systems, starting with obviously being on call and being able to troubleshoot when something goes wrong. And you know, that's kind of the origin story. We've known each other for a while. I do believe it's a very hard problem, but it's also something that is essential, especially in the era of AI coding, where we're going to be producing a lot more software.

And we'll definitely need the assistance of AI in running it.

**Tom Wilkie:** Yeah, that's a really interesting point. Like I get the question a lot from our customers at Grafana Labs. Like, you know, is agentic AI going to mean I can hire fewer engineers, right? I definitely feel like the answer's no. Like we're going to just be making so much more software that hopefully maybe, you know, we can run it with agentic AI at least and, you know, not have to hire loads of people to run the software. The answer is yes, definitely. So you, you were one of the original engineers writing the Grafana Assistant, which has some overlap here. But you had a very different founding story for the assistant, if I recall correctly.

**Cyril Tovena:** Yeah, it was, I was actually thinking about, because we were using a lot of Cursor. So we really liked using Cursor at the time. It was a year ago, and Cursor was a really good coding agent. And we were quite impressed by the fact that it was well integrated into your IDE. And because it was well integrated in your IDE, we had enough context, and it was able to help you on the task. And so we had this idea, I actually pitched it many times. I was like, we should do Cursor for Grafana. And at first, I think I pitched that idea to many people. They were not really understanding what it was meaning. But then we did the hackathon with a couple of people in the team that are still part of the team now. And yeah, the assistant came out and it was a great success. So pretty happy about the results so far. The key here is that by using AI, we basically realized, you know, how you can apply the same technique from another field into the observability field. And I think that was what helped us break through.

**Tom Wilkie:** So it sounds like you set out with the idea to automate a lot of the root cause analysis and incident response using AI. Is that correct? Am I understanding that?

**Spiros Xanthos:** Yeah, that's correct. That's correct. I guess, you know, in our case, we're starting from scratch in some sense.

And, you know, in my view, observability has evolved quite a bit and it's much more useful, right? So all the data is in place at this point. I don't think yet another observability tool will help us become better in some sense, right? Better integration obviously helps, but our thesis was that all this data is in place, but humans are, let's say, the operators. It's one of these tools. Oftentimes you have multiple tools in place, right? Even multiple observability tools, but of course tools outside of observability that you use to troubleshoot, right? You obviously need to consult code, you need to understand the structure, you need to understand changes. So our thesis was, or our view of the world was, that humans are the operators of each of these tools. And they're also the glue on top, right? And that's what slows us down and makes it very, very hard, and oftentimes requires tens of people coming together to debug a problem. So we wanted to build agents that become the operators of these tools and as good as humans, and also they become the glue across them, right? And maybe that's the difference also in us doing it as a non-observability vendor, because we can connect to all the tools that might be in place.

**Cyril Tovena:** I actually have a question for you, Spiros, related to that. You said that we don't necessarily need a new database. If we look at all the databases that exist, whether it's like Splunk or Elasticsearch or Loki, all of those databases, do you think they are well equipped for the new age of AI that is coming?

**Spiros Xanthos:** Well, that's a good point. Yeah, I meant we don't need one more of these databases. Like, so it's a good distinction. I do think that we see that the existing way, like all these tools were built for humans, right? So when it comes to agents using them, they have limitations often, right? Like, maybe the throughput is not there. Maybe the API access is not there, right? So I do think these tools have to evolve, right? And in my opinion, there is a huge opportunity for observability tools to become agent-first. And in fact, become even more powerful, more important, more relevant in the era of agents, right? But also, if they don't evolve, they might become the bottleneck, and they might be sidestepped by agents as a result.

**Cyril Tovena:** I definitely agree with the idea that these need to evolve, right? I didn't mean that. I meant more of that. Yeah. We don't need necessarily more data.

**Tom Wilkie:** That's fascinating. Manoj, I want to bring you in here because your startup from a few years ago took a very different approach to automated root cause analysis, right? Like, was not, you know, at the time, at least, not leveraging LLMs historically, you know? And so it sounds like we've got two approaches here already. Spiros set out to build an agentic root cause analysis. I think the root cause analysis capabilities of the Grafana Assistant almost emerged from the hackathon, not, you know, somewhat not intentionally. But yeah, Manoj, tell us a little about the knowledge graph and what you were working on.

**Manoj Acharya:** Yeah. So, I'd just say, quick, like, the origin story of the idea itself, right? Like, you know, I was in a company called AppDynamics for 10 years, built APM product and found that there are just too many signals and it's just scattered around. And a human, like a VP or an engineer, has to sit there and link stuff, right? This is linked to that and it's linked to this. So that's where the idea of the knowledge graph came about, right? I read the paper from Google back from 2012 to 2013. And then I said, okay, this thing can be applied to observability data. And then we started our own journey with the seven of us as an early stage startup. And then it was like, okay, so everybody's going to start using the open source data collectors. And in that world, the data is kind of labeled but not perfectly labeled. So what if we could take whatever is the intelligence or the knowledge that is already encoded into the data and transfer that into a graph database? So essentially, this is pre-LLM world, right? I'm talking 2020. LLMs have not arrived in their current shape and form. But you could still reconstruct the scattered data into a graph database.

And then you can ask all kinds of interesting questions, because there are very powerful graph algorithms that only exist in centrality and where is the... and if you know where everybody's calling the service, that database, and then that database or the service is having trouble, then that's likely the root cause, you know? So that was kind of the genesis of the knowledge graph product itself.

**Tom Wilkie:** Oh, that's cool, yeah. It's great. Like, do you take any of these concepts in Resolve? Like, do you have the concept of a knowledge graph? How are you handling that?

**Spiros Xanthos:** Yes, so I think this applies actually today. What Manoj was describing in my opinion applies in the era of agents, models, and tool calling. Because when you're dealing with a production system, first of all, production systems are not documented. Or rather, documentation lives in tools, human minds, and documents that are often outdated, right? So it does help to have a context graph, as it's called these days, or a knowledge graph, that tries to tie these things together, right? It doesn't have to be perfect in my opinion, but it gives something that the agents can use to reason about dependencies, about changes, about what might affect a problem that you see. A user might be experiencing something, but it might be deriving from a database that is maybe three or four steps down. So Resolve tries to essentially reconstruct that context graph, let's call it, and maintain it offline, but also the agents have the ability to navigate the production system real time and have these paths created as the agent reasons about problems or tasks.

**Tom Wilkie:** I think something Manoj touched on there, and I think Cyril also mentioned it as well, is knowing, you know, these models knowing how to access the data, right? Manoj, with the knowledge graph, curates a lot of that. And what we found with the Grafana Assistant is a lot of the foundation models from the big vendors already know how to use our software, already know about OpenTelemetry labels, because it's in the training set for them, right? They know about open source, they know about PromQL, they know about LogQL, they know about these kind of capabilities. So we tend to, you know, we, Grafana Labs here, tend to go around kind of saying open source is our secret weapon when it comes to AI. Because these foundation models know how to use our software. Bingo. I don't know, like, I am definitely a layperson in this space. Spiros, does that sound reasonable? Or how would you poke holes in that?

**Spiros Xanthos:** I think this is moving in a way, maybe, like, PromQL, it's a hard thing for humans to use, but it's now maybe an easy thing for models to use, because they have seen enough of it. And I think it's the right way, in my opinion, is to ask a model or an agent to do what you want and construct a query. But I think this is where the context comes into play. The naive way, in my opinion, to build agents that try to query existing systems is you give them access to the systems directly, right? But then what happens is they will end up overwhelming the underlying system, right? You cannot go and try to take all the logs out of Loki or Splunk or a system like this, because it's practically impossible, right? If code might be finite, so an agent can see all of it, but logs are practically infinite, right? Like, you know, in a period of a day or a week. So this context in the graph helps, and I think it's essential for being able to write precise queries and retrieve the data that you actually need to debug a problem.

**Tom Wilkie:** You mentioned that Resolve AI sits atop a lot of databases and observability platforms, Grafana Cloud obviously being one, but not the only one, right? Like, how do you deal with the differences between the platforms and how do you, for want of a better term, teach your agents to access data that's fundamentally a different shape or a different query language? How are you handling that problem?

**Spiros Xanthos:** You know, to your point earlier, although a lot of maybe the querying of these systems is in the training set, the actual debugging of problems is not, right? So this makes it a very, very hard problem. We have to do a lot of work on top of the models. And in fact, we think of Resolve as a full stack company that builds both agents and models to deal with the problem, because we hit the limitations of what you can do sometimes with frontier models. But, you know, to your point, I think we have essentially designed agents that understand logs. And we think of that category. There are agents that can query the different log implementations and databases, right? So there is that kind of two-level abstraction. And then we give these agents tools as well to analyze the data. And the same applies to code, applies to metrics, applies to infrastructure. And in a way, a lot of the work we have done is in being the operators of these tools that are slightly different, but also being the glue across them, right? We have spent a lot of time in creating reasoning and planning and even memories so that when we repeat the task, we are much smarter next time. So I would say that's a lot of the technology we have created. But also, where the value of this comes, right? Because if you have, oftentimes as a human, you have to go query all these systems. It's hard to remember the PromQL query to run, right? Or the SPL query to run. And then that's the first step, right? Then you need to take all this data, analyze it and connect it, right? So I think agents do that quite well.

**Cyril Tovena:** I had a fun fact about what you said about PromQL and the knowledge from LLMs and frontier models. We recently discovered, so there was one user that wanted to use native histogram. It's a quite new feature in Prometheus, and actually it doesn't perform very well with it, because I guess the cutoff date is close to when it was released, and yeah, that was way more challenging for sure for us to actually make the model understand native histogram.

**Spiros Xanthos:** By the way, this is what you can, some of the advantages in the era are, right? I think the models have become quite good at following examples. If you give them enough knowledge, usually they're good at it, right? I'm oftentimes very impressed, by the way. We use Grafana tools ourselves. And there was a point in time, probably sometime, let's say six months ago, where people stopped querying these directly usually, and they go through Resolve when they want to query this. And even outside of debugging, right? Like, somebody wants to get maybe some data out.

And I think that was my realization where I think there's going to be definitely a production abstraction layer on top of all the tools, right? That humans manage, rather than maybe knowing the specifics of the language, most of the time, at least.

**Cyril Tovena:** That's one thing that we see with customers. When we are in a sales cycle, it's very overwhelming the amount of knowledge that you have to learn to be able to use all those tools. And I think it's even more complicated in the open source because there's so many different tools that are different and there's a subtle new language that you need to learn. And yeah, people don't necessarily want to learn a new language. So I think AI is kind of interesting in that space, where they don't necessarily need to, they know about the concept of what is a metric. They don't necessarily want to learn about PromQL and all the complexity. Some queries can be quite complex, to be fair. I mean, that's what is magical here is that it removes a lot of the burden on the SREs and the engineers to know about those languages, to onboard very quickly on those tools.

**Spiros Xanthos:** Well, I have two more observations along the same lines, which is one is that the other side of this is also hard, right? Let's say you craft a query, you get the data back, then it's not easy to try to spot anomalies, right? Even if we're very good at crafting a query, right? Or understanding how to cluster data together, right? So I think agents, with the right tools, can do that very well as well, right?

And maybe the other realization I had is, you know, as someone who's worked in observability and always thought consolidation of data helps, I think LLMs probably enable us now to maybe use the best database, the best tool for the data, and then they are becoming the connector potentially, right? So maybe they enable best-of-breed architecture as well.

**Tom Wilkie:** Yeah, almost like an anti-consolidation argument. I like that. You mentioned, so you talked a bit about some of the challenges we see with customers. I've always thought about this. Our audience, our users, are SREs, DevOps practitioners, right?

People, systems engineers, right? These are people who, in my experience at least, are some of the most AI-skeptical engineers out there, right? Like, they're the ones who really want to ignore it, hope it goes away. So yeah, as an observability company, Cyril, and Spiros, I still think you're observability or observability-adjacent. How are you winning over those hearts and minds? I'll go for Spiros first.

**Spiros Xanthos:** For us, it is very true, right? I almost think that agents that work in production is harder than for code, because oftentimes you're dealing with a high-pressure situation, right? You don't have the time to ask the agent, hey, do this again, right? You made a mistake. So the other example I have is like self-driving cars, right? You don't trust a car to drive for you unless it drives a lot better than you do, right? And you've proven it for you, right? So the way we think about Resolve is, we do think that the right form factor for a tool like this is not a black box that you give it an incident, an alert, or a question, and then it spits out an answer on the other end, right? We think it has to be something, maybe akin to how we use coding agents, a Cursor or a Claude Code, that you work with, right? Accelerates what you do. Maybe improves some MTTR every time you use it. And whether it takes you to the right answer or not, right? It's very important for these agents to know as much as possible, right? If they have high confidence and the evidence and the answer, they should always cite everything they found, right? To ground the truth. And if they don't have the answer, they should give you all the work that's done, and then ask you what's the next step, right? The way maybe another engineer you've been working with would do it, right? And we found that that's the right form factor to make AI in production work, because then humans trust it and can use it every time, right? And it doesn't mislead them.

**Cyril Tovena:** Yeah, I couldn't agree more. It's definitely interesting, because I feel like it's a bit the same as any other tech, where you have early adopters and laggards, and obviously laggards are much more skeptical and early adopters are like hyped.

This is the best. And I think where it makes a big difference is the accuracy and the trust that the engineer has. What I've seen, because I've built a lot of different agents and a lot of features, and I've iterated a lot with product, and I realized that usually how you convince the skeptical is by quality. If it is really good, then usually you definitely will get them to understand the value. The problem is that, I think, in the AI space, there's a lot of slop software, and there's a lot of hyped software, and so it's very easy for them to try something, and then they realize, well, this is just actually a wrong answer. And they automatically assume that this product, all the products will be the same. All AI products will technically be the same. And I kind of agree with you, Spiros, on the grounding truth. I found this technique to be quite nice, to always ask the LLM to cite its findings, because if you don't, then it's definitely going to hallucinate an answer. Because that's the thing with LLMs, they always want to answer. They want to please you, for sure, actually, yes.

**Spiros Xanthos:** And by the way, why don't you think observability, how, with what you're saying, Cyril, is that I've seen the same, right? As you said, there is a lot of slop, there is a lot of, like, it's very different to build a demo, right? But I think I've seen a reversal by now. I would say in the last few months, I observed that when people tried to build something or try a product that had a baseline, then it becomes easier for them to understand a good product in AI also, I would say, right? Because it's much easier to have, like, if you have a baseline and you've seen something that's mediocre, then there's a product that works really well, right? It has the power that you need to get it to work right every time.

**Cyril Tovena:** Yeah, I mean, I think Tom asked that question because we had a lot of skeptics at the beginning of AI in the company. And I think the Claude Code moment was probably the moment where everyone was like, yeah, I think I get it now. And at the same time, right?

We're getting more and more users of Assistant internally. Because now they can relate to that story they had with coding and they say, yeah, I can actually trust that tech.

**Manoj Acharya:** I think I have a slightly contrarian view that I think humans are lazy. And if you make something easy for them, they will work harder to make it work, right? So, I mean, I see that in myself, right? If I start seeing something working, I will work harder to make it work for me. And I'm definitely getting there. A good example is like, you know, a classic feature that we had in our product is a knowledge graph search, right? You can add a search expression to find parts of it. So now we have given Assistant the schema of the graph, you don't have to build it in a wizard anymore. You can literally type it, it just works. So now they can tell it, like, okay, when the alert happens, go look for this segment of the graph, right? They were doing it manually before. And now they can literally let Assistant do it for them. And so they will work harder to make it work. You know, at least I'm seeing that.

**Tom Wilkie:** I think there's a moment happening. Like, I can remember 15 years ago when CICD was a thing people talked about but didn't do, right? And you had to go and convince the grumpy old software engineer that having a server run your tests for you, you know, or code review. My first professional software engineering gig, we didn't do code review, which looking back is like, how would you possibly let me work on software without having someone check my code? But yeah, I just think agentic software engineering and agentic observability is going to follow a similar path. You're going to be a laggard, and you're going to be kind of ridiculed almost if you don't adopt and know how to get the best out of and put the time and effort in to learn these tools. So yeah, I think I kind of agree.

**Spiros Xanthos:** By the way, I think I agree. I think also it's happening a lot faster than maybe other things, other similar kinds of transformations, right? My thesis at the moment is that, and I see this with Resolve, agents for observability and production are going to be working as well as agents for coding. And in fact, it is a harder problem, right? So potentially the value here is more, considering all the software we have out there, right? It exists and all the new software we're creating now with AI, right? And I do think it's going to happen, or like that breakthrough moment that you were describing as the Claude Code moment, I think it's going to happen sometime this year for AI that is working in production and observability.

**Cyril Tovena:** I was about to say that I think what's interesting is also the pace at which the models are getting better. It's quite incredible. Like Opus 4.5 was a big moment for coding, for sure. And I wouldn't be surprised that this year, we're going to get even better.

**Tom Wilkie:** I'm going to jump about a bit just to explore what you brought up there about the aha moment for agents in production, right? Like, how far out is it that software agents run software for you, fully autonomously, right? How far away is removing the human from the loop? Is that even the right question, right? And in particular, if that is the case, and we are going to get to software that basically runs itself, operates itself, how are you going to keep an agent accountable for an SLA violation? Like, what does that even mean, right? Many, many questions in this, right?

**Spiros Xanthos:** I'll give you my view of how the future might look like, a version of it at least, right? And I would say, how do you hold a human accountable also to some extent for mistakes, right? I do think that what I see with Resolve, right? What we started two years ago, people were very skeptical of an agent in production at all, right? Or an agent working on the problem, right? I would say over the past year, that has been removed, I think. Especially coding agents paved the way. I think right now, people are very comfortable with agents doing their work, maybe a human having the final say, right? I think over the next probably few quarters, this next year, I do think we're going to remove the need for a human to be in the loop for the agent to take the final action, potentially for debugging a problem or performing a task in production. I do expect maybe the majority of incidents that happen have an automated resolution by an agent by the end of the year. So in a way, maybe by the end of the year, agents are going to be on par in terms of abilities for this particular problem with maybe a senior software engineer, right? And we're going to trust them this way. But I do think that's not the end of it. Maybe in another year out, assuming the same pace of progress, maybe agents are going to start becoming like, start running production, right? Maybe becoming this abstraction layer on top of the existing systems and tools. Maybe these systems also evolve to be agent-friendly. And humans now manage these agents with goals more so than with specific tasks, and with having the final say, right? Maybe two years out for something like this. And maybe if you play it out further, what might end up happening is essentially agents become a lot better in specific tasks compared to humans. And then the result of this, in my opinion, is a positive thing, right? Which is we produce a lot more technology, we write a lot more software, we solve a lot more problems that are either expensive or difficult. And we improve the world as a result. Yeah. Of course, we have to be thoughtful on the way there and the consequences. But I am an optimist in what I think happens next.

**Cyril Tovena:** Yeah, I'm also quite optimistic about this. And I think it's already happening right now. We can see it in the coding space. Again, I like to relate to the coding space because it feels like it's just a bit in advance compared to AI for observability. And you can see now with those feedback loops, the agent is actually autonomously writing tests and then going into the loop until the test is passing. So you can see that the autonomous and long-running task is becoming more and more something real, which wasn't the case before. And so I do expect that. And I think this is the case for us. The end goal is definitely to try to automatically resolve incidents. But I do think there is a path to that. You need to first show the customers that you can trust the software. And then once you are there, it will become definitely clear that you can also give access to maybe rolling back or changing your code directly. It's the same story that we had internally. I remember when we started using Cursor, we had a lot of people that were against using background agents. But then over time, with trust, it just became natural. And everyone is using background agents now. So I think the fear of giving access just gets removed slowly as the quality gets better.

**Tom Wilkie:** And I want to be the anti-AI maximalist here, just to play that role for a second. This reminds me of like, there was a spate of companies that would optimize your AWS bill, right? They would come in and analyze the size of all your VMs and resize all your VMs to fit. And I'm not going to name names, but I don't particularly think that sector was very successful, right? And in particular, not a lot of people trusted them to do that. I think it caused a lot of outages for many people. Like, I can think of ones that happened to me, right? And in general, it's kind of this accountability. This piece of software comes in, resizes and breaks all your infrastructure. And what can you do? Not buy the software in the future, right? That's the only recourse, right? So I do get the building trust, and the human in the loop to begin with at least, arguments. But we've been down this road. Even how many, you know, there's so many services, even at Grafana Labs, that we don't even autoscale at this point, because it's so risky and you can hold a human to account.

**Spiros Xanthos:** \[30:01\] Right. You can hold them into account via performance management, via coaching, you know, there's various different mechanisms. Worse comes to worst, if they're causing repeat incidents, it becomes a horrible discussion.

Well, to talk about, I mean, I think that maybe the difference between the last generation of these technologies — like AIOps is another example in my mind, right? As a concept, everybody obviously wanted it to be true. In practice, it wasn't because we were limited by what was available, right? We could do some anomaly detection, we could group some things together, but in reality it didn't generalize well.

But I think the difference is that models can reason and generalize quite well, right? So they can essentially perform novel tasks oftentimes, or deal with uncertainty, or criticize their own work to validate — as well, maybe, as a human could. And maybe two real-world examples I have. One is, I see customers now auto-approving code changes that the agent makes, typically as infrastructure as code, but for simple changes — let's say add some capacity, right, or a small markup change — because they've seen it happening enough times and now it's safe. Or, I see myself, right, how much I trust my Tesla now to drive me to work every day. That wasn't the case six months ago. I don't pay attention. And I think that will apply to software, in my opinion.

**Tom Wilkie:** Yeah. That's an interesting segue, because what is the most interesting, esoteric, impressive incident that you've automatically root-caused, and maybe even resolved, without betraying any trust here? Obviously not betraying any trust.

**Spiros Xanthos:** Like, for me, I'll tell you, right, because we work with some very large technology companies. I think the most probably interesting problems are things that I've seen many times. And I've seen some even in our own environment where you usually have a latent problem. Maybe there is a code change. Maybe there is something that changes in the environment. Maybe a load test running somewhere that actually has impact probably after a little while, because it breaks something — it breaks slowly. And I think that's usually very, very hard for humans to dissect.

Oftentimes maybe it's even a concurrency problem, right? Which, by itself, is very hard. And I think I've seen now, over the last maybe few months, our agent becoming better and better at removing the constant noise that exists in the background and actually getting to these causality chains that are very, very hard for a human to troubleshoot.

Maybe to give you a concrete example, because it was in our environment and I can share — we had, I think, October-November, this bug where somebody introduced a function that was calling a database to update something without deterministic lock ordering. And then a few days later, we received a lot of events that made us spin up automatically a bunch of pods to process all these events. They all started hitting the database and created a deadlock, right?

And our team was trying to figure out what was going on in the moment, in the panic moment. Somebody started debugging by themselves, and Resolve was running in parallel. And it ended up finding out this latent bug, right, that was three days later manifesting as a deadlock issue. And even more impressively, what it did is — that code was changed actually multiple times after the moment of the bug, which was three days before. But none of the new changes actually changed the behavior, right? So it was able to dissect that as well.

Anyway, I think that's just an example. But also, like I said, I think it's very, very important to provide evidence, and if the agent doesn't have high confidence, to not try to say it does, right? Because in a similar way that this is impressive, it can also lead you down the wrong path very easily.

**Manoj Acharya:** Yeah, the only example that comes to my mind was someone doing actually a demo into a customer environment. And, yes —

**Cyril Tovena:** I remember that.

**Manoj Acharya:** Yeah, you remember this one. And so the customer, as he was watching the demo — can't name the customer here.

**Tom Wilkie:** Yeah, we can't name the customer.

**Manoj Acharya:** But as the demo was happening of the Grafana Assistant, the customer suspected something was wrong in his environment. And then used the assistant to figure out that it was being attacked. So that was definitely interesting.

**Tom Wilkie:** Yeah, and an emergent property as well. We'd never done any work specifically in the security space, right?

**Manoj Acharya:** Yeah, exactly. That was the interesting part.

**Spiros Xanthos:** I've seen this as well a lot. We didn't design Resolve to be used for security investigations. But I see people using it all the time for things like this. And I think that is because — which is the argument for kind of AI for prod, almost, right, that goes beyond observability. One should have these agents, essentially, that can do a good job using the tools, right? The tools across them. In reality, many production tasks, right, whether it's security engineering or optimizing infrastructure, right, to your point earlier, Tom — actually follow a similar pattern of reasoning, right? And I think agents do a pretty good job.

**Tom Wilkie:** Manoj, what was the best knowledge graph-based RCA that you've witnessed?

**Manoj Acharya:** Yeah, so I will cite one internal one and one from a customer. So the customer one is actually a highly event-driven system, and they have built lots of topics and services talking to each other. And as you know, the system is just flowing, flying around, right? Every one is a unique flow. So this customer actually has taken the effort to encode the flows — flow one, flow two, flow three — by different business domains.

So what they were traditionally doing is they had a dashboard for every topic and every service. But now, when the alert happens, they have linked that flow into the alert, right? So it automatically populates our RCA workbench, which is where we bring all the signals together. This is the classic knowledge graph. I'm talking pre-assistant, right?

But now we have shown them assistant. They're not in auto-production yet, but they're super excited to almost triple-double down on their pattern definitions, because it's very custom to them. There's no way we would know the business flows, right? But they're like, okay, every time this alert happens, this engineer or this group of engineers will straight get an output from assistant summarizing all the data that was previously shown in the workbench, right? And they can then determine should they dive in or is it not a big deal.

So that I'm pretty excited about. Internally, the one that recently happened to us is literally we had an incident and the team was literally launching the assistant asking what changed recently, and that's working really well, right? So for example, I'm sure you know, we have this thing called Kube Diff Logger. We log all our Kubernetes events. Interesting parts are already done inside Grafana in our own product. It's an open-source project. And we have transformed that into what we call change events — that's feeding that to assistant now. So people can instantly ask this one question, okay, because they know what to do every day, right? So now they don't have to go open that other dashboard and look for it. So that's working really well.

By the way, Tom, I have a question for you about something related. Something that we've seen a lot with customers is that they usually have a lot of data and not necessarily querying that much. They just query a very subset. But with AI, it seems like the blast radius of the queries expands because searching becomes faster. And so they're searching more and then searching wider. Do you think that's something that's going to change how we charge customers for querying, or what's your take on that?

**Tom Wilkie:** This is something I wanted to ask Spiros as well. So this is kind of really interesting. We currently — queries in Grafana Cloud are free. You pay to store the data, you don't pay to query it. And we are seeing people — we believe it's from using the assistant and using systems like Resolve — doing orders of magnitude more querying than the economics of Grafana Cloud can support, right? And we don't — one of the key principles of Grafana Labs is openness, right? It's your data, you own it. We're never going to stop you doing anything with your data. It's your data. But we have to cover the costs of these kind of things.

So, who knows? But yeah, I suspect we'll probably have to introduce some kind of query-based fees in the future. Like maybe a large generous fair usage amount for most people, but for people doing particularly enormous query loads, maybe a charge for that. We'll see.

I mean, Spiros, is this something you're seeing across the industry? If you're integrating with lots of different data providers?

**Spiros Xanthos:** Yeah. So I'll start by saying that the way I see Resolve, the impact I see it having on observability, is a positive one, right? Because effectively you have now this expert user of all the tools in place that anybody can access, right? So essentially, there was always a power-user expert, right? Somebody who understood how to query metrics. And maybe they created dashboards, and most people consumed those, right? I think with an agent like Resolve, you can actually now go to that and satisfy every question you have without having to be an expert in the underlying tools, right? So in my opinion, it is a net positive.

Now, I do agree with you, right? Like I said, at Resolve, we try to be very careful and precise in how we use these tools. We don't want to overwhelm them. We're not going to be the reason that it costs them. But, oftentimes we become a bottleneck. And interestingly, when we see that happening, it's usually when somebody has an on-prem deployment that they manage themselves, right? And they probably don't do a very good job sizing that. So they're very conservative and all of that, right?

I think I see it less with Grafana Cloud, right, or other similar SaaS solutions that are very well managed, obviously, at scale. But I agree with you, Tom. I think this is an opportunity, in my opinion, for the data systems, right? For these systems of record to come from how you use the data, not from what data you collect, almost, right? So I think maybe the pricing model of the past, where we charged by volume of data or by host, is probably not the appropriate one in the era of agents, right? Where they may become the main system that queries this data. And I think these have to evolve. And I honestly believe it's a great opportunity. If companies like Grafana could do this, evolve — I think they will become probably a lot more relevant, and maybe more for agents in the future.

**Tom Wilkie:** Yeah, I mean, we hope so. But particularly for Resolve, is there not a strategic risk here that some of the other vendors in this space kind of lock you out or prevent you from accessing the data? I mean, as I said, we're not going to do that, right? We're all about being open here, but...

**Spiros Xanthos:** I think, like I said, I don't think what Resolve does competes with these systems. And I think there is a natural force here, which is that obviously agents are inevitable, right? So if you're in a position where you end up becoming the bottleneck, I don't think that's strategically the right thing to do for any company. So even if it happens individually, I think it's going to be a mistake for somebody who tries to do that. Because eventually they're going to be sidestepped by agents that might replace them with other systems that are more open, right?

And from our perspective, we try to be good citizens, right? We're very, very careful about how we use these tools. We're going to use them the way they're designed — almost like the way a human would use them, right? And of course we hope that they evolve and improve. The throughput becomes better, you can do things faster, et cetera. And I think the right way to do this is by evolving the pricing models.

But I'm not as worried, because like I said, I think it's not a question of what any individual vendor does. It's a question of what the industry does, right? And I think what you described, Tom, is the future.

**Tom Wilkie:** Yeah, I mean, our open-source ethos at Grafana Labs is not just out of the kindness of our own hearts. I mean, partially it is, but it's also because it's a competitive differentiator for us, right? We think customers will choose our data platform because they get to do with the data as they please, right? And because it's more cost-effective and so on. And if this was important before, I think it's more important with agents, right?

**Spiros Xanthos:** That's my point, yeah. A hundred percent agree.

**Tom Wilkie:** How are the economics of this? To be more specific, you always hear about value-based pricing, right? We're talking about pricing — you always hear everyone wants to charge you based on the value, where you want to charge your users based on the value you deliver to them. And then, of course, pretty much everyone in the industry actually does cost-plus pricing, like charging them some percentage on top of how much they spend on Amazon to run these services. How are you thinking about those kind of things? How are you thinking about capturing the value that something like Resolve is delivering?

**Spiros Xanthos:** A very good question. I think that when agents perform tasks in production, there are some tasks that are actually very high value, right? If the agent materially improves your MTTR and reliability, that has a lot of value beyond the work they do, right? So I think it's a combination of two things, in my opinion. It is a combination of — okay, are the agents solving a problem that actually helps improve the business, right? Results in more revenue or revenue-loss reduction? And in that case, I think there is room potentially for value-based pricing the way you're describing it.

But also, I think these agents do a lot of work, right? And I think that work is replacing human effort. Or, let's say, we translate human effort into tokens, right? And I think that probably is closer to maybe some more flat-type pricing, where let's say for every minute of work the agent saves, it charges you a lot less than what it costs for a human, right? And I think in that sense, agents become a no-brainer, because probably the cost is cheaper than the human-equivalent effort, but also maybe they drive better outcomes — relative improvement, cost optimization, et cetera.

I don't have a better answer myself, but it's one of those where —

**Tom Wilkie:** I hate the idea that we're just going to transfer all the cost-plus pricing models of telemetry storage over to this new agentic world and do cost-plus on tokens, basically. It just seems like an opportunity to do a lot better. But we mentioned briefly those companies that did the "give us your Amazon bill and we'll save you a bunch of money by resizing it." That was the opportunity to do really good value-based pricing, right? Because you just charge a percentage of the money saved. But yeah, I'm just looking for that kind of aha moment of simple-to-understand pricing that really makes it easy to see the value that you're delivering, right?

**Spiros Xanthos:** Yeah, I mean, I think one thing that makes this challenging, obviously, in production is — let's contrast it with customer service, for example, right, where you have agents that deflect maybe customer requests, right? That's kind of very easy to do outcome-based pricing. I think in our case, obviously, production systems are very hard — lots of technical details. It is more difficult to have a similar outcome-based pricing. Although that would be the ideal, right? Because then you say, okay, did I do this? And maybe in a year from now we'll be there, right? And we can have very well-understood tasks that the agent performs completely without human intervention.

Today, the way we approach it is mostly to think about the work the agent does. And we get paid when that work is performed, right? And usually it saves a lot of human effort and results in better outcomes. But it's kind of somewhere between value-based and cost-based, almost.

**Cyril Tovena:** Yeah, it's a tricky one. For autonomous workloads, I think that's why it's difficult. Because when it's like a bit like Grafana Assistant, where you are actually prompting the system and you are asking questions, I think it's pretty clear that it's going to be difficult to do based on just the value that you get, because the value you get is what you ask. And so if you're asking the wrong question or making mistakes in your prompt, then you're not going to get value. But in autonomous, I think — like an alert fires and then you're trying to investigate the problem — I think it makes sense to try to do value-based pricing.

The only problem that I see is that the value that, as an enterprise providing that product, and the value perceived from the customer, is always going to be different. And I think that's why it's going to be difficult, because if you ask the customer, it's value-based, and, "tell me what the value was on that agent," they probably will say, "Hey, it wasn't great. I don't want to pay more." So I think that's why it's a bit difficult. But I agree with you, Spiros — the ideal will be on value, for sure.

**Tom Wilkie:** Slightly different topic to pricing, and this is going well off this being a technical podcast. What are your customers telling you about data privacy? Because we get a lot of skepticism from — I definitely am the AI skeptic in this conversation — get a lot of skepticism from especially European companies adopting the Grafana Assistant and technology like that, because they worry, I think, that some of their private telemetry data will leak into the training sets for future models, right? So what do you — how are you handling that, Spiros?

**Spiros Xanthos:** Yeah, so obviously we work with lots of enterprises. So we take data privacy and security extremely seriously, right? And I think that's almost like a non-negotiable. And you probably see that more in Europe, let's say, for various reasons. But I think similarly in the US, right? Nobody's going to trust you unless they really trust that you handle the data properly. And we give strong guarantees that we're not going to train any model with the data, et cetera.

Now, I'll tell you two sides of this. Obviously, you're dealing with production systems that oftentimes contain sensitive data. I think the fact that there are engineers and executives out there that are willing, essentially, to go do all the work it takes to introduce an AI in the production system speaks about the value and the pain of the problem, right? And that's often the way I tell my team — it is obviously hard and difficult, and going through security reviews and all of that is not easy for a company like this. But if people are willing to do it, it means that it obviously has a lot of value.

Now, for us as a vendor, I think we try to have very clear separation of data plane and control plane, to keep very strong guarantees, many layers of filtering and controls that the customer has. And I think that's a prerequisite, right? But still, oftentimes we see that people require maybe an on-prem deployment that is completely segregated, right? And I do think that's currently a major consideration and something that vendors like us will have to support, at least for very large or very regulated environments.

**Tom Wilkie:** Yeah. We're really moving away from offering self-managed software. At Grafana Labs, the assistant is not available and probably will never be available as a self-managed piece of software. So we're trying to focus on very different answers to that question around — how about we run it, we operate it, Grafana Labs operates it in your Amazon or Google account, right? A different approach. But it does scare me.

**Spiros Xanthos:** Agree with you. Agree with you. It doesn't mean that a segregated environment means self-managed, right? Because I know all of the wrongs with that.

**Tom Wilkie:** I'm just trying to — it's so hard to move quickly building software if you've got customers running 18-month-old versions of it, right? Which has been my experience with enterprise software.

One of the other things that makes me a bit nervous about all of this, right, playing the role of AI skeptic here, is — up until relatively recently, Grafana Cloud has had no ability to modify your state. Right? It's been view-only. We've basically given you really deep insights into what's going on, back in time, but it's pretty much a read-only interface in terms of telemetry signals and alerts and so on.

This is changing now. You can start to connect up MCP services to Grafana Cloud and have it putting code changes and so on. And it sounds similar in Resolve, right? And that — I don't know — that scares the crap out of me, right? Someone could potentially compromise our SaaS and then get into our customer's SaaS from there. That's something where, again, we take the security of Grafana Cloud very, very seriously, and we do everything humanly possible to prevent that. But yeah, that's something that I worry about. How are you — I guess, similar answer to the last question?

**Spiros Xanthos:** I don't think it should be very easy for agents to mutate production systems, actually, right? I think that should go through some controlled process, in my opinion. The way we think about it is — if it's a code change, obviously go through a code review and all of that, right? And maybe it should be only — suppose we're limited in what it changes, right? Or if it's a change to the production itself, it should probably be done through a set of approved actions that have been validated in advance, right?

**Tom Wilkie:** And preferably not by another LLM, yeah.

**Spiros Xanthos:** Not by — exactly. And then, I do think also that the agents should live in a sandbox, also, right? At the moment they can start taking actions. And so we kind of control that completely and only take actions after they have been approved. I think we're not at the point where we'll let agents run wild in production, right? If they take actions, they're going to be pre-approved actions that are controlled. But the same concepts of privacy apply to all of the security questions as well.

**Cyril Tovena:** I find it funny that you're playing really a good role of skeptic for someone who is vibe-coding his whole home automation using AI.

**Tom Wilkie:** My house is basically running itself now. Like, an agent decides when to turn the heating on. I had this problem all along — I get up at weird times of the day in various — there's no set schedule for me. And there's never hot water. And so now I've just fed a calendar into an agent and it just decides when to turn the hot water on. It's kind of cool.

**Spiros Xanthos:** Are you on the OpenAI tier, Tom?

**Tom Wilkie:** The thing I just described is something I wrote myself. But I have got an OpenAI — no, actually, so I've got an old MQTT bot running old, like, week-old

**Spiros Xanthos:** \[52:07\] Sounds like Tom —

**Tom Wilkie:** I don't trust my AI. But if the worst it can do is no hot water or too much hot water, then, I'll catch that pretty quickly.

So we talked about how agentic AI has really revolutionized coding. And I think to your point, it's ahead of observability. But I think the consensus is also that observability is on a similar path. So what's next? What's going to happen after observability and coding? Where is this technology going to apply in our space next?

**Spiros Xanthos:** I think maybe because of the fact that we usually go across other tools that are outside of observability, I may have some things I see already, right? So in our case, it started by trying to improve reliability, MTTR, production issues, and all of that, right? But I think the moment the agent started working very well and seemed very good about production tasks, we started seeing people using it for a lot of other things, right?

So, maybe a few examples. People will usually rightsize infrastructure, right? And to your point earlier about this category of companies, I think agents can do a better job, because what they can do is they can look at the data now, they understand pricing, then they can go back as long as they need to, look at telemetry, and understand the behavior of the system, right? Even correlate any potential production issues that happened to whether that was caused by, maybe, under-provisioning. So that's one category of things that we see happening.

Another category I would say is technical customer support, which touches usually the same type of data. It's something that ends up interrupting the SREs and developers quite a bit, because they're often the ones who know the problem. I think agents can become this in-between layer that probably can answer most questions. It can enable somebody who's on the support side but not an engineer to actually get the answer.

One more category is probably security engineering. I do think the same transformation that's happening maybe in the NOC or in the DevOps world is going to happen in the SOC as well.

Similar reasons, similar concepts. And eventually, like I said, I do think we're creating an abstraction layer above these tools. And over time, as these tools evolve to work better with this abstraction layer —

**Tom Wilkie:** Manoj, any thoughts?

**Manoj Acharya:** Yeah, so I'm in the lazy category, as you know, Tom. So basically I just want to create custom Claude skills which will do all kind of re-architecture. Remember how the classic thing goes — you have an SLO that breaches, go back and figure out what to fix in engineering. And I really, really want that closed loop there, right? Something that can look at production data, look at my current architecture, and then start making recommendations on how to prioritize which backlog item. That could be huge. I have too much backlog. We're trying to figure out based on instincts and all that stuff, which is fine. But something that can assist us there, right? Yeah, I mean, that'd be my next frontier, I would say.

**Spiros Xanthos:** Almost like AlphaZero, right?

**Manoj Acharya:** Yeah. How it starts from scratch and just knows the rules.

**Cyril Tovena:** I think there's also the business intelligence that is going to be — and it's already happening — revolutionized by AI. Because there are a lot of executives or directors that need to ask a question, and they usually go to a data analyst to answer those questions. But I think all of this can be automated. So I think this is probably a space that is even more dangerous, because yeah, you can technically ask a question about how is my revenue going and get the answer directly. So I think this is another space where there will definitely be a lot of improvement over time.

Maybe another one — in between, I feel like between code and observability, there's infrastructure. Infrastructure is where you can use coding agents right now. I think there is also space where you could vibe-code the deployment and automate that.

**Tom Wilkie:** \[56:09\] Yeah, I was going to say that — just for context, for us, we — and I'm sure most companies do this now — but we shove all of the code to generate the Kube manifests in a single repo, right? And it's all in this language called Jsonnet, and the engineers hate it, but it is a superpower of ours because you can do really complicated rollout strategies, we can roll out new regions, everything is infinitely tunable in production. And it's incredibly powerful and it gives us a huge amount of flexibility in being able to respond to incidents — like just twiddle something in deployment tools.

But yeah, I think config management is ripe for disruption with agentic AI. I think it's going to be completely replaced. The whole idea of, "turn this VM into something that can be reproduced" — that could just be handed off to an agent, right? It's such an obvious and easy thing to do.

**Manoj Acharya:** Well, anyway, I have a couple of data points, but sure, Spiros, I think —

**Spiros Xanthos:** Please. Because I completely agree with what Manoj and Cyril said, I'd like to take this point about more business intelligence. I think oftentimes, to answer these questions, you need to go back to technical data. And what I've seen at Resolve happening over time — probably like 90% of employees at Resolve use Resolve, and obviously not everybody is an engineer. But I see oftentimes salespeople going and asking questions about what's happening in a customer's environment. PMs using Resolve to maybe make a change in code to create a funnel in production for something they're tracking. Or maybe a customer support or solutions engineer going and trying to essentially understand the behavior of the system, or whether a feature flag is on, without having to bother engineers.

So I do think that essentially the users are expanding as a result, right? And the use cases are expanding as a result. And we're eliminating layers in between that were necessary before. And maybe we go to the bottleneck, right? Because if at the end of the day I need to go bother an engineer to run some query, I would be hesitant probably to interrupt them from what they're doing.

**Tom Wilkie:** What's not being asked because they don't want to interrupt people?

Very cool. So is there any last questions we should have asked, any last topics we should have brought up?

**Cyril Tovena:** I have one question for you, Spiros. As you are in an AI company, what is the AI software apart from yours that you're using and you would never go back?

**Spiros Xanthos:** So you're saying tools we use ourselves as a company?

**Cyril Tovena:** Yeah. Whether it's coding or maybe for your own use case as an executive — is there something that you really can't stop using anymore?

**Spiros Xanthos:** I would say, I think being a brand-new company allows us to essentially do AI-first on a lot of things, right, which may be difficult for an existing company to retrofit AI processes. So obviously, I would say — who can code without AI now? We can't even review what the code is generated, right? That wasn't the case three months ago, I would say. But now the iteration between, let's say, remote agents and their local agent, whether it's Claude Code or Cursor — they also use Resolve a lot. We actually have now a CLI, and people use it from the laptop. So a lot of the actions they take in production come directly from Resolve now. So Resolve becomes a system, the agent that kind of takes actions on their behalf in production.

At the higher level, for me, I would say I'm always trying to see — every time we're trying to perform a task that's manual, why do we do that? And is there an AI-first approach we can take that maybe saves us time, requires less effort? I think it applies to a lot of things. It applies to customer support. It definitely applies to legal reviews and all of the contract work that we have to do. It applies to your point about AI and how it can run the business metrics and all of that, right?

Yeah, I mean, I think Resolve will probably have a lot less people for the same level of, let's say, revenue and success. I'm probably characterizing it as a company that's going to be 10x less, 5x less — I don't know, but definitely less.

**Tom Wilkie:** Here's a controversial one for you. I use a lot of the LLM tools to do performance reviews.

**Spiros Xanthos:** \[60:01\] And I'm pretty sure my team are just putting them into an LLM to read them as well. It's a classic joke about, you know, I used an LLM to write an email and then used the LLM to summarize back the essence of the long sentence I intended to give you, right? I think that might be happening. But I also find LLMs as a feedback mechanism to be quite good, right? Like, if I record something I'm saying and ask, it's quite good actually in giving feedback. And I think maybe it's also a safe way for all of us, right? Whether you're a junior engineer on call and maybe you're afraid to go ask a question to somebody else, right? It's much easier to ask an agent. And maybe similar to ask for feedback for your own work, I'd say.

**Tom Wilkie:** The junior engineering point is interesting. It's a remote company where we don't hire a lot of junior engineers because there's no one they can sit next to and kind of bounce ideas off of at Grafana Labs. And I really think, as we get bigger, it's kind of our duty to hire junior engineers. And so maybe the agentic coding assistants become that rubber duck, right? Become that tool and technology that can enable us to hire more junior engineers. Who knows?

**Spiros Xanthos:** And I think, Tom, that applies to coding. But I think it applies to production, right? Because let's say you're a junior engineer faced with a production issue that might take down the system, right? You're starting with a cold start problem. Having some guidance from an agent like this is probably very, very useful and helpful.

**Cyril Tovena:** Tom, especially for someone who is not native English, if I have to write my own review, I have the intent of what I want the review to be. But writing it so it's nicely written for someone to read is taking me a lot of time, especially as a non-native English speaker. So using LLMs for writing my review, I think, yeah, of course, yes.

**Tom Wilkie:** Yeah, all of my writing is going very well.

Anyway, I think that's probably all the time we've got for today. So I want a big thank you to Spiros, to Manoj, to Cyril, for joining us. And thank you for listening. I will see you next time on Grafana's Big Tent.