1
6 Comments

Built Huddle, an AI that lives in your group chat and only talks when tagged

Hey IH, been heads down on Huddle for a while and wanted to share it here.

What it does: you add Huddle to a group chat on Slack, Google Chat, or Telegram. It reads along for context but doesn't say anything until someone @mentions it. Then it answers with sources, whether that's settling an argument, checking a live stat or price, or catching someone up on a thread they missed.

Why I built it: my own group chats kept getting stuck in the same loop, someone states something confidently, someone else disagrees, and the conversation stalls because nobody wants to be the one who stops to go verify it. Figured the group chat itself should just be able to answer that.

It's live now at huddle-hq.com and launching on Product Hunt in a few days. Would really value feedback from this crowd, especially if you've tried building or using bots that live inside group chats before, what broke, what people actually used vs ignored.

on August 15, 2026
  1. 1

    For anyone landing here after the PH launch: it's live at huddle-hq.com, one-click install for Slack, Google Chat and Telegram take a couple minutes. Still reading every comment on this thread.

  2. 1

    For anyone landing on this post after the PH launch: the live version is at huddle-hq.com if you want to see it before adding it to a chat, one-click install for Slack, and Google Chat/Telegram take a couple minutes. Still reading every comment on this thread and would love more of the permission-model style feedback above, that's shaping what ships next.

  3. 1

    The activation risk is asking a group to trust a bot that reads everything before they have felt any value. I would make permissions explicit, offer a narrow onboarding mode such as thread catch-up only, and show what context was used with every answer. Track weekly groups with a second tagged query, not installations. A group that invokes it twice has crossed the trust barrier; an installed bot with no repeat use has not.

    1. 1

      Really good framing, and honestly the trust barrier line is going to stick with me. We already default to a fairly narrow footprint, it only reads context in the chat it is added to and only responds when tagged, but making that permission explicit up front instead of assuming people will just trust it is a fair callout. The idea of tracking a second tagged query as the real activation metric instead of installs is smart too, we have mostly been watching installs and first response quality, not repeat taps. Going to steal that framing internally.

      1. 1

        That is the right next step. Make the permission model part of onboarding in one screen: what Huddle reads, when it listens, what it stores, and how to remove it. Then define activation as a second tagged query within seven days and segment that by group type. That will show where Huddle earns both trust and repeat utility.

        1. 1

          Appreciate you spelling that out concretely. The one-screen breakdown (what it reads, when it listens, what it stores, how to remove it) is exactly the kind of explicit framing we've been missing, right now that information exists but it's scattered across the docs and the setup flow instead of being one clear moment. Segmenting the seven-day repeat-query metric by group type is the part I hadn't thought to slice that way, most of our early read has been aggregate, so a team chat and a friend-group chat get treated the same even though they'll obviously behave differently. Going to bring both of these into how we're rebuilding onboarding. Thanks for actually sitting with the problem instead of just reacting to the pitch.