# What Comes After Observability? > Source: > Published: 2026-07-20 15:00:00+00:00 # What Comes After Observability? A year ago, I predicted ways in which AI was about to fundamentally change observability as we knew it. Here's what we've seen happen since—both at Honeycomb and with our customers—and what we're building for the future. By: [Austin Parker](/author/austin) #### The Second Edition of Observability Engineering Is Here The second edition of Observability Engineering is available for download on our website. [Download](/blog/the-second-edition-is-here) A year ago, I wrote [“It’s the End of Observability (and I Feel Fine).”](/blog/its-the-end-of-observability-as-we-know-it-and-i-feel-fine) The upshot of that post was that AI was about to fundamentally change the way we approach systems design and operation in the future. In the grand tradition, I’d like to revisit my claims from then and see how my predictions panned out. ## Claim: Agents can zero-shot investigations for less than a dollar I asked the agent the same question we’d ask you in a demo, and the agent figured it out with no additional prompts, training, or guidance…and it did it for sixty cents. I pointed out in my original blog that the way I evaluated our MCP server was to feed it a prompt based on the same demo that we give to people—e.g., here’s this weird latency spike, investigate it, tell me why it happened. At the time, that demo took eight tool calls and about $0.60 of inference. A year later, we process about 2 million agent-initiated query runs through Honeycomb every month! What’s really interesting, though, is that we’ve seen agents start to accomplish significantly longer-horizon tasks. Frontier models—like Sonnet or Fable 5—are increasingly agentic and capable. In the same agent session, we’ve seen tool calls double on average between February and June of this year. Our original demo of eight queries looks downright quaint. # Ask Austin live Join Austin Parker and the other authors of Observability Engineering for a live AMA on what's changed in the AI era. July 29 | 10 a.m. PT / 1 p.m. ET ## Claim: Humans stay in the loop I’m not gonna sit here and say this destroys the idea of humans being involved in the process, though. I don’t think that’s true. The rise of the cloud didn’t destroy the idea of IT. The existence of Rails doesn’t mean we don’t need server programmers. Productivity increases expand the map. There’ll be more software, of all shapes and sizes. We’re going to need more of everything. What’s really interesting is that *human-initiated queries haven’t shrunk*. Agents aren’t taking investigations away from humans, they’re *accentuating* them. People still use the UI, people still check their boards, but they’re now able to do more than they could before by leveraging AI. We see this a lot in terms of edits—while people *are* using agents to build boards and update SLOs, the overwhelming majority of tool calls are to just run queries. In my blog, I claimed that productivity increases weren’t going to diminish the impact or effect of people, and that’s what the data shows. The map is not the territory, but the map has grown significantly thanks to agents. This doesn’t mean that all of these agents are being driven by a human, though. We’re seeing an increasing amount of headless agents using our MCP; it’s actually the fastest-growing segment. ## Claim: It’s only getting cheaper to do this Inference costs are only going down…If your product’s value proposition is nice graphs and easy instrumentation, you are cooked. An LLM commoditizes the analysis piece, OpenTelemetry commoditizes the instrumentation piece. In my original post, I focused on the idea of inference costs going down. I think that’s, broadly, still true (even if a lot of people are getting sticker shock as they transition from all-you-can-eat to API pricing for development workloads). That said, I’m writing this post on a laptop that effortlessly runs Google’s Gemma4 model, and it’s perfectly capable of using our MCP. I think, long-run, the “cost of AI” is going to keep going down at a fixed level of capability. What I didn’t call, though, is that the robots are actually surprisingly efficient when it comes to *using* Honeycomb! On average, agent queries cost about half as much to serve as human ones. There’s a pretty easy explanation for this: the agents are able to much more accurately figure out what to search for, especially if they’re running with access to your code. They know exactly what to look at, and they don’t need to spend as much time searching across an entire environment to orient themselves. Interestingly enough, we also notice that agents—on average—tend to run queries over a 50% shorter time range than humans. Where this gets really interesting is how *different* the agent runs tend to be. Custom agents tend to look at smaller time windows, while human-driven ones tend to look across longer periods of time. My hypothesis is that those custom agents are probably more task-oriented (“Here’s an error, look around this time for traces”) vs. more exploratory work being done in the development loop. The headline number, though? On average, an agent-initiated query fans out to 3.3x fewer lambdas, scans 1.8x fewer bytes, and burns 2.2x less compute. What does this mean for us? Well, from March to June we’ve grown 4x in query volume while only increasing cost by 23%, leading to a 72% reduction in unit costs for agent-initiated queries. I’ll take that! An interesting coda to this, though, is that agents are *significantly worse* for caching. While we don’t see significant amounts of caching for interactive queries in general, we see almost *none* for agent-driven queries. This is mostly because agents don’t need to ask the same question twice. I’ve also personally observed that agents prefer to re-run queries rather than reuse existing ones, which is interesting and probably deserves more attention. That said, we’ve seen pretty [staggering levels of adoption](/blog/30-70-prs-day-how-we-managed-not-wreck-systems), especially in the enterprise. One of our larger customers read 62 PiB of data in one month's time *exclusively* through agents, mostly through off-the-shelf tools like Claude Code. There’s a downside to this as well, though: a lot of those queries wind up being kinda slow, because the agents aren’t chewing through nicely structured data, they’re grepping across unstructured body fields. Structured, high-cardinality, high-dimensionality data is no longer a nice-to-have for humans, **it is a requirement for making agent investigations affordable**. All of that data that the agent has to chew through in order to find the needle in the haystack? That’s tokens coming out of your pocket. Do you want to pay Fable rates to look through gigabytes of crappy logs? ## Claim: Fast feedback loops are all that matter I’m gonna put a marker out there: the only thing that really matters is fast, tight feedback loops at every stage of development and operations. AI thrives on speed—it’ll outrun you every time. Just go ask Claude to summarize the current state of the “Loops” discourse and you’ll see that the rest of the AI thought leadership industry is talking about something you read here a year ago. Anyway, there’s no prize for being first, so I instead want to share a story from one of our customers. Guy writes in to tell us how much he loves MCP and how he’s using it. He’s hooked up everything to agents that talk to Honeycomb. When a customer reports an issue or someone files a bug, the agent goes out to verify it using production telemetry. When an SLO burns, agent goes out, looks into it. Agent takes that investigation, hands it off to another agent, which goes out and writes a fix, makes a PR. Yet another agent reviews the PR and pings a human for final review and merge. PR gets deployed, goes into prod, wakes up that original agent to look at production telemetry to see if the problem was fixed. If it wasn’t, enter the loop again. That’s the kind of tool that we’re building at Honeycomb today, yes. But what we’re building for tomorrow is so much more than that. I don’t want us to build *just* a really fast column store (although a really fast column store is cool). I want to make it easy for everyone to have these fast feedback loops. I want you to be able to understand what your agents are doing with your code, and I want to make it easy for you—and your agents—to learn about production and turn those learnings into knowledge. If you’ve had the chance to check out [Canvas](/platform/canvas), and our Canvas Agent, you’ve seen the first cut of this (and if you haven’t, you should check it out; it’s free!). This is just the first chapter of what we’re building, though. If you're interested in learning more about how we see AI changing observability and what we're working on here at Honeycomb, join me and the other authors of the Observability Engineering book [during our live AMA July 29](/go/observability-engineering-author-ama). P.S. [We’re hiring](/careers) if you wanna come work on agents with us.