Um agente, três canais, três integrações que não se falam
A empresa decide colocar um agente de IA no WhatsApp. Alguém escreve o webhook, trata o formato específico da Meta, guarda sessão em uma tabela improvisada. Funciona. Três meses depois o time comercial pede o mesmo agente no Slack. Copia o código do WhatsApp, adapta os nomes dos campos, duplica a lógica de sessão. Mais adiante entra o Discord da comunidade. Agora são três integrações que fazem a mesma coisa de três jeitos diferentes, e qualquer mudança na regra do agente precisa ser replicada três vezes, torcendo para não esquecer nenhuma.
Esse é o problema que todo time que constrói agente multicanal encontra, e é também o problema que um projeto pessoal resolveu de um jeito que virou o repositório de crescimento mais rápido da história do GitHub.
O gateway que virou o maior fenômeno do GitHub
O OpenClaw nasceu como projeto de fim de semana de Peter Steinberger, criador da PSPDFKit, lançado publicamente em 25 de janeiro de 2026. No primeiro dia já tinha 9 mil estrelas. Hoje, 21 de agosto de 2026, o repositório oficial soma 387 mil estrelas, checado direto na página do projeto no GitHub. Sete meses para passar de um hack de fim de semana a um dos softwares mais observados do ano, sem financiamento, sem equipe de vendas, sem departamento de marketing.
O que o OpenClaw faz não é sofisticado no papel: ele conecta um mesmo assistente de IA a WhatsApp, Telegram, Slack, Discord, Google Chat, Signal e iMessage. A parte interessante não é a lista de canais, é como ele evita reescrever a lógica do agente sete vezes. No centro do sistema fica o que o próprio projeto chama de Gateway: um processo local que administra sessão, ferramentas, eventos e conexão de canal em um lugar só. Cada canal vira um adaptador fino que só traduz o formato daquele app para um evento comum. O agente nunca sabe se está conversando por WhatsApp ou por Discord, ele só recebe uma mensagem normalizada e responde com uma ação normalizada.
Canal fora, evento dentro
O nome técnico para isso é padrão gateway, e não é novidade nenhuma: é o mesmo raciocínio por trás de um API gateway na frente de microsserviços. O que muda é onde a maioria dos times de IA aplica esse raciocínio: quase ninguém aplica, porque o primeiro canal sempre parece um caso isolado que não merece abstração.
Uma versão simplificada do formato de evento seria algo assim:
{
"canal": "whatsapp",
"usuario_id": "55829999xxxx",
"sessao_id": "sess_8f3a",
"tipo": "mensagem",
"conteudo": "quero rastrear meu pedido",
"metadados": { "nome": "Carla" }
}
O adaptador do WhatsApp recebe o payload feio da Meta e produz esse evento. O adaptador do Slack recebe o payload feio da API do Slack e produz o mesmo evento, com canal: "slack". O agente processa um formato só, guarda sessão em um formato só, e a regra de negócio muda em um lugar só quando o cliente pede um ajuste. Trocar de canal, adicionar canal ou mover o agente inteiro para outro provedor de modelo vira trabalho no adaptador, não reescrita do agente.
Quando vale montar o gateway, e quando não vale
Nem todo projeto precisa disso no primeiro dia. Um piloto de duas semanas com métrica única, rodando só no WhatsApp, não ganha nada com uma camada de abstração que ninguém vai testar.
| Situação | Ponto a ponto | Gateway |
|---|---|---|
| Um canal, prazo curto, escopo fechado | Mais rápido de entregar | Overhead sem retorno |
| Dois ou mais canais confirmados no roadmap | Duplica lógica a cada canal novo | Paga o investimento já no segundo canal |
| Cliente pede trocar de modelo ou provedor depois | Reescreve integração inteira | Troca só a camada de agente, adaptador fica igual |
| Times diferentes mantendo canais diferentes | Cada time reinventa sessão e retry | Um contrato de evento para todo mundo |
O critério prático é simples: se o piloto tem um canal e uma métrica, construa direto e não pense em gateway. No momento em que a proposta do cliente menciona o segundo canal, ou quando o mesmo agente vai atender WhatsApp da equipe de vendas e Slack interno do time de suporte, o gateway deixa de ser elegância de arquitetura e vira a diferença entre manter um sistema e manter três.
O próprio crescimento do OpenClaw é evidência indireta disso: a comunidade que built em cima dele mantém hoje um marketplace de plugins, o ClawHub, porque quem contribui não precisa entender o app de mensagens de ninguém, só o contrato do Gateway. Separar canal de lógica é o que permite terceiro construir sem pedir acesso ao código do agente.
O que fazer na segunda de manhã
Abra o agente que a empresa já tem em produção e responda uma pergunta: se o cliente pedir amanhã para o mesmo agente responder também no Slack interno, quanto código precisa ser reescrito? Se a resposta for "quase tudo", vale um dia de trabalho isolando o contrato de evento entre canal e lógica de agente, mesmo que hoje exista um canal só. Não é sobre prever o futuro, é sobre não pagar duas vezes pelo mesmo agente quando o segundo canal chegar, porque ele chega.
A Overflow constrói agentes de IA e automação com esse tipo de decisão de arquitetura desde o diagnóstico, antes da primeira linha de código: conheça o trabalho de IA e automação da Overflow.
