One queue for the Slack message, the Sentry error, and the GitHub issue

Slack intake: a message in a channel becomes a ticket with context, status, and an owner, without making the person leave the channel. Sentry: Tux AI triages the error and folds duplicate events into the one item, so a noisy release does not become fifty tickets. GitHub: the ticket and the issue sync both ways, so the engineer is not copying status back into chat. WhatsApp is on the integration surface for teams whose internal requests do not all start in Slack.

That list is the list. We are not claiming a connector for every tool drawn on a whiteboard. Jira can stay the service desk of record. PagerDuty can stay the thing that pages a human at 2am. Linear can stay where product work is tracked after someone has decided the bug is real. FlowTux is the queue in front of Slack, Sentry, and GitHub.

Tux reads the incoming issue, classifies it, and resolves the routine ones before a person opens them. Priority follows what the issue affects, not which channel was loudest. Duplicate Sentry events collapse. The point of the first month is to watch what it closed and decide whether you agree.

Do not start by pointing it at incident declaration and customer communication. Those stay with a person. Start with the questions the team answers from a runbook: how do I get access, why did this job fail, is this the same error as yesterday. If a class of ticket should never close without a human, say so before you turn the automation on. We will shape that boundary. We will not promise an unbounded agent that merges code on its own.

Per-agent helpdesks get expensive the moment a second team is allowed to file. FlowTux is a flat $99 a month up to 50 members. The intern can open a ticket. You are not billed again for the seat.

Connect one source first. Slack, or Sentry, not both plus GitHub plus a migration of the old helpdesk on the same Friday. Measure whether duplicates drop and whether the right person is named. Add the next source after that is true.

FlowTux is internal support. If the thing your team is shipping is a real-time voice or streaming product, the routing problem is different: Twilio sending mulaw, Deepgram wanting PCM, an LLM stream that has to fan out, webhooks from Stripe or GitHub that each have their own shape. That product is HZRelay, in private preview, one session model and one SDK. It is described on its own page. Do not buy FlowTux expecting it to be the media router.