"How are engineering organizations adopting AI within observability workflows, what is the maturity gap, and what is blocking scale?"

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now the thing I keep coming back to is the gap between what our observability vendors are promising with AI and what actually integrates cleanly into our existing workflows. Every tool we use — Datadog, PagerDuty, a couple others — has started bolting AI features onto their dashboards, and the pitch is always the same: "it's purpose-built, AI at the core." But when I push on what that actually means operationally, it gets thin fast. The more concrete tension is around data access. A lot of the AI-assisted analysis these vendors are offering requires them to have broader access to our telemetry data than we're comfortable granting. We're a B2B SaaS company, our customers' data flows through our systems, and I have to think carefully about what I'm feeding into a third-party model, even if it's just metadata. Security posture isn't optional for us. The third thing is really a resourcing question — we don't have a dedicated team to evaluate, implement, and maintain every new AI capability that gets dropped into a vendor update. My engineers are already context-switching enough. So even when something looks genuinely useful, the integration work and ongoing ownership cost is real, and it often doesn't show up in the vendor's pitch.

What's the most important thing you need to understand or solve here?

For us, the core problem right now is figuring out where AI in observability actually earns its keep versus where it's just adding another layer we have to maintain. We've got traces, logs, metrics spread across a few different systems, and the question isn't "should we use AI" — it's "which specific part of this workflow breaks down enough that AI actually fixes it rather than just complicating it." The secondary thing I'm trying to solve is the integration story. I've been burned enough times by vendors who bolt AI onto an existing product and call it purpose-built. I need to understand whether the AI component actually has access to the right data at the right time, or whether it's just summarizing things I could already see.

What does 'good' look like to you — and how far are you from that today?

For us, "good" means AI that's genuinely embedded in the feedback loop — where an anomaly is detected, correlated to a probable cause, and surfaced with enough context that an on-call engineer can make a decision without having to pivot across four different dashboards. That's the north star. Where we actually are today is... maybe halfway there on a good day. We've got reasonable anomaly detection running in our metrics pipeline, and we've done some work connecting that to deployment events. But the correlation layer — tying together logs, traces, and metrics with something that actually reasons about causality rather than just pattern-matching — that's still pretty immature for us. The tooling exists in pieces, it's just not cohesive yet. The honest gap is less about the AI capability itself and more about data quality and normalization across services. You can't build a smart layer on top of inconsistent telemetry, and that's a foundational problem we're still cleaning up.

What would change your perspective on this entirely?

If someone showed me a real production system where AI in observability was actually closing the loop autonomously — not just surfacing anomalies or generating summaries, but actually remediating issues in a way that I could audit end-to-end and trust — that would move me. Right now most of what I see is AI bolted onto alerting pipelines that already exist, which is incremental at best. The other thing that would shift my thinking is better answers on data residency and model explainability. My security instincts kick in hard when I'm sending telemetry data to a third-party inference endpoint and I can't fully account for what's being retained or how the model arrived at a conclusion. If a vendor could demonstrate genuine air-gapped or on-prem inference with comparable performance, that conversation gets a lot more interesting to me.

What question are you not being asked that you wish someone would ask?

The data quality question. Everyone wants to talk about which AI features they're adding to their observability stack, but almost nobody asks "what's the actual state of your telemetry data before you point AI at it?" In my experience, if your instrumentation is inconsistent, your naming conventions are a mess across services, or you've got gaps in coverage, the AI layer just amplifies those problems. Garbage in, garbage out — but now it's confidently presented garbage. I'd rather spend time on that foundational question than evaluate another vendor's anomaly detection demo.

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now the thing I'm wrestling with most is the gap between what vendors are claiming AI can do in observability and what actually integrates cleanly into our stack. We run a fairly opinionated architecture — everything's API-first, we care a lot about data residency and access controls — and a lot of these tools that say they're "AI-native" or "built with AI at its core" don't hold up when you start asking specific questions about how the inference actually works, where the data goes, what the model's doing under the hood. The other piece is more internal. My team is capable, and we've built some lightweight tooling ourselves around anomaly correlation and log summarization. So the build-vs-buy calculus is genuinely hard right now. Some of what vendors are charging for, we could wire together with API calls in a few weeks. But then I also don't want to be maintaining that indefinitely when the vendor landscape matures. So we're in this holding pattern where we're not fully committed to any one platform, which has its own costs.

