Today, Tero is joining Cribl to help build observability for the AI era. Engineers now run production alongside AI agents, and those agents are becoming primary consumers of the same data. Both need the data underneath every tool, the context to make sense of it, and a foundation that customers control, not another set of disconnected products. Cribl is the place to build it.
For the past decade, I’ve been working on the same problem. How do engineers take control of their telemetry, and how do they know which of it actually matters? That started with Vector, the open source observability pipeline we built at Timber.
The problem I keep coming back to
We built Vector because moving data from where it’s produced to where it’s needed was much harder than it should have been. Teams were tied to whatever collector their vendor shipped, and changing direction meant rebuilding pipelines. Vector gave engineers a fast, open way to collect, transform, and route their data wherever they wanted. Seeing how many teams adopted it, and the community that grew up around it, is still one of the things I’m proudest of.
But controlling where data goes didn’t tell anyone which of it was worth keeping, or what it meant. Teams could send their data anywhere, but they were still paying to store and search huge volumes of it that nobody ever looked at.
What Tero taught us
At Tero, we started by asking engineering teams how much of their telemetry is waste. The answer was almost always more than they expected. We built technology to measure it, pinpoint low-value data across observability tools, and fix it in the tools engineers already use.
The bigger surprise was why teams couldn’t tell on their own. Knowing which data matters means knowing how services connect, what changed, and which signals engineers actually reach for during an incident. Almost none of that was written down. It lived in engineers’ heads. That works when a person is running the investigation, but it breaks down when an agent is.
Observability wasn’t built for agents
Observability was built to help people understand production. Products collected data and presented it through dashboards and search. Engineers supplied the context themselves. They knew how the system fit together, what had changed, and where to look.
Those products also became how observability is packaged and sold. APM, log management, infrastructure monitoring, and real user monitoring each come as a separate product, even though underneath they’re largely built on the same data. Engineers bridged the gaps, jumping between tools and stitching the story together.
Now picture an agent chasing a latency spike at 2 a.m. It starts with a symptom, then needs the deploy that went out an hour earlier, the code change behind it, and the downstream service that started timing out. The problem decides where the investigation goes, but the products you bought decide what evidence it can reach.
Where observability goes next
The data, and the understanding of production built from it, need to stand on their own, independent of any one product. Your data should be accessible wherever it makes sense to keep it, and usable for whatever the work requires, not divided up by product line. Your understanding of production should be maintained once and shared by every engineer and agent.
That doesn’t mean host monitoring, APM, or the other experiences engineers depend on go away. Engineers still need excellent observability, and building it is a big part of what our team will work on at Cribl. But those should be applications built on a shared foundation, not separate silos with separate copies of your data. On that foundation, engineers get better tools, and agents get what they need to do real production work.
Switching agents or finding a new use for your data should carry your investment forward, not make you buy the same foundation again. The foundation should be yours to use. The applications should be yours to choose.
Why Cribl, and why now
When I read Cribl CEO Clint Sharp’s post, What is agentic telemetry?, one line stood out: “Models will change. Agents will change. Interfaces will change. Your telemetry is the durable asset.” It was clear Cribl saw the same future we did. Agents are already showing up in production, and the foundation needs to be ready for them. Watching what Cribl was shipping, we could either compete with them or build it together. So I reached out.
This future needs a platform that already works across the sources, storage, and tools customers use. It also needs a company that means it when it says your data is yours. Cribl has both. It has always put customers first and earned a fiercely loyal community along the way.
That’s why we’re here. My co-founders Adam Cohen, Nihar Singhal and I are bringing the Tero team and our work on agent access and production understanding to Cribl. There’s a lot of work ahead, and we can’t wait to do it with this community.
