Accelerate Your OpenTelemetry Migrations With Honeycomb's Agent Skills

Since releasing our hosted MCP server last year, we've been thrilled to see customers not just adopt it but build Honeycomb deeply into their agentic development and observability workflows. Users have embraced it, leveraging Honeycomb to stay in conversation with their code and understand how it runs in production.

The magic of an MCP is that it lets you build agentic workflows across a bunch of tools, with the central agent not dependent on any one of them, and adapt them to whatever agent you prefer, whether you use Claude Code, Cursor, or something more boutique. However, to take these workflows to the next level, you need to teach your agent to be an expert in observability and to understand—and use—Honeycomb the way your best SREs do.

Honeycomb has that expertise in spades. Heck, we literally wrote the book on observability! With the release of our Agent Skills, we’ve used our domain knowledge to make your agents even more powerful. Instead of having to copy and paste blocks of markdown into Claude Code, we've distilled everything we know about using Honeycomb into a set of core skills, packaged it up, and are making it open source today!

What will you find? Eight skills, two autonomous agents, and more—all organized around the three things you're most likely trying to do: get started with observability, migrate to OpenTelemetry, or figure out why production is on fire.

Getting your instrumentation right

If you're setting up OpenTelemetry for the first time or retrofitting it into an existing codebase, you know that the hard part isn't the SDK. It's knowing what to instrument, how to structure your telemetry, and what patterns will actually help you at 3 a.m. when something breaks.

The skills cover the full journey.

• Observability Fundamentals ground your agent in first principles (wide events, high cardinality, the core analysis loop) so it gives you better answers about why you should instrument something, not just how.
• OpenTelemetry Instrumentation handles SDK setup, custom spans, and attribute strategy, with opinionated guidance on what's actually worth capturing. HTTP handlers and database queries? Yes. Private helper functions? Probably not.
• For existing applications that have no instrumentation at all, the OpenTelemetry Migration skill walks through a six-phase retrofit from SDK initialization through context propagation (which is the hard part, as this tends to make up roughly 60% of the effort) to logging and metrics bridges. It's framework-aware, too. If you're on Go Fiber and your agent doesn't know about the c.UserContext() gotcha, you're going to have a bad time. This skill knows about it.
• And if you're still on Beelines, we love you, but it's time. The Beeline Migration skill handles the two-phase cutover: get W3C trace propagation running everywhere first, then migrate services one at a time. Your distributed traces stay intact throughout, no big bang required.
• We also ship an Instrumentation Advisor agent that bridges your codebase and your Honeycomb data. It reads your code, queries Honeycomb to see what's actually being collected, performs a gap analysis, and writes the instrumentation code to fill those gaps, matching your existing OpenTelemetry patterns and style. It prioritizes by debugging value: the attributes that answer "who was affected?" and "what changed?" come first.

Investigating production issues

This is where things get fun. The Production Investigation skill implements our core analysis loop (Define, Visualize, Investigate, Evaluate) as a structured workflow an agent can follow. Orient with SLOs and triggers, characterize the problem with broad queries, use BubbleUp to surface what's different about the bad stuff, drill into traces, verify your hypothesis, and record findings on a board. It's the same process our engineers use when things go sideways.

The Query Patterns skill teaches your agent how to ask good questions: never use AVG for latency (it hides the tail), use HEATMAP to spot bimodal distributions, start broad, narrow with filters. It's opinionated, because good query habits aren't a matter of taste. The SLOs and Triggers skill rounds this out with guidance on designing SLIs, interpreting budget burn rates, and configuring burn alerts—for example, fast burn to PagerDuty, slow burn to Slack.

The Honeycomb Investigator agent ties it all together. Point it at a production issue (latency spike, error surge, SLO budget burn, deployment regression) and it runs the full investigation workflow autonomously. It queries, uses BubbleUp, explores traces, verifies hypotheses, and produces a structured report with findings and recommendations.

If you read my post about doing exactly this with our MCP server, imagine that workflow but with the agent already knowing what a good investigation looks like before it starts.

The little things that matter

One more thing worth mentioning: we built a Query Validation Hook that caches your dataset schema and checks column names before your agent sends a query to the API. If your agent typos http.status_cod instead of http.status_code, it catches it and suggests the right column name via fuzzy matching. This sounds minor, but if you've ever watched an agent spiral into a doom loop of failed queries and hallucinated column names, you know it's not.

Open source, obviously

Great news; all of our Agent Skills are open source and available today. Install it as a plugin in Claude Code or Cursor, point it at your Honeycomb environment, and start asking questions. Whether you're instrumenting a service for the first time, migrating off Beelines, or debugging a production incident, these skills put everything we know about using Honeycomb right in your agent's context.

We think this is what the future of developer tools looks like—not just APIs your agent can call, but the knowledge to call them well.