What's the most important thing you need to understand or solve here?

For us, the core problem is figuring out where AI in observability actually adds durable value versus where it's just a feature that got bolted on because vendors needed something to talk about at KubeCon. We're running a reasonably complex microservices environment, and the signal we're getting from the market is noisy — every tool in our stack is claiming AI capabilities now, and most of them are describing the same thing in different words. The question I keep coming back to is: what does "AI-assisted observability" actually change about how my team operates day-to-day? Not in theory — in practice. Where does it compress toil, and where does it just add another thing an engineer has to babysit?

What does 'good' look like to you — and how far are you from that today?

For us, "good" looks like AI that's actually embedded in the remediation loop — not just surfacing anomalies but connecting the dots across services, suggesting a probable root cause, and ideally triggering a runbook or at least drafting one. The signal that it's working is when an on-call engineer spends less time in the war room reconstructing what happened and more time validating a hypothesis that the system already handed them. How far are we? Honestly we're partway there on the detection side — we've got reasonable anomaly coverage — but the remediation piece is still pretty manual. The gap is mostly around context: the AI doesn't have enough understanding of our service dependencies and business criticality to prioritize well. It can tell me something is wrong; it can't yet tell me why this one matters more than that one right now. The other piece that's blocking us is data quality upstream. Garbage in, garbage out — if your instrumentation is inconsistent across services, the AI layer just amplifies that inconsistency. We've had to do a lot of foundational work on span coverage and log structuring before we could even get the AI features to behave predictably. That's unglamorous work that nobody's selling you a solution to.

What would change your perspective on this entirely?

That's a fair question. I think what would move me most is seeing genuine cross-signal correlation that actually closes incidents faster — not just "AI flagged an anomaly" but "AI connected the deployment event, the upstream dependency degradation, and the customer-facing latency spike in under two minutes, and here's the incident timeline to prove it." Right now most of what I see is AI operating on individual signal streams rather than across them. The other thing would be a credible data isolation story. We're in a position where feeding full telemetry into a third-party AI layer raises real questions about what's being retained, trained on, and exposed. If a vendor could demonstrate genuinely air-gapped inference with model quality that doesn't degrade significantly, that changes the calculus for us on the security side pretty substantially.

What question are you not being asked that you wish someone would ask?

The data quality question. Everyone wants to talk about which AI observability tool you're evaluating or whether you're doing AIOps — but nobody asks "what does your underlying telemetry data actually look like before you feed it to any of these models?" In our environment, we've got instrumentation gaps, inconsistent tagging across services, log formats that vary by team. If the foundation is messy, layering AI on top of it just automates bad conclusions faster. That's the real maturity gap in most orgs, and it's not a sexy conversation to have with a vendor or a researcher.

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now the thing I keep coming back to is the gap between what AI tooling promises in our observability stack and what our engineering team actually has bandwidth to configure and maintain. We've got a small platform team, and a lot of these tools — whether it's Datadog's AI features or some of the newer purpose-built stuff — assume you have someone who can own the tuning and feedback loops. We don't really have that person. The other piece is that we're in fintech, so compliance and data sensitivity add a layer of friction that slows down every adoption decision. Even when the engineering team is excited about a capability, procurement and legal want to understand exactly what's leaving our environment. That's not unique to us, but it definitely stretches out timelines in ways that a pure velocity argument doesn't account for. Broadly, I feel like we're somewhere in the middle — we've moved past just using AI for log search or basic anomaly detection, but we're not at the point where any of it is meaningfully automated or feeding back into our incident workflows in a reliable way. That's the gap I'm trying to figure out how to close without just throwing headcount at it.

What's the most important thing you need to understand or solve here?

For us, the core question is whether AI in observability actually changes how fast engineers can diagnose and respond to issues, or whether it's just adding another layer that someone still has to babysit. Right now we're a small-ish fintech team, so we don't have the luxury of a dedicated SRE function that can spend cycles tuning every AI-assisted alert or anomaly detection model. The practical blocker is that the value of these tools is really contingent on having clean, well-instrumented data underneath them — and a lot of teams, including ours at times, haven't fully solved that foundational layer yet. So before I'd feel confident scaling anything AI-related in our observability stack, I'd want to know: are the teams that are seeing real workflow improvement doing so because the AI is genuinely capable, or because they already had strong data hygiene and the AI is just surfacing what was already there?

