DEV Community: Lola 🧱 - Lunch Pail Labs

The head chef model of AI collaboration

Lola 🧱 - Lunch Pail Labs — Mon, 22 Jun 2026 13:14:00 +0000

Working with AI is still strange territory. We reach for metaphors: manager, intern, editor, surgeon. Each gets close, but none explain the back-and-forth dance of giving inputs, interpreting outputs, and adjusting course as you work alongside a machine. We want scale, but we also want the output to reflect our judgment, our standards, and our voice. It is not just about producing more; it is about making sure what is produced still feels like us.

The Old Metaphors

Manager: Too detached. You end up supervising outputs instead of shaping them.

Intern: Too one-way. You spend more time teaching and correcting than creating.

Editor: Too reactive. You polish what already exists instead of driving direction.

Surgeon: Too specialized. Great for precision work, but not for broad creative problem-solving.

The Head Chef Frame

The head chef is not a distant strategist. They are in the kitchen, hands-on, guiding the team, tasting, and keeping everything aligned with their creative vision. They delegate, but they also step in when something needs attention.

A head chef also has a certain level of competency with the craft. They understand ingredients, technique, timing, and flavor. They can jump on the line if needed. They know what good looks and feels like.

Putting It Into Practice

Here is how I apply the Head Chef model in my own stack, using AI agents embedded in my dev environment to handle execution while I guide direction.

Set up your stations. I work in two Ghostty terminals. The left side is for planning and viewing, the right for synchronous agents running through OpenCode.
Prep your ingredients. I pick the next task from my list and break it into clear, sequential phases using a custom /create-plan command.
Open a shared recipe. Once the direction feels right, I open a GitHub issue so every agent can read from the same context.
Cook in phases. I offload each phase to the execution agents with a /create-instruction command and let them work through it.
Taste and adjust. As outputs come back, I use a /review command to inspect and refine them before committing changes.
Serve and reset. When all phases are complete, I close the issue and pull the next most important task.

This loop keeps me in the kitchen. I am orchestrating, tasting, and directing while AI handles execution without pulling me out of the work.

Conclusion

The metaphors we use for AI are not just storytelling. They shape how we work. When we frame AI as an intern, a coworker, or a copilot, we interact with it in fundamentally different ways. These mental models influence trust, delegation, and how hands-on we stay (source).

The Head Chef model reflects what great product work really requires. You need to understand the tools, the timing, and the ingredients. You need competency with the material.

And for builders, when AI enters the kitchen, that competency matters even more. The more fluent you are across design, code, marketing, and storytelling, the better you can shape what AI produces.

Originally published on Lunch Pail Labs

Building an autonomous Slack agent with OpenCode

Lola 🧱 - Lunch Pail Labs — Tue, 16 Jun 2026 16:17:59 +0000

Pipa, my operations agent running on OpenCode and living in Slack, came from a boring problem.

The more I trusted coding agents with non-coding work, the more annoying it became that they still needed my laptop, my terminal, and my attention.

I was handing local work to OpenCode: plans, writing, research, reviews, repo cleanup, content workflows, and studio operations. Some of that work became cron jobs and recurring agent loops.

So Pipa moved into Slack.

Slack gives me channels for topics, threads for tasks, and a shared place to see what happened. Pipa can work autonomously, but I can still talk to her like a teammate.

Other teams are making the same move. Duolingo built an AI Slackbot with 180+ MCP tools and got to 250 weekly active users. Shopify shared River, its Slack-native agent that coauthored one in eight merged pull requests. Mintlify wrote that its docs agent runs on OpenCode and Daytona in sandboxes.

How it works

The architecture behind Pipa looks like this:

Each tool has a job.

Slack is where most work starts and answers land. It gives Pipa the message, requester, workspace, thread, and delivery target.
The gateway is the web service that receives requests. I host it on Fly. It accepts Slack events, automation API calls, trigger requests, Composio webhooks, Inngest calls, and runtime calls.
Inngest wakes work up. It handles scheduling, retries, cancellation, concurrency, and execution handoff.
E2B is the sandbox. It gives the agent its own computer to do work.
OpenCode is the agent harness. It is the brain that edits files, runs commands, calls tools, works in repos, and returns structured output.
Composio handles external triggers and tool integrations. It can wake the gateway when something happens in another app, and it makes it easy to add tool connections in Slack.

If you do not need the autonomy pieces, Slack, a sandbox, and an agent harness can get you pretty far.

Creating "autonomy"

You can stop at a setup where a Slack message starts OpenCode in a sandbox and get leverage. If you already live in Slack, that reduces friction for you and your team. Threads become workspaces. You can keep several tasks moving at once without living inside a terminal or another agent UI.

With a little more shaping, the agent can start doing more on its own.

The pieces I add after the base sandbox loop are:

Character and instruction files. OpenClaw popularized files like soul.md, heartbeat.md, and character.md. You can put the same kind of files into the OpenCode config. They shape behavior, set standards, and give the agent more personality.
Automations, workflows, and triggers. This is where I get the most benefit. Inngest wakes the agent and sandbox at a set time. Sometimes the prompt is specific: run this skill on this thing every morning. Sometimes it is more like a heartbeat: look at the current state, use judgment, and decide what needs attention. Not every run starts from time. Many SaaS tools send events. If you want the agent to wake up and execute a skill when something happens, create a trigger.
Tool access. I use Composio because it makes broad tool access easy. If I need to give the agent something, I click a link. If the agent is blocked, it can post in Slack, say what it needs, and I can connect it. A lot happens when the agent has access to the same everyday tools I use.
Skills. Agent skills teach the agent how to write things and do things. This matters more with automations, because many of my scheduled prompts look like "run this skill on this target." The skill holds the logic. The public Pipa skills live in the Pipa skills repo.
Memory. I use Supermemory for this. Before, Pipa loaded context files and knew to update them. A memory tool adds teammate-like recall: goals, preferences, latest business state, and small details that should carry across runs. Good memory tools also know how to supersede and delete memories, which matters once the agent has more autonomy.

