Operations | Monitoring | ITSM | DevOps | Cloud

From alert to answer: a hands-on investigation with trace analysis in Mezmo

Authored by Sven Delmas, VP of Research at Mezmo I wanted to know what Mezmo's new trace features feel like with real telemetry behind them, so I built the smallest honest rig I could: the OpenTelemetry demo application running in a local Kubernetes-in-Docker cluster on my machine, one collector, and one deliberately simple Mezmo pipeline.

Builder in the loop: what production agents were missing before AURA

Builder in the loop is a Mezmo interview series with the engineers, product leaders, and operators shaping AURA. Each installment looks past the product layer to explore the decisions, tradeoffs, and lessons involved in building agents for real production work. This installment features Mike Shearer, the engineer who built AURA and, until recently, its only developer. AI agents are easy to believe in when the task is small.

What an AI SRE agent actually finds when you point it at a broken Kubernetes cluster

‍ Most of the AI features that shipped into observability tools this year summarize alerts. You get a paragraph that restates the dashboard you were already looking at, and the agent never reads the cluster itself, because giving it cluster access is a security conversation nobody wanted to start. This walkthrough starts it.

5 Things to Know About Context Engineering

Software systems are getting better at understanding themselves. The mix of richer telemetry, smarter pipelines, and agentic AI is shifting observability from a passive record of events into something more active and useful. That shift is what we mean by context engineering. We recently partnered with O’Reilly on a report by David Beale that introduces the discipline. Before you read it, here are five things worth knowing.

An SRE agent for production

AI has changed how software gets built. It hasn't changed how software gets run. Most of the AI money in software has gone into the IDE: code generation, copilots, developer assistants, faster pull requests. That work matters. But writing software is one slice of the lifecycle. The harder problem, and the more expensive one, is running that software in production. Production is where systems fail in ways nobody predicted. Incidents don't stay inside one service.

We built an SRE bot on AURA. Here's what we learned.

PagerDuty fires. You open the incident. Title, timestamp, nothing else. Whatever context exists is in someone's head, in a Slack thread from two weeks ago, or in a runbook nobody has touched since the last reorg. We got tired of that. So we put an AURA agent behind a Slack bot and pointed it at our own production environment.

Life after SaaS: Enabling the System of Context

By: Tucker Callaway, CEO at Mezmo The market keeps saying “SaaS is dead.” That’s probably true, but it’s also incomplete. What’s actually dying is the idea that value lives inside a vendor-controlled black box. The next era is about utilities: unlimited coding capacity and unlimited analytical capability. And if those two utilities are real, then the vendor model has to change.

Builder in the loop: Tony Rogers on stress-testing AURA before production

Builder in the loop is a Mezmo interview series focused on the engineers, product leaders, and operators shaping AURA, an open-source, MCP-native agent harness for production operations. This installment features Tony Rogers, whose work on AURA is less about building new features and more about trying to break them before users can.

Builder in the loop: Eric Lake on making AURA smarter after every incident

Builder in the Loop is a Mezmo interview series focused on the engineers, product leaders, and operators shaping AURA, an open-source, MCP-native agent harness for production operations. The goal is to get past the polished product layer and talk through the decisions that matter when AI starts interacting with real systems. Key questions include: What should agents be allowed to do? How do they get better over time? Where should humans stay in the loop?

Why SRE agents need orchestration, not just more tools

Single agents are a useful starting point for SRE workflows. They are not where the architecture should end. The first version is simple enough: connect an LLM to a few tools, give it a system prompt, and point it at your infrastructure. It can summarize an alert, pull logs, answer questions, and draft a useful next step. Then the workflow gets real. You add GitHub for runbooks, Kubernetes for cluster state, PagerDuty for incident context, Prometheus for metrics, and Mezmo for telemetry.