They Told Me the Market Is Saturated. That's Exactly Why I Co-Founded DataAgent.

The short version is already out: I've joined DataAgent as Co-founder & CTO, and it was the fastest yes I've ever said. This is the long version.

When people heard what I was planning to do, they asked:

• Isn't the market saturated?
• Won't the big players eat you alive?
• There are already so many startups in this space.
• Aren't you tired? After all, this is your third startup.

That's exactly what I heard from most of the investors too. Here's what I told them.

Saturated market? That's exactly the opportunity

What exists today in the SRE space is a kind of market failure. I have never come across a situation where almost everyone I talked to is frustrated with how things work. Everyone collects everything that moves into one central place first, and then pays a premium for that collection, on the way in, on the way out, and on storage. And most of that data is never read. Most of the time it has little to no value, it just sits there in case something breaks.

On top of that, we pay again for AI agents to help find the needle in that haystack. In short, we pay extra to solve a problem that never should have existed in the first place!

Everyone I talked to agrees with the problem. Just as many are skeptical there's a real solution. Not one person was happy with how things stand today, and everyone is unhappy about the rising costs. So in my eyes this isn't a saturated market. It's exactly a market opportunity.

But aren't there already so many startups in this space?

True. That crowded landscape is clear proof that the problem is real and that observability costs keep soaring. However, most existing solutions simply use AI to optimize legacy processes without questioning why those processes existed in the first place. Why should AI agents inherit constraints designed back when humans had to manually manage everything?

Look at what those startups are building and a second pattern shows up: almost all of them are building an assistant. An agent that investigates, summarizes, and recommends, then hands the work back to you. But assisted doesn't grow into autonomous by adding features, the same way assisted driving never became self-driving. A recommendation at 3 a.m. is still a wake-up call, and now you also have to decode it. What customers are actually asking for is a fixer. Even the industry's biggest vendor has said it out loud: the future of observability is not just observing, it's fixing.

A fixer is not an assistant with one more feature. It inverts the order of operations: stabilize with a verified fix first, then run the deep root-cause analysis in the background, after the system is healthy. That inversion is what remediation-first means, and you cannot bolt it onto a tool that was built to watch. You have to build for it from day one.

Consider the traditional divide between SRE, DevOps, and QA. All three ultimately aim for the same outcome: service reliability, availability, and quality. Why keep them in separate silos?

Likewise, do we really need to ship massive volumes of raw infrastructure telemetry to central platforms just to analyze it? Is that data even sufficiently contextualized once it arrives, or are we just hoarding noise?

While up to 80% of SRE issues are recurring, traditional automation falls short. Would you trust an agent with 90% accuracy when missing 10% of critical incidents could trigger a major outage? In reality, current market solutions hover closer to 50% precision, hardly enough for real operational trust.

Furthermore, cost reduction shouldn't be an afterthought relegated solely to FinOps. True savings stem from redesigning the paradigm from the ground up, bringing engineering, operations, and financial optimization together into a unified workflow.

This is why we built DataAgent remediation-first, and why we started narrow instead of broad. Every other player in this space raced to integrate with everything that moves, every cloud, every stack, on day one, because that's what a dashboard needs: one pane of glass showing all of it. But an agent that acts doesn't need breadth. It needs to actually understand what it's looking at, and depth and breadth conflict with each other, definitely in the short term. So we picked Kubernetes and AWS first, on purpose, and went deep enough there to be trusted with real fixes, instead of shallow everywhere and trusted with none.

That depth is what makes fixing something safely possible at all. A metric spiking or an error rate climbing is a symptom, not a cause, and a system that only watches telemetry can tell you something is wrong without ever telling you why. The real signal is drift: what actually changed right before the fault. A config edit. A permission revoked. A deployment that shifted. A dependency that quietly updated. Finding that means being close enough to the platform to see the change itself, not just its downstream effect on a graph five minutes later. That's what real depth buys you in Kubernetes and AWS specifically: not a river of raw telemetry from fifty integrations, but the actual history of what changed, which is what separates the fault from its symptoms.

That same depth is also what makes right-sizing your observability footprint possible. Not your compute, your telemetry: what gets ingested, at what fidelity, and for how long you keep it. And it isn't a separate feature bolted on. It's the other side of the same understanding. Once an agent knows precisely what evidence it needs to diagnose and fix a given workload safely, it also knows, by the same logic, what it never needed to collect in the first place. That's the "collect everything, just in case" problem from the top of this post, solved by the same mechanism that earns the agent the right to act, not by a second, unrelated cost tool.

One choice, going deep instead of broad. Two outcomes: incidents get fixed instead of just flagged, and you stop paying to hoard data nobody was ever going to read.

And what about doing it for the third time (at my age)?

If anything, today I feel like everything I've learned over the years, in automation, in big data, and more recently in AI, was waiting for exactly this moment. So could I really sit on the sidelines, when the alternative was building something new with the potential to change an entire industry?

Part of that experience is also knowing how to lead a change like this without throwing away everything you've already built, how to do it gradually so the risk stays small. That only comes from someone who has actually led changes like this before, technical and organizational, through real successes, but just as importantly through real failures, and who comes to it with the humility that takes, to help you succeed where so many others have failed.

I know some of this sounds like slogans. But anyone who knows me knows I chose every word here carefully, and behind every sentence there's enough substance to back it up, some of it already on the blog, in the podcast, and in the training series. I'm happy to go deeper with anyone who wants to be part of this journey. Because that's what I'm actually looking for: partners, not customers.

If that's you, reach out.

References

• The cost problem. The cost teardown behind the collect-everything argument: the same environment priced across backends; premium tools landed at 5 to 9 times a self-hosted floor.
• Assistants vs a fixer. The industry is conceding the destination, and why assisted does not grow into autonomous: Your agent wrote it. So who runs it? and the Reversim episode it came from.
• The accuracy numbers. Every frontier model scored below 50% on Kubernetes root-cause tasks in the independent ITBench evaluation by IBM and Artificial Analysis.
• Going deeper. Build the loop yourself with the free, open-source autonomous SRE training series, hear the practitioners on The Circuit Breaker podcast, or start from the blog.