What does 'good' look like to you — and how far are you from that today?

For us, "good" looks like AI that's genuinely embedded in the feedback loop — where anomalies surface with enough context that an engineer can make a decision without having to go chase down five other dashboards. Not just alerting, but actual triage support. Something closer to: here's the pattern, here's what changed, here's the probable blast radius. Where we are today is a fair bit behind that. We have some AI-assisted tooling, but honestly the iteration work has been mostly on the tooling side — not enough on the process and people side. I've seen that play out broadly too, where teams invest heavily in the tech and then twelve to eighteen months in they realize the humans and the workflows didn't really adapt around it. The gap for us specifically is around workflow integration. The signal exists but it's not reaching the right people in the right format at the right moment in their workflow. That's less an AI problem and more a product design and change management problem, which is sort of my lane to push on.

What would change your perspective on this entirely?

For us, the thing that would shift my thinking the most is seeing reliable evidence that AI-generated insights actually close the loop — not just surface an anomaly, but trace it, contextualize it within our business logic, and hand off something actionable without a human having to re-interpret it. Right now there's still a meaningful gap between "AI flagged something interesting" and "AI understood what it meant for our specific system." The other piece is data governance. We're fintech, so we have compliance requirements that make it hard to just pipe everything into a third-party model. If that constraint got meaningfully easier to navigate — either through on-prem options that were actually competitive, or clearer regulatory guidance — that would open a lot of doors we currently treat as closed. I don't have a strong view on the timeline for either of those, but those are the two things I'd actually be watching.

What question are you not being asked that you wish someone would ask?

The integration question, honestly — not "are you using AI in observability" but "who owns the output when AI surfaces an anomaly and it turns out to be wrong?" That accountability gap is something we haven't fully worked through. On the product side, when I'm thinking about shipping a feature that touches alerting or monitoring, I need to know whose name is on the decision if the AI misclassifies something critical. Right now that's murky in a lot of orgs, including ours.

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now the thing I keep coming back to is the gap between what AI observability tools promise and what actually fits into how our engineers work day-to-day. We've got a few tools in the stack that have AI-enabled features, but the adoption inside the team is pretty uneven — some engineers find the suggestions useful, others just ignore them and go back to their usual workflow. The harder question for me as a PM is figuring out whether that's a tool fit problem or a process problem. Like, did we actually do the work to understand where in the incident response or monitoring workflow AI could genuinely reduce friction, or did we just turn on a feature and hope people would use it? I suspect it's more the latter, and that's something I'm trying to get ahead of.

What's the most important thing you need to understand or solve here?

For us, the core question is really about signal quality and trust. We're generating a lot of telemetry data across our services, and the challenge is figuring out where AI actually helps an on-call engineer make a faster, better decision — versus where it's just adding another layer they have to mentally wade through. Right now I'd say we're early. We've got some tooling in place, but the adoption gap between "we have this capability" and "engineers actually rely on it in a high-pressure incident" is real. That's the thing I want to understand better — what's blocking that trust from forming.

What does 'good' look like to you — and how far are you from that today?

For us, "good" means our engineering team spending most of their time on actual problem-solving rather than hunting through dashboards to figure out what's wrong. Like, if something degrades in production, the system should surface the right context — not just a raw alert — so the on-call engineer can get oriented quickly without needing to correlate five different tools manually. How far are we from that? Reasonably far, I'd say. Right now we have observability tooling in place, but the AI-assisted layer on top of it is pretty shallow. It's more "here's an anomaly" than "here's what's probably happening and here's what we've done about similar things before." The gap between those two is where I'd say most of the real value sits, and we haven't closed it. Part of what makes that gap hard to close is it's not purely a tooling problem. It's also a process and data quality problem — the kind of thing where you can deploy a new capability and then realize twelve months in that the underlying telemetry wasn't structured well enough for it to actually work. We're trying to avoid that pattern by getting the foundations cleaner first before we add more AI on top.

