Usable uses MCP-first access to scale observability
Customer Story

Usable uses MCP-first access to scale observability

William Roberts
August 12, 2026
 |  
7
min read
Usable uses MCP-first access to scale observability

1

Meeting needed to get full data visibility

20%

The cost increase on a 200% increase in log/trace volume during monthly spike

0

Minutes spent debugging incidents manually without inputs from MCP

“We’re using the MCP server (on groundcover) heavily. We are almost never debugging, ourselves, anymore.”

Julius Á Rógvi Biskopstø, Co-Founder and CTO, Usable

The Stakes

As a leading consultancy, Usable (formerly Flowcore) specializes in providing governed organizational memory for AI tools. By delivering high-quality infrastructure, they enable customer-facing assistants, developers, and DevOps teams to utilize an AI agent backed by persistent, shared knowledge. This allows Usable’s customers to dedicate their energy to core product development rather than constructing their own knowledge infrastructure. They owe their customers reliable services and answers whenever they need them, so they chose groundcover.

“We’re using the MCP server (on groundcover) heavily. We are almost never debugging, ourselves, anymore.”

The Challenge

When the company launched as Flowcore (now known as Usable) in January 2023, its initial observability stack included Datadog for logs and traces. By May, as customers began using the cluster and the team dogfooded the Flowcore platform, the economics of volume-based observability were already becoming a constraint. As CTO & co-founder Julius Biskopsto explains it “as soon as we started the company, and got real data in, we started to see the throughput and realized that volume-based output was going to blow up the budget right away.” 

Flowcore was processing high-throughput customer streams representing approximately 200,000 IoT devices. At that scale, a newly deployed service — or a stray debug, info, or error log emitted for every event — could materially affect the monthly observability bill. The team found itself limiting logs and traces to control costs rather than retaining the operational context its engineers needed to understand and troubleshoot the platform. “It was getting too expensive without even seeing any benefits. We were spending time optimizing what we logged instead of engineering our own software.” That experience led Flowcore to move its primary observability workloads to groundcover.

Agents are also their product’s consumers. They know they can expect significant data growth as they expand their services with more agents.  “When it’s humans that look at the logs, and you add a lot of logs, you don’t necessarily get benefits. When you use AI, you actually benefit from a lot of logs. That’s where volume-based pricing became problematic, to say the least.” 

So how do you design an observability stack that meets the demands of agent scale without spending significant time adding instrumentation, optimizing your logging, and still get the immense benefit of rich context for your agents? They rolled out an observability platform deployed to their own cloud

“We had a spike in May where our log/trace volume went up 2-2.5X and our costs on groundcover only went up to something close to but less than 20%. I’ve been at other companies where an accidental feature flag may have resulted in an unexpected $10K observability bill in one month.”

Julius Biskopsto

The Implementation

The Usable team operates Kubernetes environments across Microsoft Azure and AWS, including customer clusters enrolled in groundcover. These environments process and move high-throughput customer data, some of which is sensitive. Usable therefore wanted an observability architecture that could run within the relevant cloud environments and provide greater control over where telemetry was processed and stored, rather than requiring all observability data to be shipped to a vendor-managed, multi-tenant SaaS data plane.

The groundcover eBPF sensor provided immediate baseline network and service visibility across these Kubernetes environments without requiring custom application-code instrumentation for every service. Where Usable’s services already emitted application telemetry through OpenTelemetry, groundcover combined that application context with infrastructure-level signals collected from the groundcover eBPF sensor.

For Usable, groundcover’s MCP server has fundamentally changed who, or what, does the debugging. “We are almost never debugging ourselves anymore,” says Julius.

Instead, investigations are predominantly agent-led. When an incident occurs, the team can hand it to a remote agent that uses groundcover via MCP to investigate the system directly. The agent queries groundcover and Kubernetes, correlates telemetry with prior investigations stored in Usable, identifies the likely root cause, proposes and implements a fix, and submits a pull request.

