OllyGarden's telemetry-cutting Rose agent now recommends what teams should instrument

The engineer who opens Rose on Monday will find two kinds of suggestion in one queue. The older kind names logs, traces and metrics that are not worth collecting or storing ^[4]. The new kind names places where no instrumentation exists and says what to add ^[2]. Applying the first keeps irrelevant data from reaching the observability backend at all ^[5]. Applying the second creates telemetry that was not being sent before ^[2].

The buyer is the team that owns both the OpenTelemetry setup and the invoice. Founder Juraci Paixão Kröhling said the goal is to help teams calibrate the exact amount of telemetry they need to observe an environment and reduce the noise that hides meaningful signals ^[6]. The new capability, called Minimum Viable Instrumentation, is meant to identify the most relevant sources to instrument with OpenTelemetry, the open-source framework advanced under the Cloud Native Computing Foundation ^[3]. It ships after OllyGarden raised a further $4 million ^[1].

Teams tell themselves the payoff is an AI agent that reasons better because it sees cleaner data. The devops.com report makes that case, arguing that observability platforms will feed telemetry to agents and that shrinking what they see is how teams get better outcomes at lower cost ^[10]. What the product does today is smaller and easier to check. Rose evaluates the telemetry being collected, identifies issues and generates source-level fixes that the team then applies ^[5]. The same report says agents are probabilistic and still need close monitoring and verification at almost every step of a DevOps workflow ^[7].

OllyGarden's 85% figure needs the same care. The company says that over the past year it helped teams identify opportunities to reduce volume across up to 85% of their logs ^[8]. The figure is a ceiling on the share of logs where a cut was proposed. The report does not include a measured before-and-after for log volume or for agent decisions ^[8][10]. The pressure behind the pitch is plain in devops.com's account: telemetry volume keeps rising as AI workloads are deployed, and aggregating it is becoming cost-prohibitive for many teams ^[9].

I would switch on the cut side first and send the add side through its own approval path. The tradeoff is that uninstrumented services are where an on-call engineer, or an agent, has the least to go on, so holding back additions protects the bill and leaves those gaps open longer. A month in, net ingested volume will show whether the two halves of the tool are cancelling each other out.

Each Rose suggestion can be sorted on two axes. One is whether it removes telemetry or adds it. The other is whether anyone has queried that signal, or needed it during an incident, in the last quarter. Cuts to signals nobody reads can go through quickly, and they are where the 85% claim gets tested against your own logs. A cut to a signal someone does read goes to whoever owns that dashboard or alert. An addition on a service that has already had an incident nobody could trace is the case MVI was built for. Additions with no incident behind them wait until someone can name the question the new data would answer.