What would change your perspective on this entirely?

That's a fair question to sit with for a second. Probably the thing that would shift my view most is if I saw AI genuinely closing the loop autonomously — not just surfacing an anomaly or summarizing a log, but actually correlating it to a root cause, proposing a fix, and having that fix validated without meaningful human intervention. Right now I see a lot of the value in the "here's a summary" layer, which is useful but not transformative. The other thing would be seeing the people and process side actually catch up to the tooling. In my experience, most orgs — including ours to some degree — are still spending the majority of their energy getting data pipelines clean and teams aligned, and the AI layer sits on top of a pretty messy foundation. If I saw a credible pattern for solving that organizational readiness problem, not just the technology problem, I'd update my view on how fast this can actually scale.

What question are you not being asked that you wish someone would ask?

The maturity model question, maybe. Everyone asks "are you using AI in observability?" but nobody asks "what does your data foundation actually look like underneath it?" Because in my experience, a lot of teams are trying to layer AI on top of data pipelines and logging infrastructure that were never designed with that in mind. The AI tooling question is almost downstream of that.

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now, my biggest wrestling match is attribution — specifically trying to understand what's actually driving pipeline versus what just looks like it's driving pipeline. We've been layering in more AI-powered tooling across our stack, and the honest problem is that when something works, I can't always tell if it's the AI component or just better process hygiene underneath it. The other thing is vendor consolidation pressure. Every tool I'm already paying for has "AI" baked in now, so when a net-new vendor pitches me an AI-native point solution, the bar they have to clear is pretty high. It needs to do something my existing stack genuinely can't, not just wrap a familiar workflow in a shinier UI. Those two things are connected — if I can't attribute outcomes cleanly, I can't justify adding another tool. So I'm kind of stuck in this loop where I want to experiment more aggressively, but the CAC consciousness keeps pulling me back toward "prove it first."

What's the most important thing you need to understand or solve here?

For us, the most important thing is understanding where AI in observability actually moves the needle on pipeline health versus where it's just adding complexity to our stack. I'm not an engineering buyer, so my lens is more indirect — if our eng team is drowning in noise or spending cycles on manual triage, that's a capacity problem that bleeds into product velocity, which eventually hits my ability to run campaigns against a stable product. So I care about whether these tools actually reduce toil in a measurable way, or whether they're just another integration someone has to maintain. That's where I'd want to focus.

What does 'good' look like to you — and how far are you from that today?

For us, "good" in the demand gen context is pretty straightforward — I know which channels are driving pipeline that actually closes, I can tie spend back to revenue with reasonable confidence, and I'm not guessing at CAC by segment. That's the north star. How far are we from that? Closer on some things than others. The scoring and enrichment layer is decent — we're using a few tools stitched together rather than one magic solution, which is honestly more realistic anyway. Where we still fall short is the feedback loop from sales back into our models. Closed-won data doesn't flow back cleanly, so the AI scoring never quite learns what "good" actually looks like in our customer base. That's a pretty common failure mode from what I can tell, not unique to us.

What would change your perspective on this entirely?

If we started seeing really clean proof that AI-driven observability actually reduces time-to-resolution in a way that's measurable and attributable — not a vendor case study, but something like a peer company with a similar stack publishing their actual incident data — that would shift how seriously I push for it internally. Right now a lot of what I see is vendors saying "AI" when they mean "we added some rules-based anomaly detection on top of our existing dashboards." If the tooling got more honest about what it actually is versus what it's marketed as, that would help too. I don't have a strong view on the engineering side of this specifically, but from where I sit watching tool evaluations happen, the gap between the pitch and the proof is still pretty wide.

What question are you not being asked that you wish someone would ask?

