By David Steinacher and Roland Kákonyi
TL;DR
- We built a Slack-native AI agent called Hummer during Bitmovin’s Q2 2026 hackathon that works only in public channels, so the whole team can see, learn from, and contribute to every session.
- It connects to GitHub, Google Workspace, Bitmovin’s docs, and Jira, and has a hierarchical memory system that gets smarter the more the team uses it.
- During the live demo, it took a Jira ticket, implemented a new SwiftUI picture-in-picture API for Bitmovin’s Player SDK, opened a pull request, caught its own lint failures, and applied code structure it had learned from the previous day’s session, all without being re-prompted.
Most AI coding tools are built around a single user. You work with the agent in a private window, and when the session ends, everything it learned stays with you. The next person on the team starts from zero. That bothered us, so for Bitmovin’s Q2 2026 hackathon we decided to build something different.
In this post we walk through Hummer, a Slack-native AI agent that works only in public channels, what we built, how it works, and what happened when we ran it live.
Hummer: Slack-native agent work, in public
Where the idea came from
The idea started with a simple observation: teams learn collectively, but most AI workflows do not. Valuable prompts, decisions, and lessons often stay inside individual sessions, making them difficult for others to discover or build upon. For our Q2 2026 hackathon, we wanted to explore whether an AI agent could become a shared team resource rather than just another personal productivity tool.
Then Tobi Lütke posted about Shopify’s internal Slack agent, River. The thing that stood out was not what it could do, but that it only works in public channels. All the prompts, all the back-and-forth, all the debugging happens where anyone can watch. We thought that was the right approach, so we built our version of it.
How it works
Hummer runs via Slack’s Socket Mode, which means it can run from anywhere and scale across multiple instances if needed. Mention @Hummer in any public channel with the suffix _hummer and it spins up a worker scoped to that thread. The conversation stays there, other people can jump in, and everything is visible and searchable.
We gave it access to the tools it would actually need to do engineering work:
- GitHub access to our engineering org, so it can read tickets, write and commit code, open pull requests, and monitor CI checks.
- Google Workspace, so you can share a doc or sheet and ask questions about it directly in Slack.
- Our documentation via an MCP integration, so it can look things up without being told where to search.
- Slack message lookup, so you can drop a link to any public message and it pulls that context in.
- An attachment service for images and files sent directly in Slack.
- LangFuse for session tracing and duration tracking, which also lets us monitor token costs if we want to.
Sessions persist to SQLite and sync to Google Cloud, so nothing is lost between runs and we could move it to a full cloud deployment without much work.
Hummer runtime architecture, showing Slack entry, Socket Mode runtime, job workers, Pi Agent session, and durable state integrations
The memory system
The part we spent the most time on was memory. We wanted it to actually get better the more the team uses it, not just within a session but across them. So we built a hierarchical memory system with three levels:
- User-level memory for individual preferences, things like commit message format or which patterns someone prefers.
- Channel-level memory for context that is relevant to a specific topic or team area.
- Zone-level memory scoped to a project, so if you tell it “whenever you work on the iOS Player, follow these conventions,” that applies to everyone who uses Hummer in that context, not just you.
All memories are human-readable and editable. If it learns something wrong, you can fix it. That felt important, since the last thing you want is an agent quietly carrying forward a bad assumption.
What we showed in the demo
We started the demo before the presentation because it genuinely takes time to run. The task was implementing a new SwiftUI API on Bitmovin’s Player SDK to add picture-in-picture support, something the iOS SDK did not yet have for SwiftUI.
We gave Hummer the Jira ticket, it summarized the work, formed a plan, and we told it to go ahead. About five minutes later it had opened a pull request. The first attempt had SwiftLint violations and did not build, but Hummer tracked the CI failures itself and went back to fix them without us having to say anything.
The detail that got the most reaction: it extracted the new API code into a separate file, which is exactly how we had structured the scaling mode modifier the day before. It had picked that up from the previous session’s public thread and applied it on its own. That is the whole point of working in public.
Why public-only matters
The decision to make Hummer public-only was deliberate. Hummer is restricted to public channels by code and by permissions, it literally cannot read DMs or private channels, so the openness is not optional.
The practical effect is that every session is a record of how the team is using AI: what they ask, what works, what the agent learned. Anyone can read those threads, anyone can jump in and help steer, and the agent carries the useful parts forward into the next session. The more the team uses it, the better it gets for everyone.
Where things stand
Right now Hummer runs on a MacBook in the office. That is partly pragmatic: iOS development needs local macOS, and getting that working in the cloud is its own project. The backend is already syncing to Google Cloud though, so moving it when we are ready is straightforward.
We built this in a 2-day hackathon window. The core architecture is solid and the demo held up, which tells us the approach works. The bigger question is how much it keeps learning as more of the team uses it. That part we are genuinely curious to find out.
