Introducing Minimum Viable Instrumentation

In 2026, companies generate code with coding agents and operate their systems with AI SRE agents. There are agents on both sides of the equation now: one writes the code, the other runs it. The engineers who direct those coding agents read less of the code than ever. When something breaks in production, the first responder is increasingly an agent connected to the observability backend, investigating before anyone is paged.

What connects the agent that writes the code with the agent that runs it? Telemetry. People no longer read every line of code, but they, and their agents, can look at the telemetry. It has become the single source of truth about what is actually happening in production. Telemetry used to be something we looked at. Now it is the source of truth that AI acts on, so it has to be top-notch.

That is why today we are launching Minimum Viable Instrumentation (MVI) in OllyGarden Rose, together with the news that OllyGarden has raised $4m from Next Frontier Capital, Grand Ventures, ACTAI, DIG Ventures, Datadog, Grafana Labs, and Dash0. You can read the details in our press release. This post is about the product, and about why the old way of getting telemetry does not work anymore.

High volume, low quality no longer works

For years, the fastest path to telemetry was the wide net. Attach the Java agent, enable eBPF-based instrumentation, add instrumentation libraries, and data shows up for every request, query, and DNS lookup. When all you have is darkness, a floodlight is welcome. But these tools cannot know what is important to your business, so they capture everything. That is high-volume, low-quality telemetry.

Here is what that looks like in practice. At one company we work with, a single batch job that ran for 59.7 seconds produced 633,718 spans through the Java agent. More than 90% of them came from the database layer. About 19% were orphaned from their trace. Not one span described the business operation the job performed. Our plan for the same job, built around its real boundaries, needs six spans.

This was already expensive. Observability is the second largest infrastructure expense after compute, and in our audits we keep finding the same waste: 82% log duplication, 63% trace waste, and credentials or personal data leaking into telemetry at five out of six companies. In 2026, the problem compounds. Coding agents write most of the new instrumentation that ships to production, at machine speed, and they were trained on the bad patterns of the past. If agents help us write ten times more code, a wide-net approach gives us ten times more telemetry to store, query, and pay for. That volume of data was already hard to justify yesterday. It is worse tomorrow.

The cost does not stop at the bill. When one agent writes bad telemetry and another agent reads it, nobody really knows what is happening in production. AI SRE agents take every signal at face value. Noisy, duplicated, or misleading telemetry makes them spend more time and more tokens to reach an answer, and sometimes they confidently fix the wrong problem. High-volume, low-quality telemetry costs more money and more resources in 2026, not less.

Low volume, high quality, at 2026 speed

The alternative has always been manual instrumentation: deciding in the code which operations deserve a span, which attributes they carry, and how context flows between services. It produces low-volume, high-quality telemetry, including the business context no library can guess, such as the installation ID that lets you pull every trace for the one customer whose install failed. Its problem was never quality. It was speed and scale. It takes OpenTelemetry expertise, and most organizations have only a handful of people with it, who cannot review every repository.

Plain coding agents do not solve this on their own. When we tested them, they suggested outdated SDK versions and APIs, struggled with the SDK setup, and broke context propagation between services. But agents guided by real expertise change the equation. Today we can instrument source code with the same speed and effort a wide-net agent needed a few years ago, at a quality that is far better. If teams are going to write ten times more code, they cannot afford ten times more telemetry. They need low volume and high quality, delivered at the speed and scale of 2026.

What Minimum Viable Instrumentation means

Minimum Viable Instrumentation is the smallest set of telemetry that gives a team, and its agents, a foundation it can operate on. By default, that means the boundaries of a service are instrumented: the requests it serves, the outbound calls it makes to databases, queues, and other services, and the context that connects them. On top of that come the few business attributes that turn a generic trace into one you can search for during an incident. Rose goes deeper only where you ask it to.

The word "minimum" is deliberate. More instrumentation is not better instrumentation. The goal is the telemetry you need, and nothing you don't.

How Rose establishes the baseline

Until now, Rose reviewed the instrumentation you already had and suggested how to improve it. With MVI, Rose also finds the parts of your code that production cannot see, and gives you a path to an instrumentation baseline.

Rose does not start by adding an SDK. It starts by reading the code base and writing an instrumentation plan. The plan identifies the service boundaries and the external systems the code connects to, and decides which of those boundaries should be instrumented. Knowing which boundaries are instrumented is the core of MVI.

Rose then sets up the OpenTelemetry SDK using declarative configuration, so the setup lives in a configuration file instead of language-specific code spread across the application. It implements the plan with targeted manual instrumentation, and tunes instrumentation libraries where they remain the better starting point, for example by turning off duplicate database spans or DNS resolution spans that nobody will ever query.

Along the way, Rose adds business context. In one of our demo applications, a NestJS service with two OAuth sign-in flows, one for Apple and one for Google, the default instrumentation would not have separated them. Rose added a provider attribute to each flow, so a person or an agent chasing a sign-in issue can filter by provider and see whether only one of them is failing.

Before it opens a pull request, Rose verifies its work. When it can start the application, it runs an OpenTelemetry Collector locally and sends sample telemetry to it, never to a remote backend, to confirm the instrumentation actually produces data. The result arrives as a pull request with the plan, the configuration, and the code changes, all plain OpenTelemetry in your own repository. Your engineers review it and decide what merges, as with every other change Rose proposes.

An OpenTelemetry expert in every repository

MVI completes the loop Rose started. For services with instrumentation, Rose reviews and improves what is there, and catches the regressions coding agents introduce. For services without it, Rose now establishes the baseline. Together, that puts an OpenTelemetry expert in every team, every repository, and every pull request, watching around the clock, even in organizations with only a handful of observability engineers.

This works on top of the observability backend you already run. Better telemetry makes every backend more valuable, and it gives your AI SRE agents a source of truth they can actually trust.

If you want to see the approach before you try it, our Minimum Viable Instrumentation with AI Agents session walks through Rose instrumenting an uninstrumented application, step by step. If you prefer to work with your own coding agent, much of the knowledge behind Rose is public: the OpenTelemetry Agent Skills give any agent current, token-efficient OpenTelemetry references, and the OllyGarden skills carry our opinions on instrumentation planning, declarative configuration, and manual instrumentation. See our Agent Skills page for how to install them.

Availability

Minimum Viable Instrumentation is available today to all existing OllyGarden enterprise customers, with a free trial available to new customers. Talk to us to start, or connect Rose to your repositories and see what it finds in the instrumentation you already have.

To our investors, our customers, and the OpenTelemetry community: thank you. Coding agents write the code, and AI SRE agents operate it. Our job is to make sure the telemetry between them is something both can trust.