That's a fair question to end on. Probably something around how marketing and engineering are actually supposed to collaborate on observability tooling decisions when they're buying from completely different frames of reference. Engineering cares about uptime and root cause; I care about whether the product's reliability story holds up in a deal cycle and whether we can actually use system health data to inform customer success handoffs. Those worlds don't talk to each other much, and I don't think vendors ask about that gap either.

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now the thing I keep bumping into is attribution — and I know that sounds like a marketing problem, not an observability problem, but hear me out. We're being asked to evaluate a bunch of AI-powered tools across our stack, and the honest challenge is that it's really hard to isolate what any one of them is actually doing. Every piece of software we use already has AI baked in at this point, so when someone pitches us on a new observability or monitoring tool, the question I immediately ask is: what does this do that my existing vendors haven't already shipped in their last two releases? The second thing is just the learning curve tax. We're a lean team at a Series A, so asking someone to get fluent in a new platform has a real cost. The tool basically has to add insane value above whatever we're already running before I can justify the context switch. So I'd say we're cautious adopters — not because we don't believe in the category, but because the switching cost math rarely pencils out cleanly at our stage.

What's the most important thing you need to understand or solve here?

The core thing for me is pipeline efficiency — specifically understanding which channels and campaigns are actually driving qualified opportunities, not just top-of-funnel volume. At a Series A company with a lean budget, I can't afford to keep spending on things that look good in a dashboard but don't convert downstream. The attribution piece is what makes that hard. Sales and marketing are still not great at closing the feedback loop on which leads actually closed and why, so the data I'm optimizing against is incomplete. That's less a tool problem and more a process and alignment problem.

What does 'good' look like to you — and how far are you from that today?

For us, "good" is pretty straightforward to define even if it's hard to reach: I want a system where I can trace a pipeline dollar back through every touchpoint without having to stitch together three different reports manually. That's the north star. Right now we're probably halfway there. We've got decent tooling for scoring and enrichment, but the feedback loop between sales and marketing is still leaky — closed-won data doesn't reliably flow back into our models, so the scoring never really learns what a good lead looks like in practice. That's the gap I spend the most time thinking about.

What would change your perspective on this entirely?

That's a fair question. I think if I saw consistent, closed-loop evidence that AI-driven observability was actually moving pipeline metrics — not just reducing MTTR in a vacuum, but connecting engineering reliability to revenue impact — that would shift how I think about it. Right now the conversation feels like it stays inside the eng org and doesn't really translate outward. The other thing would be seeing the feedback loops actually work. From what I can tell, a lot of these tools surface insights but the data doesn't flow back into anything actionable at the business level. If someone showed me a case where the AI learned iteratively from real outcomes — not just pattern-matched on logs — I'd take the maturity claims a lot more seriously.

What question are you not being asked that you wish someone would ask?

That's a fair question to end on. I'd probably want someone to ask more about the organizational layer — not the tools, not the data pipelines, but who actually owns the output when AI flags something in an observability workflow. Like, in a lot of the conversations I see around AI adoption in engineering, everyone's debating which platform or which model, but the accountability piece gets skipped. When AI surfaces an anomaly or a predicted failure, does that land with SRE? DevOps? Platform engineering? That ambiguity is where I'd expect adoption to slow down, even when the tooling is solid.

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now, the thing I keep coming back to is the gap between what the AI observability tools promise and what our engineering org is actually able to operationalize. We've got tooling in place — some of it has AI features baked in — but the teams are still largely reacting to incidents the same way they were 18 months ago. The wrestling match is really around whether the AI layer is genuinely changing how fast they triage and resolve, or whether it's just a feature checkbox that got added to something we were already paying for. I don't have clean attribution on that yet, and that bothers me from a planning and budgeting standpoint.

What's the most important thing you need to understand or solve here?

For us, the core question is whether AI in observability is actually reducing time-to-resolution or just adding another layer that engineers have to manage. We're a Series B SaaS company, so our engineering team is lean — when something breaks at 2am, every minute matters, and I need to know the tooling is genuinely helping, not creating more overhead. The second piece is around adoption. Even if the tooling is good, getting engineers to trust and consistently use AI-assisted workflows is a real change management challenge. Tools that don't fit naturally into how the team already works tend to get bypassed pretty quickly.

What does 'good' look like to you — and how far are you from that today?

Good, for me, is when the observability layer stops being purely reactive. Right now our engineering team is largely triaging after something breaks — good looks like the system surfacing the right signal before a customer feels it, with enough context that an engineer isn't spending 45 minutes reconstructing what happened. How far are we? Probably mid-maturity. We have the tooling — Datadog, some custom dashboards — but the AI-assisted pieces are still pretty bolt-on. The anomaly detection flags things, but the signal-to-action workflow still requires a lot of human interpretation. The gap isn't really the detection; it's the contextualization and the handoff to whoever needs to act on it. The honest constraint is less about technology and more about process. Every tool I've seen in this space works better when the underlying data is clean and the team has agreed on what "normal" looks like — and that foundational work takes longer than buying a new product.