My favorite pattern right now uses Linear. I keep a task list there, then Pipa can wake up, pick work, do it, ship it, and leave me something to review.

Why OpenCode

You could use the Claude SDK, the OpenAI SDK, LangChain, OpenClaw, Hermes, Codex, or another agent system and still use the pattern in this article.

I like OpenCode for a few reasons.

1. It is easy to reason about.

I have run experiments with OpenClaw and Hermes, and they are fun. They are also built around stronger autonomy patterns. But I have had more trouble making them execute as deterministically as a coding agent. Call it a skill issue, but OpenCode is easier for me to understand when it works and when it breaks.

2. It works for local synchronous work and "autonomous" Slack work.

My work now falls into two buckets: tasks I go deep on locally, and tasks that can run in Slack with less supervision. OpenCode gives me one harness for both. I am not learning the edges of two different systems.

3. It is open source and swappable.

I can change the model without rebuilding the runtime around another provider. I can swap models, plugins, memory tools, and sandboxes without tying the whole system to one agent ecosystem.

Conclusion

That is how I run Pipa today: Slack for the interface, a gateway for requests, Inngest for workflows, E2B for sandboxes, and OpenCode for agent work.

I am thinking about opening up the core gateway pattern. A lot can be done with OpenCode in the cloud, and I think it is underrated for this use case.

If you want to see that, drop a note.

If you want a managed agent for your studio without worrying about these pieces yourself, you can hire Pipa.

--
This post originally appeared on the Lunch Pail Labs blog

How to add Honeycomb traces to your AI Slack bot

Lola 🧱 - Lunch Pail Labs — Tue, 02 Jun 2026 22:24:00 +0000

Pipa is our agent for studio operations at Lunch Pail Labs. She lives in Slack, is powered by E2B sandboxes, and uses OpenCode for the harness.

When it works, it’s awesome. You ask for help. Pipa goes off, runs the tools, does the work, and comes back with the answer.

When 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.

If 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.

Start with the trace shape

A 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.

The shape depends on your architecture. In Pipa, a chat gateway pings an E2B sandbox, loads the right skills and templates, and runs OpenCode.

For Pipa, 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.

The 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.

For my bot, the trace includes spans like:

pipa.run.execute
pipa.e2b.sandbox.prepare
pipa.opencode.command
invoke_agent pipa.standard_opencode

The first few spans explain the backend path. The invoke_agent span explains the agent session. Inside that span, Pipa attaches events for the user message, assistant responses, tool calls, retries, and run summary.

Now the boring infrastructure stuff and the agent’s actual behavior live in the same trace.

Add the traces

1. Send OpenTelemetry traces to Honeycomb

OpenTelemetry creates and sends the trace data. Honeycomb is where I inspect it. In Pipa, the gateway sends traces to Honeycomb when HONEYCOMB_API_KEY is present.

Slack event -> gateway run -> sandbox prepare -> OpenCode command -> Slack reply

2. Create one top-level span for the agent run

For Pipa, the top-level run span is pipa.run.execute. This is the span I search for when someone says, “the bot got stuck” or “Slack never got a good answer.”

3. Add spans for the big infrastructure steps

These spans tell me whether the basic plumbing worked:

pipa.e2b.sandbox.prepare
pipa.opencode.command

They 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?

4. Add an agent invocation span for Honeycomb Agent Timeline

One thing I missed at first: traces alone do not give you an agent timeline.

You 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.

For that, you need Honeycomb’s Agent Timeline.

The 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.

A normal trace might look like:

slack.event.received -> sandbox.prepare -> opencode.command -> slack.reply.sent

An agent timeline is more like:

invoke_agent -> user_message -> assistant_response -> tool_call -> tool_result -> assistant_response -> run_summary

That 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.

As 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.

Pipa emits a Honeycomb Agent Timeline-compatible span:

invoke_agent pipa.standard_opencode

That span gets the attributes Honeycomb needs to group and display the run:

gen_ai.conversation.id
gen_ai.agent.name
gen_ai.operation.name
gen_ai.request.model
app.run_id

This is what lets Honeycomb show the agent session as a timeline instead of a pile of unrelated events.

5. Attach the agent’s activity as events

Honeycomb 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.

For Pipa, the gateway parses structured opencode run --format json output and emits events such as:

opencode.user_message
opencode.tool_call
opencode.agent_response
opencode.run_summary
opencode.parser_skipped

That makes the hidden middle visible: the prompt, assistant-visible text, tool names, tool status, token and cost data, retry markers, and failure summaries.

6. Verify with a real failed run

After adding traces, run the bot from Slack and inspect the trace in Honeycomb. The trace should answer these questions:

Did Slack reach the gateway?
Was the run created?
Did E2B prepare a sandbox?
Did OpenCode start?
What prompt did the agent receive?
Which tools did it call?
What assistant-visible text did it produce?
Did it retry?
Did the run fail or complete?
Did the Slack reply send?
Is anything sensitive leaking?

If the trace cannot answer them, add another span or event at the layer that can see the missing context.

Conclusion

If your AI bot runs inside Slack, traces are how you see what happened between the prompt and the final reply.

Start 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.

Originally published on Lunch Pail Labs.