I Spent Two Days at the Observability Summit. Here’s What I Keep Thinking About.

I’ve been in the observability and monitoring space for over a decade. I have a pretty good mental model of what these events look like: vendors with flashy demos, practitioners venting about alert fatigue, a keynote that name-drops whatever acronym is having a moment.

Observability Summit North America 2026 was different in a way that’s hard to describe cleanly. Yes, there were sessions on better dashboards or cheaper observability, but the most interesting sessions were about what happens to your operational model when the systems you monitor are themselves making decisions. And honestly, I’m not sure the industry has good answers yet.

Here’s what I keep coming back to.

Monitoring what your agents do isn’t enough

For the past few years, agentic AI has been the thing everyone’s talking about building. At this summit, it was the thing people were talking about having already built and now trying to manage.

The challenge is that most observability tooling was designed around a simple premise: something happens, you observe it, you respond. An AI agent breaks that model. It doesn’t just respond to inputs; it decides things. It scales a service, reroutes traffic, triggers a remediation. And when something goes wrong downstream, “our agent decided to do it” is the wrong answer. You need to know why it made that call.

Julian Topley, Senior Cloud Delivery Manager at Lloyds Banking Group, published a sharp piece on exactly this problem the same week as the summit. He put it better than I could: “Telemetry is not yet understanding, and recovery is not yet learning.” That’s the gap. And it’s not just a tooling gap — it’s an organizational one. Most teams are optimized to restore service. Far fewer have built the second feedback loop that improves the model underneath.

Several sessions focused on using distributed tracing to reconstruct agent reasoning, not just agent behavior. The open-source community is moving quickly here. Semantic Conventions 1.37+ (semconv 1.37+) is actively expanding to cover LLM and agent observability, and there’s genuine debate underway about whether OTLP — the current OpenTelemetry transport protocol — is the right mechanism for agentic workloads at all, with OTAP emerging as a potential successor.

For IT leaders, the practical question isn’t whether to follow these standards debates closely. It’s whether your current monitoring stack can even tell you why an agent did what it did. Most can’t.

The telemetry cost problem just got harder

There’s a tension in this space that I don’t think anyone has resolved, and the summit surfaced it repeatedly.

AI systems need rich, detailed telemetry to make good decisions. But observability costs — what you pay to collect, store, and process all that data — are already the biggest complaint in the industry. The traditional response to cost pressure is sampling: send a fraction of your traces and logs, keep the bill reasonable. That’s fine when a human is reviewing dashboards. It’s a real problem when an AI agent is trying to diagnose a subtle, intermittent failure and you’ve already discarded the signal it needed.

There were enough telemetry pipeline vendors at the summit, the tools that sit between your systems and your observability platform, managing what gets sent and what gets dropped, that it was hard to miss how acute this problem has become. Cost pressure clearly remains top of mind.

If you’re responsible for an observability budget, make sure you push your vendors to understand data volume pricing.

Someone built their own agentic RCA in two months

This is the one I’m still sitting with.

A large financial services company presented how they built an in-house agentic root cause analysis system. Two engineers. Roughly two months. They’d looked at commercial solutions and found gaps. Some were capability gaps: not enough investigation depth, or onboarding complexity that would slow them down. But some were table-stakes requirements that vendors simply couldn’t meet — SOC 2 compliance, on-premises deployment options. For a regulated financial institution, those aren’t negotiable. When the commercial options couldn’t clear those bars, building started looking more attractive than buying.

I want to be careful about how I frame this, because the obvious read is “see, DIY is fine.” I don’t think that’s the right takeaway. Building your own platform has real long-term costs that don’t show up in the initial build estimate: ownership, maintenance, keeping pace with fast-moving standards, and integration work that compounds over time. Most organizations underestimate those costs significantly.

But the fact that it’s a credible option now for a mid-size engineering team is a meaningful shift. Three years ago, it wasn’t. AI tooling has lowered the barrier to assembling something capable from open-source components, and that changes the build-vs-buy conversation whether vendors want to acknowledge it or not.

The implication for IT leaders isn’t “build it yourself.” It’s more uncomfortable than that. If a commercial solution can’t show you working value faster than an internal team could put something reasonable together, that’s a real problem.

Who shapes the standards shapes what you can buy

This one was more subtle, but I think it matters more in the long run than any of the product announcements I saw.

OpenTelemetry has already changed how the industry thinks about telemetry collection, moving it away from proprietary agents toward a common framework. That shift is mostly done. What’s happening now is the extension of those same standards into new territory: agent observability, LLM token tracking, multi-modal AI pipelines. The semconv 1.37+ work and the OTAP conversation are both live examples of this. These aren’t academic debates. Standards decisions made in the next 12 to 18 months will determine what integrates with what.

What I’d actually do with this

I don’t love listicle takeaways, but a few things feel concrete enough to be worth stating directly.

If you’re deploying AI agents in operational roles, check whether your current monitoring stack can surface agent reasoning, not just agent actions. Most can’t, and you’ll find out the hard way if you don’t check first.

If you haven’t pressure-tested your telemetry costs against a scenario where AI workloads double your data volume, do that before you’re in a budget conversation about it.

And if you’re evaluating observability vendors, make time-to-value a real criterion with a real test. Not “how fast do they say they can get us live” but how fast can they show you something that looks like your environment working.

The space is moving. The organizations treating observability as a strategic question rather than an IT line item will have more options when it matters.

Thinking about how your observability strategy maps to a world where AI agents are part of your operational stack? Contact Virtana to talk through what full-stack hybrid observability looks like for your environment.  

Continue Reading
AIFO Solution Brief
Virtana Platform overview