What was once a hands-on debugging workflow for an engineer can now run largely autonomously, with groundcover providing the observability context agents need to reason about production. Engineers move into a supervisory role, reviewing and approving the resulting code, and stepping into the investigation themselves only when a case is ambiguous, privileged, or high-risk.

The Delta & The Proof 

The delta: groundcover solved Usable’s problem of cumbersome instrumentation and unmanageable expense from volume-based pricing. “We didn’t have to instrument… and with eBPF sensors, you get it (telemetry data) right away.” 

The implication behind this new deployment and commercial model for Usable was that they no longer suffered the pain of expensive and unpredictable volume-based pricing. Observability became a dependable operational capability that Usable could automate and standardize. Engineers increasingly supervise the proposed outcome rather than manually gathering telemetry, correlating evidence, and implementing the initial fix. 

The proof: Julius said “I think volume-based pricing is obsolete at this point” when asked about a theoretical scenario in which he had to estimate how his team would change their observability in response to the growth of metrics, logging, and traces in their current era of agentic-focused workloads. “We had a spike in May where our log/trace volume went up 2-2.5X and our costs on groundcover only went up to something close to but less than 20%. I’ve been at other companies where an accidental feature flag may have resulted in an unexpected $10K observability bill in one month.” 

Besides the ability to absorb the unexpected spikes in demand for his observability stack, groundcover also gave Usable peace of mind when it comes to planning services in the future. Each new service shows some footprint in their cloud environment, without any instrumentation, and there are few risks (if any) when it comes to building applications that have to respond quickly to scale.

“I think volume-based pricing is obsolete at this point”

Julius Biskopsto

“It’s difficult to predict where you’ll be three months from now. Say you launch a service and it suddenly goes viral. With volume-based observability pricing, that kind of growth can turn into a cost problem almost overnight. The curve for going viral today is so much steeper than it used to be. If your pricing scales directly with that volume, you can get screwed pretty quickly.”

The Usable team spends less time watching the meter, less time building the metered functions into their applications, and can automatically health-check their systems and agents. 

Why Usable Chose groundcover

Usable originally evaluated dozens of observability solutions in 2023 to replace DataDog. According to Usable, New Relic, Honeycomb, Dynatrace, and Instana were too complex to integrate into their distributed system, required extensive configuration to gain meaningful insights, and offered unpredictable pricing. That’s why they ended up choosing groundcover in the first place. They’ve since become powerful users of the groundcover MCP server, and are early adopters of many new features in the groundcover platform. 

Usable was so convinced of the value delivered by groundcover that they sold on behalf of groundcover to one of their own customers. Their customer wanted to switch observability vendors from Datadog to open source to manage the costs of the experience. In their customer’s evaluation process they ran a POC with groundcover that ran in parallel against OSS Grafana. “We agreed with them that it would be easy to evaluate both since groundcover is quick to deploy. It was still a surprise how soon after start they were able to get groundcover running. But what they really did not expect was that even simple Grafana services in parallel with the POC were running into limits immediately while groundcover was handling traffic with ease. Because it was Grafana, all the dashboarding work they worked on in the parallel POC was painless to import to groundcover. It was a no-brainer for them - they didn’t even complete the POC with Grafana.”

When asked to describe his company’s experience with groundcover, Julius Biskopsto opined on the adoption speed as the thing that comes first to mind, “We were up and running in the first meeting we had. The first sales meeting. That’s how fast it was to get data in. You get it right away.” 

Are you ready to see what full-stack and unmetered observability can look like for your team in as few as 30 minutes?

Book a demo to see how groundcover delivers observability in your own cloud - without per-query or spiking unpredictable pricing.

William Roberts

8 min read |
Published on: August 12, 2026

Latest stories

Explore more stories

Sign up for Updates

Keep up with all things cloud-native observability.

We care about data. Check out our privacy policy.

Observability
for what comes next.

Start in minutes. No migrations. No data leaving your infrastructure. No surprises on the bill.