Tag: Telemetry Optimization

I have been covering observability for a long time. Long enough to remember when we called it APM. Long enough to have watched the conversations shift from “can we capture everything?” to “should we capture everything?” to “we absolutely cannot afford to store everything, so now what?”

We never fully answered that last question. We just kept buying more storage and paying bigger observability bills and telling ourselves we’d deal with it later.

Later is here.

I sat down recently with Ronit Belson and Erez Rusovsky, two of the three co-founders of a company called Sawmills. Ronit is CEO, Erez is CPO, and their third co-founder, Amir Jacobi, came out of New Relic, where he ran engineering for AI Ops. These are not people who woke up one morning and decided to start a startup. Ronit has been CEO for companies that were acquired three times — once by Splunk, once by Tricentis, and once by CloudBees. Erez built and sold a feature flagging company before this. They have been around this problem for years, and they finally got frustrated enough to do something about it.

The problem they are solving is simpler to describe than it is to fix. The data that feeds your observability tools is out of control. Too much of it, low quality, unmanaged, and growing faster than anyone budgeted for. When they started building Sawmills two years ago, this was already a serious pain point. Costs were climbing. Signal-to-noise was degrading. Teams were drowning in telemetry that told them less and less while costing more and more.

That was before AI coding agents became the norm.

Think about what has happened in the last twelve months. Developers are not writing most of the code anymore. Agents are. Cursor, GitHub Copilot, and a dozen other tools are generating application code at a pace no human team could match. That is mostly great. What is not great is that instrumentation — the telemetry, the logs, the metrics, the traces that feed your observability stack — is an afterthought to those agents. Nobody told the agent your logging standards. Nobody reviewed whether it is sending the right metrics. Nobody checked if the traces it generates are even useful. The agent shipped the feature and moved on.

The result is that the garbage-in problem the industry has always had just got turbocharged. More code, more telemetry, worse quality, higher cost. Your Datadog bill does not care whether the data it ingested was useful. It charges by volume.

Sawmills is positioning itself as the first Agentic Telemetry Management Platform. That is a mouthful, but the idea is straightforward: Sit between your code and your observability tools, optimize what gets sent, kill the noise, and do it continuously with an agent that learns from what it sees in production. They are not replacing Datadog or New Relic or Grafana. They are making the data that those tools receive worth paying for.

The agentic piece matters more than the telemetry piece, if I am being direct. The reason this problem has never been truly solved is that it requires continuous attention. You cannot audit your telemetry pipeline once a quarter and call it done. The codebase changes daily. New services spin up. New agents write new instrumentation. The noise compounds. What Sawmills is building — what they launched — is a system that watches the pipeline the way a senior SRE would watch it if that SRE never slept, never had meetings, and never got pulled onto the incident that just blew up.

Erez made a point during our conversation that stuck with me. There is still a human in the loop. The agent identifies issues, proposes changes, flags things for review, and follows up with the DevOps or SRE team when something needs a sign-off. That is the right design. Full autonomy in a production telemetry pipeline is a bad idea. Autonomous with human checkpoints is how you actually get adoption.

They are also doing something I find genuinely interesting from an architectural standpoint. They are moving the instrumentation problem left. Not just optimizing what gets sent to your observability backend, but reviewing the code at the CI stage to understand whether the telemetry being written is correct in the first place. Close the loop: See what production is actually generating, feed that back into how the code is instrumented, catch the problems before they ship. That is a different problem than AIOps ever tried to solve. It is observability quality control at the source.

For the DevOps practitioner reading this: You know this work. You have been meaning to do it. It lives on the list of things that are important but never urgent enough to get prioritized over the incident queue. Auditing telemetry pipelines, cleaning up noisy instrumentation, enforcing logging standards across a codebase where half the code was written by an AI agent that had no idea what your standards are. It is unglamorous and it is expensive to ignore.

The observability vendors are not going to solve this for you. Their incentive is the opposite. They make more money when you send more data. The optimization problem is yours, not theirs.

What Sawmills is betting is that this problem is now big enough, and painful enough, and expensive enough, that teams will stop accepting it as background noise and start treating it as something worth fixing. Based on what I heard from Ronit and Erez, and based on what I see in my own conversations with engineering and DevOps leaders, that bet is looking pretty solid.

Garbage in, garbage out. That has been true since before most of us were in this industry. The only thing that changes is how fast the garbage arrives. Right now, with agents writing code around the clock, it is arriving very fast indeed.

You can keep paying for it, or you can get control of it. Those are the options.

Check them out at sawmills.ai.