🏗️ Implementar Multibot

Antes de escrever uma linha de codigo, voce precisa de um plano claro. Sistemas multibot falham mais por falta de planejamento do que por problemas tecnicos. O planejamento comeca com uma pergunta simples: quais problemas este sistema vai resolver? Nao "quais tecnologias vou usar" ou "quantos bots vou ter". A resposta define tudo que vem depois: quantos bots, quais responsabilidades, como se comunicam, e onde rodam.

O mapeamento de bots segue o principio da separacao de responsabilidades. Cada bot deve ter um dominio claro e bem definido. Se voce nao consegue descrever o que um bot faz em uma frase, ele provavelmente esta fazendo coisas demais. Exemplos de dominios bem definidos: "responde perguntas sobre codigo e desenvolvimento", "gerencia emails e comunicacoes", "pesquisa e sintetiza informacoes da web", "monitora servicos e infraestrutura".

O diagrama de arquitetura e o artefato mais importante do planejamento. Ele mostra: os bots (com seus nomes e responsabilidades), os canais de entrada (Telegram, Slack, webhook), o router (como mensagens sao classificadas e encaminhadas), as dependencias externas (APIs, bancos de dados, LLMs), e os fluxos de comunicacao entre componentes. Desenhando isso antes de codar, voce evita refatoracoes caras depois.

O router e o cerebro do sistema multibot. Ele recebe cada mensagem do usuario, classifica a intencao, e encaminha para o bot especialista correto. Um bom router e rapido, preciso, e tem fallbacks inteligentes. Um router ruim manda mensagens pro bot errado e frustra o usuario. A qualidade do router determina a qualidade de todo o sistema.

Existem tres abordagens principais para classification. A mais simples e regex/keyword matching: se a mensagem contem "codigo", "debug", "deploy", vai para o bot de desenvolvimento. E rapido e gratuito, mas fragil com linguagem natural ambigua. A segunda e LLM classification: voce envia a mensagem para um modelo leve (como Llama 3.2 3B ou Qwen 2.5 7B) com um prompt que pede para classificar em categorias. E mais preciso mas adiciona latencia e custo. A terceira e hybrid: tenta regex primeiro, e se nao encontra match com confianca alta, usa LLM como fallback.

O conceito de confidence threshold e essencial. Quando o router classifica uma mensagem, ele deve retornar nao apenas a categoria mas tambem um nivel de confianca. Se a confianca esta acima do threshold (ex: 80%), encaminha diretamente. Se esta entre 50-80%, pode pedir confirmacao ao usuario. Se esta abaixo de 50%, vai para o bot default. Sem threshold, o router vai forcar classificacoes incorretas em mensagens ambiguas.

Cada bot especialista e um agente autonomo com sua propria personalidade, conhecimento de dominio, conjunto de skills, e backend de LLM. A chave e que cada especialista seja realmente bom no seu dominio especifico, nao mediocre em tudo. Um bot de desenvolvimento que conhece seu stack tecnico, suas convencoes de codigo, e seus repositorios e infinitamente mais util que um chatbot generico que sabe um pouco de tudo.

O deploy de especialistas pode ser feito de duas formas. Na forma monolitica, todos os bots rodam no mesmo processo Node.js, como modulos diferentes. E mais simples de gerenciar mas tem o risco de um bot crashar todo o sistema. Na forma distribuida, cada bot e um processo separado, comunicando via HTTP/WebSocket ou fila de mensagens. E mais resiliente mas mais complexo de operar. Para comecar, monolitico e a escolha certa. Distribua quando tiver necessidade real.

A personalidade de cada bot e definida em seu proprio arquivo de configuracao (como um CLAUDE.md especifico). O bot de desenvolvimento deve ter tom tecnico, direto, e conhecer os frameworks que voce usa. O bot de pesquisa deve ser investigativo, citar fontes, e admitir quando nao tem certeza. Essas personalidades diferentes nao sao frescura estetica. Elas melhoram a qualidade das respostas porque o LLM se comporta diferente com system prompts diferentes.

Multi-channel deployment significa que seu sistema multibot pode receber mensagens de diferentes plataformas: Telegram, Slack, Discord, WhatsApp, webhooks HTTP, ou ate email. O desafio nao e tecnico (APIs existem para todas essas plataformas). O desafio e normalizacao: cada plataforma envia mensagens em formatos diferentes, com capacidades diferentes, e limitacoes diferentes. O sistema precisa abstrair essas diferencas.

A camada de normalizacao transforma mensagens de qualquer canal em um formato interno padrao. Esse formato deve conter: texto da mensagem, ID do usuario, canal de origem, timestamp, e metadados opcionais (se tem midia, se e reply, etc.). Quando o bot responde, uma camada de formatacao faz o caminho inverso: transforma a resposta interna no formato especifico do canal. Telegram suporta markdown, Slack usa blocks, Discord tem embeds. A mesma resposta e formatada diferente para cada destino.

Para webhooks, voce expoe um endpoint HTTP que recebe eventos de servicos externos. Isso permite integracoes como: GitHub envia um webhook quando um PR e aberto, o sistema processa e notifica via Telegram; um servico de monitoramento detecta downtime e dispara um webhook que aciona o bot de ops. Webhooks transformam o sistema de passivo (espera mensagens do usuario) em ativo (reage a eventos externos).

Testar um sistema multibot e diferente de testar software tradicional. Voce tem componentes nao-deterministicos (LLMs retornam respostas diferentes para o mesmo input), dependencias externas (APIs de terceiros), e fluxos complexos que atravessam multiplos servicos. Testes tradicionais de "input X = output Y" nao funcionam aqui. Voce precisa de estrategias adaptadas.

Conversation tests sao testes que simulam conversas reais. Voce define um script com mensagens do usuario e verifica que: a mensagem foi roteada para o bot correto, a resposta contem os elementos esperados (nao a resposta exata, mas palavras-chave ou patterns), e o sistema nao crashou. Esses testes cobrem o fluxo principal: mensagem entra, router classifica, especialista responde, resposta volta ao canal.

Load tests verificam como o sistema se comporta sob pressao. O que acontece se 10 mensagens chegam ao mesmo tempo? E 100? O Ollama local aguenta? As filas de processamento funcionam? O timeout esta configurado corretamente? Load tests revelam gargalos que so aparecem em producao: memory leaks, connection pool exhaustion, rate limiting de APIs.

Este e o exercicio final da Trilha 5. Voce vai construir um sistema multibot funcional completo: router inteligente + 2 bots especialistas + 1 canal, tudo funcionando e testado. Ao final, voce tera um sistema que recebe mensagens, classifica intencoes, roteia para o bot certo, e retorna respostas especializadas. Isso e o que empresas cobram milhares de dolares para implementar.

O exercicio consolida tudo que voce aprendeu na Trilha 5: arquitetura multibot (Modulo 5.1-5.2), patterns de comunicacao (Modulo 5.3), protocolos de coordenacao (Modulo 5.4), frameworks de bot pessoal (Modulo 5.5), e deployment (Modulo 5.6). Cada um desses modulos forneceu uma peca do quebra-cabeca. Agora voce vai montar todas juntas.

Tempo estimado: 2-4 horas para o setup completo, mais 1-2 horas para testes e refinamento. Se voce ja completou o exercicio do Modulo 5.5 (setup de framework), grande parte da infraestrutura ja esta pronta. O foco agora e adicionar o router e o segundo especialista.