What would change your perspective on this entirely?

That's a fair question. Probably consistent, reproducible evidence that AI-driven observability actually reduces mean time to resolution at scale — not in a controlled demo environment, but in messy production conditions with real heterogeneous stacks. Right now most of what I see is vendors showing me the best-case scenario. The other thing that would shift me is seeing the feedback loop problem actually solved. The pattern I keep observing — and it's not unique to observability — is that the AI component improves over time only if the engineering team is disciplined about closing the loop on what signals actually mattered. Most teams aren't. So if someone could show me a deployment where that learning cycle is genuinely embedded in the workflow, not just claimed in a pitch deck, that would change how I think about the maturity ceiling here.

What question are you not being asked that you wish someone would ask?

That's a fair question. I'd probably say: "How do you actually decide when AI in an observability workflow has earned its keep versus when it's just adding another layer of complexity to manage?" Because right now a lot of the conversation is around adoption rates and maturity frameworks, but the harder question is the evaluation criteria. Every tool we bring in that has AI baked into it comes with its own claims, and we don't have a clean way to benchmark whether the AI component specifically is doing work or whether we'd get the same outcome from a well-configured rule-based system. That's the gap I don't hear people asking about systematically.

Tell me what's top of mind for you on this topic right now — what are you wrestling with?

Right now the thing I'm most focused on is the gap between what vendors are promising about AI in observability and what I can actually verify is working. We use a few tools that have AI baked in — anomaly detection, log summarization, that kind of thing — and the challenge is figuring out which of those features are genuinely reducing time to resolution versus just being table stakes that ship with every platform now. From a marketing lens, I'm also watching how engineering orgs internally communicate ROI on these investments. If I can't get a clear signal from our own engineering team on what's actually moving the needle, I have limited ability to understand our customers' buying behavior and what they care about. That feedback loop is pretty broken right now.

What's the most important thing you need to understand or solve here?

The core thing I'm trying to understand — and this is more of a company-wide question than just my team's — is where AI actually moves the needle in our observability workflows versus where it's just adding another layer to manage. We've got tools already baked into our stack that claim AI capabilities, and half the time it's hard to tell if we're getting real lift or just a repackaged feature. For us specifically, the blocking question is: what does "good" actually look like at scale? We can run pilots, we can see promising results in a narrow context, but getting consistent value across the engineering org is a different problem entirely.

What does 'good' look like to you — and how far are you from that today?

For us, "good" is when AI in the observability workflow actually surfaces the right issue at the right time with enough context that an engineer can act on it without having to dig through five other tools first. The system points you to the bottleneck, not just the symptom. How far are we from that? Honestly a fair distance. Right now we have a handful of AI-enabled tools in the stack, but they're not really talking to each other in a meaningful way — you still end up with a human doing a lot of the synthesis work that ideally the tooling should handle. The gap isn't that we lack AI features, it's that the integration layer between them is immature, so the value doesn't compound the way you'd expect.

What would change your perspective on this entirely?

If I saw a clear, reproducible example of AI in an observability workflow actually reducing mean time to resolution in a way that was attributable — not just correlated — that would move me. Right now a lot of what gets presented is "we deployed this, things got better," but the causality is murky. Show me a controlled comparison or at least a credible before-and-after with consistent measurement methodology, and that changes the conversation. That's honestly just the bar I'd apply to any tooling investment.

What question are you not being asked that you wish someone would ask?

That's a fair question to end on. I'd probably want someone to ask: "How does AI adoption in observability actually change the skill mix you need on the engineering team?" Because right now the conversation is almost entirely about tooling and vendor selection, and not enough about whether your existing team can actually operationalize whatever you buy. You can have the most sophisticated anomaly detection platform in the world, but if your SREs don't know how to validate its outputs or tune it for your specific environment, you've just added complexity. That human capability gap is where I think a lot of the real friction lives, and it doesn't show up in any of the vendor decks.