{"slug": "how-to-add-honeycomb-traces-to-your-ai-slack-bot", "title": "How to add Honeycomb traces to your AI Slack bot", "summary": "Lunch Pail Labs has integrated Honeycomb traces into its AI Slack agent Pipa to solve the black-box problem when the bot fails. The agent, which runs in E2B sandboxes using OpenCode, now sends OpenTelemetry data to Honeycomb, creating a single trace per run that includes spans for sandbox preparation, OpenCode commands, and Slack delivery. To capture the agent's actual behavior beyond infrastructure metrics, the team emits custom events for user messages, assistant responses, tool calls, and retries, enabling Honeycomb's Agent Timeline feature to visualize the full session.", "body_md": "[Pipa](https://www.usepipa.com/) is our agent for studio operations at [Lunch Pail Labs](https://lunchpaillabs.com/). She lives in Slack, is powered by [E2B](https://www.e2b.dev/) sandboxes, and uses [OpenCode](http://opencode.ai/) for the harness.\n\nWhen it works, it’s awesome. You ask for help. Pipa goes off, runs the tools, does the work, and comes back with the answer.\n\nWhen it goes wrong, it’s a complete black box. In the terminal, I can see the mess: tool calls, permission prompts, stalls, and weird little “I can’t do that” moments. In Slack, most of that disappears behind a typing indicator and one final message.\n\nIf you’re building an AI agent that lives in Slack or runs in the background, this pain may feel familiar. You need traces. This is the setup I used to send mine to [Honeycomb](https://www.honeycomb.io/).\n\nA trace shows one request moving through your system. For a Slack agent, that usually means one Slack message, one agent run, and one Slack reply.\n\nThe shape depends on your architecture. In Pipa, a chat gateway pings an E2B sandbox, loads the right skills and templates, and runs OpenCode.\n\nFor [Pipa](https://www.usepipa.com/), I put the telemetry in the chat gateway because that layer sees the whole run: the Slack prompt, the sandbox lifecycle, the OpenCode event stream, stdout and stderr, retries, run status, and Slack delivery status.\n\nThe gateway creates one trace per run. That trace is made of spans. A span is one timed step inside the run, like preparing the sandbox, starting OpenCode, watching a tool call, or sending the final Slack reply.\n\nFor my bot, the trace includes spans like:\n\n`pipa.run.execute`\n\n`pipa.e2b.sandbox.prepare`\n\n`pipa.opencode.command`\n\n`invoke_agent pipa.standard_opencode`\n\nThe first few spans explain the backend path. The `invoke_agent`\n\nspan explains the agent session. Inside that span, Pipa attaches events for the user message, assistant responses, tool calls, retries, and run summary.\n\nNow the boring infrastructure stuff and the agent’s actual behavior live in the same trace.\n\nOpenTelemetry creates and sends the trace data. Honeycomb is where I inspect it. In Pipa, the gateway sends traces to Honeycomb when `HONEYCOMB_API_KEY`\n\nis present.\n\n``` php\nSlack event -> gateway run -> sandbox prepare -> OpenCode command -> Slack reply\n```\n\nFor Pipa, the top-level run span is `pipa.run.execute`\n\n. This is the span I search for when someone says, “the bot got stuck” or “Slack never got a good answer.”\n\nThese spans tell me whether the basic plumbing worked:\n\n`pipa.e2b.sandbox.prepare`\n\n`pipa.opencode.command`\n\nThey answer the early questions. Did the sandbox start? Did OpenCode run? How long did each step take? Did the failure happen before the agent really got going?\n\nOne thing I missed at first: traces alone do not give you an agent timeline.\n\nYou can emit a bunch of spans and Honeycomb will show you a normal backend trace. Useful, yes, but it still reads like infrastructure: Slack event received, sandbox started, command ran, response sent. You can see which services ran and how long they took. You still cannot see what the agent did.\n\nFor that, you need Honeycomb’s Agent Timeline.\n\nThe way I understand it, Agent Timeline works when Honeycomb can recognize an agent invocation span and read the agent’s activity as events inside that span. Instead of showing only backend work, the trace can show the session itself: the user prompt, assistant messages, tool calls, tool results, retries, and final output.\n\nA normal trace might look like:\n\n`slack.event.received -> sandbox.prepare -> opencode.command -> slack.reply.sent`\n\nAn agent timeline is more like:\n\n`invoke_agent -> user_message -> assistant_response -> tool_call -> tool_result -> assistant_response -> run_summary`\n\nThat distinction matters. Honeycomb can show normal service spans automatically, but it will not magically know what happened inside your agent. You have to emit those events yourself.\n\nAs far as I understand it, “Agent Timeline” is Honeycomb’s product view for this. Other observability tools may support GenAI tracing, span events, or custom trace views. Honeycomb’s Agent Timeline is the feature I was targeting here.\n\nPipa emits a Honeycomb Agent Timeline-compatible span:\n\n`invoke_agent pipa.standard_opencode`\n\nThat span gets the attributes Honeycomb needs to group and display the run:\n\n`gen_ai.conversation.id`\n\n`gen_ai.agent.name`\n\n`gen_ai.operation.name`\n\n`gen_ai.request.model`\n\n`app.run_id`\n\nThis is what lets Honeycomb show the agent session as a timeline instead of a pile of unrelated events.\n\nHoneycomb can show service calls, but it cannot know what your agent did unless you tell it. The gateway sends the moments I actually care about: the user message, the tool call, the agent response, and the run summary.\n\nFor Pipa, the gateway parses structured `opencode run --format json`\n\noutput and emits events such as:\n\n`opencode.user_message`\n\n`opencode.tool_call`\n\n`opencode.agent_response`\n\n`opencode.run_summary`\n\n`opencode.parser_skipped`\n\nThat makes the hidden middle visible: the prompt, assistant-visible text, tool names, tool status, token and cost data, retry markers, and failure summaries.\n\nAfter adding traces, run the bot from Slack and inspect the trace in Honeycomb. The trace should answer these questions:\n\nIf the trace cannot answer them, add another span or event at the layer that can see the missing context.\n\nIf your AI bot runs inside Slack, traces are how you see what happened between the prompt and the final reply.\n\nStart with the questions you ask when the bot responds badly. Then emit spans and events around those moments. One Slack request should become one run you can actually inspect in Honeycomb.\n\nOriginally published on [Lunch Pail Labs](https://lunchpaillabs.com/writing/how-to-add-honeycomb-traces-to-your-ai-slack-bot/).", "url": "https://wpnews.pro/news/how-to-add-honeycomb-traces-to-your-ai-slack-bot", "canonical_source": "https://dev.to/ojabowalola/how-to-add-honeycomb-traces-to-your-ai-slack-bot-2f1b", "published_at": "2026-06-02 22:24:00+00:00", "updated_at": "2026-06-02 22:43:06.605855+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "mlops", "artificial-intelligence"], "entities": ["Pipa", "Lunch Pail Labs", "E2B", "OpenCode", "Honeycomb", "Slack"], "alternates": {"html": "https://wpnews.pro/news/how-to-add-honeycomb-traces-to-your-ai-slack-bot", "markdown": "https://wpnews.pro/news/how-to-add-honeycomb-traces-to-your-ai-slack-bot.md", "text": "https://wpnews.pro/news/how-to-add-honeycomb-traces-to-your-ai-slack-bot.txt", "jsonld": "https://wpnews.pro/news/how-to-add-honeycomb-traces-to-your-ai-slack-bot.jsonld"}}