[ON DEMAND] AI O11y, why your 
production is flying blind

TRANSCRIPT: AI Observability — From Zero to Full AI in One Sprint groundcover Webinar
SPEAKERS:
- Will Roberts — Product Marketing, groundcover (San Francisco) - Orr (Benjamin) — VP of Product, groundcover (Tel Aviv) - Noam (Levy) — Field CTO & Founding Engineer, groundcover (New York City)
WILL ROBERTS:
Welcome everyone to this super exciting conversation on AI observability — from zero to full AI in one sprint. I'm Will Roberts, the product marketing person here at groundcover, joining you all from sunny San Francisco. Today with me I have two incredible speakers who know a lot more about this space than anyone else I know.
First I have VP of Product, Orr Benjamin, joining us from Tel Aviv. Orr, welcome.
ORR BENJAMIN:
Thank you. Great to be here, Will.
WILL ROBERTS:
Next I have Field CTO and, I believe, founding engineer joining us from New York City. Noam, welcome.
NOAM LEVY:
Hey everyone, great to be here.
WILL ROBERTS:
For everyone joining us, please tell us where you're joining from, and feel free to ask questions in the chat window. This will be an engaging, interactive webinar if you want it to be.
For those who don't know, observability platforms are essential to the reliability teams and developers who are building software today. Observability helps these teams keep the lights on for digital-first businesses by pointing out where in applications or infrastructure there are problems or potential issues. Observability platforms are also uniquely positioned to help dev teams think about or foresee the impact of both current and future work.
Two weeks ago, groundcover released full visibility into LLMs and AI agent workloads. It's established the market standard for what it's supposed to look like when mission-critical workloads — metrics, logs, traces — get captured inside your own cloud.
But why now? Why are we talking about AI observability now?
Well, first of all, 41% of all code as of 2025 is AI-generated, meaning developers are less aware than ever of what it is that they're shipping. It's rife with opportunities for issues and bugs to be introduced. What's more, 37% of enterprises are running applications that depend on the probabilistic outcomes of LLMs and network calls between them. And yet as of 2025, less than 20% of these engineering teams have the capability to track what's actually happening with these newly designed systems. This is clearly a problem of significant scale when these applications are deployed and out on their own.
groundcover released AI observability to the market specifically with these problems in mind. I've contextualized the problems in the space now, but I don't want to spend this entire time on slideware. As quickly as possible I want to get us to a demo. Noam, are you ready?
‍
DEMO SECTION — Presented by Noam
NOAM LEVY:
Yes, of course. I would also assume that for many of you joining us today this is the first time seeing groundcover, so before I jump straight to the main topic, let me speak for a second about what the groundcover solution is and how it's different from other observability solutions.
groundcover is truly — and vastly — different in two major aspects from any other observability solution you've seen to date.
The first is that in order to generate signals, groundcover is not just relying on engineers and on the concept of instrumentation. It relies on a technology called eBPF to essentially generate signals out of thin air about every interaction that your application is doing. This, in my opinion, fixes a very old but now-wrong assumption about observability: that we know how applications behave, and that engineers can predict where applications are going to fail. We want to remove this assumption and give you confidence that applications are running correctly without relying on the ability of engineers to predict where errors will stem from.
The second core difference is the architecture. groundcover is a BYOC solution. BYOC means Bring Your Own Cloud. That means we provide a SaaS experience like you'd use from any other observability SaaS vendor, but the entire posture of the solution is an on-prem posture — running completely within your cloud vendor
account. You get the best of both worlds in multiple aspects:
- Cost, which is no longer bound to ingestion. - Privacy, meaning you're no longer sharing the most sensitive data of your organization with a third party. - The ability to scale in a predictable way with observability.
Now, let's talk about AI observability specifically.
AI observability in groundcover is how we allow our customers and users to understand how their agentic workloads are interacting with LLMs. This is the first time in history that this practice in software engineering exists — the notion of applications working with LLMs. We have no baseline for how this kind of observability looks. It's a new adventure, a new journey, a new vertical for every company developing and using AI in their applications.
This is where the first advantage of using an eBPF-based sensor comes into place: we eliminate your need to know where to look when it comes to AI and how your applications interact with LLMs. The first thing that will happen when you install groundcover is that you will immediately see — without doing any integrations — how your applications are interacting with LLMs. You will see it in the way the industry has made familiar: as a conversation between an end user (in this case an application) and the LLM.
In agentic workloads, LLMs are interacted with not just by the user prompt, but also with system instructions and tool calls. groundcover will capture this entire journey of the back-and-forth between your applications and the LLM, including the underlying tool calls, so you have a clear idea of how your workloads are operating with LLMs.
Because this happens out of the box, it completely unblocks your ability to experiment as fast as possible with new models. One of the most sought-after benchmarks in every company that adopts AI is: which LLM matches my use cases in terms of cost efficiency and accuracy? Every model you want to experiment with will magically appear in groundcover as if there was already native support for it. Every new tool call, every new change in system prompt, every new augmentation to the user prompt will be immediately observed in groundcover.
The second challenge companies face when working with LLMs is: this is a new signal to me. How do I ramp up in interacting with it? This is where Ground Cover has another secret sauce, which is called Agent Mode.
In groundcover, if you press Alt+Shift+A, or just open the Agent Mode via the icon, a new sidebar will open. This sidebar is our agentic experience for the entire platform, including all the signals generated by the interactions between your applications and the LLM. Even without browsing into the AI observability experience itself, I can ask questions about how my agentic workloads are performing, and groundcover will guide me through the investigation.
I have some pre-made queries I ran just before this demo. We have a demo app called the Flower Shop — an app where a user can prompt to create a greeting for a card attached to a flower delivery. We are experimenting with multiple LLM models for this workload, and I want to check how those experiments are working.
I can just ask in the most natural language possible whether there are any reasons for failures in the Flower Shop application. I don't need to pinpoint the agent about it. The agent is capable of executing all the queries it needs to give you a fully detailed breakdown of how the Flower Shop variations are working with different models.
One of my favorites is what I like to call the "thinking out loud" mode of Agent Mode. I don't just get the answer I'm looking for — I have complete access in groundcover to the reasoning process and the steps the agent took in gathering data while it synthesized the answer. This is important because as I use the agent, I also learn as a human how to use groundcover itself, and I can also track down whether there was any need for additional data to further tune the reasoning as a second step while I'm investigating the issue.
If you really want to personalize Agent Mode to how your application works, groundcover's Agent Mode also supports skills. You can set skills and give hints to the agent on how a specific service needs to be investigated, rather than just letting it do the work.
So I get not just the underlying widgets of the different queries that were run — I also get a widget with the final answer, and essentially a root cause analysis and action items I can act on in order to remediate the issue.
This is something we see all the time with customers: people using models that are phased out from production APIs, missing permissions, budget limitations that prevent the agent from reasoning — an endless variety of use cases for debugging your applications without needing to know anything going in.
Lastly, before we move on from the demo: as I ran these queries and got back statistics about how models are being used — we are not leveraging only eBPF-driven data. We fully support the OpenTelemetry GenAI semantics. Every workload that emits instrumented traces using the GenAI semantics will also get native representation in groundcover. The idea with eBPF is not to replace OpenTelemetry in groundcover — they complement each other completely. eBPF provides an organizational compass for where you should prioritize instrumentation to get deeper business analytics.
To conclude: this is also how we use groundcover to debug our own Agent Mode. In the AI Observability page I can see the queries that were running, queries that generated errors, and the queries I used the agent for — kind of like an inception. This is how we allow organizations to stay on top of AI adoption in a very rapid pace while still giving you all the visibility you need to track down any new issues.
All this data is also queryable via traditional APIs. You can use MCP to query this data in groundcover, build dashboards, and create alerts. The data is treated as a signal you can do whatever you want with on top. And connected to the BYOC model, the inference of Agent Mode in groundcover also happens completely on the customer's premises. As part of our zero-ingestion-markup policy, groundcover introduces no markup on token costs for using Agent Mode or MCP. You pay the list price for your cloud vendor token usage.
The idea is to allow all customers to unblock AI adoption without worrying about how this might blow up in cost — unlike traditional legacy SaaS vendors that likely have a huge markup.
That's me for now. Thank you, Will. Stopping the share.
‍
DISCUSSION — Pain Points & Why AI Observability Matters
WILL ROBERTS:
That was incredible. I want to recap what we saw in the demo. There's a Flower Shop service on this demo instance — the equivalent of an application someone would build to serve their flower customers. We saw the LLM experience built into that service, hosted on some cloud. Out of the box, observability-wise, you were able to see the prompt and the response for all invocations of that LLM within the Flower service. And at the very end, not just capturing that engagement from the end-user point of view, but also seeing the agent prompt and response from our own Agent Mode in the platform — seeing exactly how we were able to triage the potential service issue highlighted within the platform itself. Is that right?
NOAM LEVY:
Yes.
WILL ROBERTS:
Amazing. Thank you so much for walking us through that. Orr, I want to turn it over to you. Can you talk a little bit about the specific pains and the "why"? We know customers are trying to harness what Noam just showed, but really don't have a great way to understand what's happening — not just within their LLMs generally but also in production.
ORR BENJAMIN:
Yeah, absolutely. The challenge of building an observability platform is ultimately about allowing customers to see across the entire stack from beginning to end, understanding every element within it. As technologies develop and as the world evolves, especially in this age of AI, it seemed like such a core build-out that we needed to double down on and focus on.
What was really interesting for me is that because we had this eBPF sensor — the ability to observe kernel-level communication without any instrumentation — it was a superpower. It was a superpower for microservice interactions and API interactions, and it became a superpower when we began to see all of these LLM calls flowing to OpenAI, Anthropic, Bedrock, Vertex, and so on. Our customers started seeing this come through as HTTP requests and got a huge amount of positive feedback about just how impressive and relevant it was for them.
As we spoke to more and more customers, we understood that even our customer base — modern technologists, companies that really know what they're doing with observability — a lot of those customers don't have any other LLM observability. They don't have any other observability for their AI workloads.
So we're able to see everything, but it's not just an HTTP request — there's meaning to LLM calls. You want to be able to show all of those different turns, the full lifecycle of the agent calling each tool and having each iteration. You want to display things like cost, build alerts around it, enrich elements around every model and every provider, and track that over time. You want to see the connection back to errors and connect it back to the service level actually calling each LLM, so you can send that back to the relevant owner.
Then — and Noam alluded to this — we could give value to our customers in a way no other observability vendor can because of our Bring Your Own Cloud back end. We don't price based on products. We give you log management, infra, APM, synthetics, RUM, session replay, and now LLM observability, AI observability, and Agent Mode — at no additional cost, no product SKU, no volume-based pricing.
Whenever there's a point in time where we can give value to customers that they maybe wouldn't be able to afford in other vendors — where they'd get to really difficult tradeoffs around what to monitor and what not to monitor — those are the really compelling points where it's clear we need to do this.
The really interesting point also clicked when we began building out our Agent Mode. We started building what we believe is one of the best-in-breed solutions for AI on top of your observability data. And what we saw is that our own needs around observability were something we could learn from and then provide to our customers. The same pains that our customers have are those that we ourselves felt: How do we track costs and keep them consistent? How do we deal with a model change we want to roll out? How do we verify results and usage? How do we track latency across the full flow and not just one individual call? All of this came to light and we doubled down and rolled it out. This world is changing so fast — I'm super excited to see what tomorrow brings.
WILL ROBERTS:
That's an important point — in building an agentic experience into our platform, we discovered a gap, especially for teams like ourselves trying to build on-prem agentic experiences that needed to track not just on-prem but also the buildout and release cadences of our own LLM application. We were dog-fooding our own product, and that's where we saw that gap and realized it was a need in the market.
ORR BENJAMIN:
Definitely. Just like with traditional observability — our ownership over Ground Cover as a mission-critical application within so many different customers makes us experts in best practices. Digging in, building out LLM observability, and going through that process allowed us to become experts within this new arena and pass those learnings on to customers. You land in the system post a two-minute installation, you're able to see everything that comes out of the sensor, and the experience is as easy as possible to leverage across every different aspect of AI.
‍
DISCUSSION — Handling Long Traces & Agent Complexity
WILL ROBERTS:
We're talking about capturing traces and tool calls that may be 50,000 lines long, and agents running in sessions for longer and longer periods of time. Noam, how should we think about the value in capturing that much information into a platform like groundcover with such a complex workflow?
NOAM LEVY:
There are a few challenges when it comes to approaching AI observability.
The first challenge is that — unlike, say, an authentication refactor, where you have tons of baseline knowledge and established best practices — with AI observability we don't have that baseline. The only way for us as an industry to navigate this is by trial and error. Best practices are constantly evolving in a super-volatile way.
So our challenge as an observability vendor is: how do we provide a strategy that enables rapid trial and error at scale?
The first condition is to solve and eliminate the cost issue. This was core to groundcover from inception, and it's only gotten worse with AI, because the amount of code being introduced into applications is now proxied by agents. Companies have zero idea how many signals they've introduced into production — and that was true before the AI revolution. This means that as long as they are bound to an ingestion-price model, they cannot adapt tooling to unblock agentic adoption. That's the first thing.
The second thing: now that you have all the data you need to accommodate rapid trial and error at high fidelity, you have to understand that engineering teams don't have time to do instrumentation. Business is always pressing for value first. If you're adapting AI to your applications without instrumentation, you're flying blind on every other platform. You have zero idea how behavior changes because there's no notion of classic errors as in traditional APIs — there are hallucinations, model switches that dramatically change behavior, sessions that can be an hour long.
We need to decouple the ability to have visibility into this journey from assuming that engineers know where to look. That is achieved by the eBPF model. It's similar to how the security industry approaches endpoint security: companies don't trust engineers not to click on phishing links — they install endpoint security. The same philosophy applies here. We want you to understand how your applications behave after a huge change, without relying on the assumption that engineers put the signals in the right places in the first place.
ORR BENJAMIN:
I'll add a point or two. The pain around a conversation with thousands of different turns and LLM calls is much the same pain as in traditional observability — just on steroids. You now have more data, more variation, and things that are non-binary in nature: is this an error? Is this a problem? It may just be a slight deviation from the past. It's nondeterministic.
Our additional layer of Agent Mode on top is a big piece of what's different here. Something that's difficult to look at from a raw perspective becomes much more manageable when an agent is able to look through all of it, identify variations or things that have changed, and surface the real signals that allow you to move forward toward something meaningful.
It's a lot like it was in the past — the complexity has just grown, and the tooling needs to advance as well.
‍
Q&A
WILL ROBERTS:
Let's get to some questions.
Q: Is groundcover meant to only observe agentic apps deployed to a cloud
platform, or can it be used to detect shadow AI apps running locally?
ORR BENJAMIN:
You can ultimately ship data from wherever you want. groundcover needs our sensor installed to use the power of eBPF, but we're also able to receive any and all kinds of traces, requests, and telemetries that come from outside. We support the wide majority of telemetries you'd need to bring in.
Q: Is AI observability a separate SKU with groundcover?
NOAM LEVY:
No. It's completely bundled into the single SKU of groundcover. The only pillar in our licensing fee is the number of sensors you license to deploy on your clusters and containerized environments. You get all the features in Ground Cover: unlimited seats, dedicated support, SSO, all access controls, unlimited usage of any pillar. There is no pay-per-query or pay-per-usage. It's all bundled and encapsulated into your compute footprint — the only licensing dimension in groundcover.
Q: Does this observe all LLM models, or only from specific model providers?
ORR BENJAMIN:
This is extremely wide in terms of our model coverage and provider support. We cover the entire universe. As more models roll in, we see them as raw requests, and that's expanded and built into the system. From day one after installation, you see the entire universe.
Q: Is there a way to get started?
NOAM (via chat):
Yes — play.groundcover.com is the place where you can try it today. You can see what the traces look like and exactly what is observable in the groundcover platform. The lift to get started is incredibly low.
CLOSING
WILL ROBERTS:
If you've made it this far, you've well earned your access to the Gartner report "AI Will Unlock Observability at Scale." Please capture the screen — we will also send out a link to the slides for attendees so you get access to that resource.
I want to thank Noam and Or — Noam, thanks for the amazing demo; Orr, thanks for staying up late in Tel Aviv. This was an incredible event.
ORR BENJAMIN:
My pleasure. Thank you, Will, so much for hosting and orchestrating this webinar, and thank you to the entire audience who attended today.
WILL ROBERTS:
Folks, thanks so much. Please check back to this page for the recording and all resources.
That's it. Thanks, guys.
END OF TRANSCRIPT

‍