Observability spent most of the past decade as a post-production discipline, catching outages and cutting the time engineers need to find a root cause. That focus is shifting as agentic AI systems move into the software development lifecycle, pulling production context earlier into coding, testing, and deployment work.

That shift is helping to fuel growing demand for observability vendor Groundcover, which this week announced a $100 million Series C round. The round was led by One Peak and included Morgan Stanley Expansion Capital, Zeev Ventures, Angular Ventures, Heavybit, and Jibe. Groundcover’s total funding now stands at $160 million.

Groundcover builds observability technology on the open-source eBPF and OpenTelemetry technologies. Founded in 2021, the company raised $35 million in a Series B round in April 2025 and has spent the time since extending that foundation to cover AI agents and the tools those agents call in production.

“I think what is happening to observability right now is fascinating,” Groundcover CEO and co-founder Shahar Azulay said.

What eBPF does and why it matters more now

eBPF, short for extended Berkeley Packet Filter, is a Linux kernel technology that lets code run safely inside the kernel without a custom kernel module. It has long been used for network monitoring. Groundcover uses eBPF to watch application and infrastructure activity without requiring a developer to instrument each service by hand.

That approach removes a step most observability vendors still require. “You didn’t have to have the developer instrument an SDK, change their code base, and so on,” Azulay explained.

The same property is becoming useful for a different reason now. Engineering teams are adopting new AI tools fast enough that they lose track of what is actually running in their own environment, Azulay said. He compared the gap to the visibility problems teams dealt with roughly a decade ago, before observability tooling matured. eBPF operates below the application layer rather than depending on code a developer wrote, so Groundcover can still see workflows nobody thought to instrument.

“eBPF is kind of that security net of even if you didn’t instrument, even if you’re not in full control, you’re gonna know which agentic workflows are running in production, which models are using, which vendors they’re using, and so on,” Azulay said.

eBPF was originally developed to improve packet filtering and network tracing in Linux. Over time, its use cases expanded to security, performance troubleshooting, and observability. Because eBPF programs run in a restricted virtual machine inside the kernel, they are safe to load and execute without adding new kernel modules. This makes it possible to collect fine-grained data from any process on a host, even when the process was not configured to emit telemetry.

OpenTelemetry, by contrast, is a vendor-neutral standard for generating, collecting, and exporting telemetry data such as traces, metrics, and logs. Many observability platforms rely on OpenTelemetry collectors and agents to normalize data. Groundcover combines OpenTelemetry with eBPF to reduce manual instrumentation while still fitting into the broader observability ecosystem.

How agentic workflows are breaking distributed tracing

Distributed tracing follows a request as it moves across services so engineers can see where time is spent and where something broke. It has always relied on a predictable number of hops, the kind of path an engineer could trace by hand, such as a cache calling a database.

Azulay said that assumption breaks down once agents enter the picture, since a single agent session can generate a large number of tool calls and internal model calls with no fixed pattern. “With LLMs and agentic workflows, this is becoming very complicated,” Azulay said.

Teams now also track token usage and hallucination rates alongside latency and error rate, Azulay said. Traces can contain a customer’s actual prompt instead of only structured request data, which raises privacy questions. He does not consider the result a variant of application performance monitoring. “It’s not going to be the same product,” he said. “AI observability is not exactly APM.”

Azulay tied that shift back to Groundcover’s own architecture. Because the platform stores telemetry inside the customer’s own cloud environment rather than a shared vendor backend, he said it is built to hold the larger, more sensitive telemetry volumes agentic workloads produce without shipping that data to a third party.

“I think people are expected to save more telemetry, and save more telemetry more privately,” Azulay said.

Traditional tracing instruments assume a request graph with finite boundaries. An engineer can identify every service in the path by looking at a trace. Agentic AI systems make these boundaries fluid. An agent can decide at runtime which tools to invoke, which vector stores to query, which APIs to call, and how many times to revise its output. That creates a trace that cannot be fully described in advance.

There is also a semantic problem. A typical trace is built around service names, operation names, and timing. An AI workflow may need to be understood in terms of prompts, model responses, tool call arguments, and context windows. Those elements are difficult to capture with standard span attributes and require new conventions for representing AI activity.

Agent Mode and the rise of MCP

Groundcover isn’t just optimizing its platform for the needs of modern agentic AI activity. The company is also using AI to improve user experience.

Agent Mode is Groundcover’s built-in AI assistant for engineers, letting them ask questions about their systems, build dashboards, and troubleshoot problems in logs and traces without writing queries by hand. Groundcover has also built a Model Context Protocol (MCP) integration that connects Agent Mode to coding agents and workflow tools including Linear, letting engineers and AI systems pass context back and forth during an incident.

Azulay said adoption of MCP integration has moved faster than the company expected. Customers use the integration differently depending on how far along they are in adopting AI tools, according to Azulay. Some ask questions through it instead of opening the Groundcover dashboard, while others use it to write a fix directly. He framed the pattern as an industry trend rather than a product win specific to Groundcover.

“People are basically starting to build their autonomous software development structure,” he said.

Model Context Protocol is an open standard aimed at making it easier for AI assistants to interact with external data sources and tools. MCP defines a common way for models to expose capabilities and for applications to invoke them. The protocol gained attention after AI-assisted coding tools began to require access to project context, documentation, issue trackers, and runtime telemetry.

For observability platforms, MCP can turn telemetry into a direct input for AI agents rather than a destination for human querying. An engineer can point an assistant at an incident, let it retrieve relevant traces, logs, and metrics, and then take action based on what it finds. Groundcover’s integration with Linear is one example of this pattern: an AI tool can pull incident context from an observability system and use it to update tickets or coordinate a response.

Groundcover at a glance

• Founded: 2021
• Total funding: $160 million
• Latest round: $100 million Series C, led by One Peak
• Other investors: Morgan Stanley Expansion Capital, Zeev Ventures, Angular Ventures, Heavybit, Jibe
• Headquarters: Tel Aviv, Israel
• CEO: Shahar Azulay
• What they do: Observability technology built on eBPF and OpenTelemetry

Groundcover says the new funding will be used to expand its AI observability features, grow its engineering team, and deepen support for production AI workloads. The company also plans to extend Agent Mode and its MCP integration as enterprise teams build more autonomous development workflows around AI assistants.

Source: Network World News