🏗️ Monolito vs Microsservicos para Bots
O debate monolito vs microsservicos que existe no backend tradicional se aplica diretamente ao mundo dos bots. Um unico bot que faz tudo e o monolito. Varios bots especializados sao os microsservicos. E a mesma tensao, os mesmos trade-offs, as mesmas armadilhas.
🎯 Conceito Principal
Um bot monolito centraliza tudo num unico processo: system prompt, tools, memoria, contexto. Ele e simples de deployar, simples de debugar e simples de entender. Mas tem um teto. Quando voce adiciona a decima funcionalidade, o system prompt vira uma biblia e o modelo comeca a se confundir sobre qual personalidade usar.
Um sistema multibot (microsservicos) distribui responsabilidades. Cada bot tem escopo reduzido, prompt curto e tools limitadas. O custo e a complexidade de orquestracao: routing, comunicacao entre bots, estado compartilhado, deploy de multiplos servicos.
- • Monolito: 1 processo, 1 system prompt, N tools. Deploy simples. Complexidade interna cresce linearmente com features
- • Microsservicos: N processos, N prompts, tools distribuidas. Deploy complexo. Complexidade interna de cada bot permanece baixa
- • Trade-off real: simplicidade de operacao vs qualidade de resposta. Nao existe resposta certa universal
📦 Bot Monolito
- + 1 deploy, 1 processo, 1 banco
- + Contexto 100% compartilhado
- - Prompt enorme = confusao do modelo
- - Uma falha derruba tudo
🔀 Sistema Multibot
- + Cada bot e excelente no seu dominio
- + Falha isolada, nao derruba o sistema
- - Router adiciona latencia e complexidade
- - Estado compartilhado exige infra extra
💡 Quando a Simplicidade Ganha
Em 80% dos casos, comece com monolito. Se voce esta lancando um MVP, tem um time pequeno, ou o bot atende um unico dominio com variacao (exemplo: suporte tecnico com FAQ, tickets e troubleshooting), um bot unico bem construido vai ser mais rapido de entregar, mais facil de manter e mais barato de operar. Microsservicos sao a resposta certa para o problema errado se voce nao tem escala.
🚧 Limites do Assistente Unico
Todo bot unico tem um ponto de ruptura. Nao e uma questao de "se", e "quando". Entender os sinais de que voce atingiu o limite e o que separa um desenvolvedor que escala de um que fica preso refatorando.
🎯 Conceito Principal
Os LLMs tem limites cognitivos praticos que aparecem muito antes de atingir o limite de tokens. Um system prompt com 50 instrucoes conflitantes produz respostas piores que um com 10 instrucoes claras, mesmo que o modelo tenha capacidade de processar ambos.
Os tres limites criticos sao: saturacao de contexto (informacao demais no prompt), confusao de papel (personalidades conflitantes) e sobrecarga de tools (muitas ferramentas disponíveis). Qualquer um deles degrada a qualidade significativamente.
Saturacao de Contexto
Mesmo com janelas de 128k ou 200k tokens, modelos perdem acuracia em instrucoes que estao no "meio" do contexto (o famoso problema "lost in the middle"). Um system prompt de 5000 palavras com 30 regras diferentes garante que o modelo vai ignorar ou misturar pelo menos algumas delas.
Confusao de Papel (Role Confusion)
Quando o system prompt diz "seja empatico e acolhedor para suporte" mas tambem "seja assertivo e direto para vendas", o modelo fica preso entre personalidades. O resultado e um bot que nao e bom em nenhuma das duas coisas. E pior: o usuario percebe a inconsistencia.
Sobrecarga de Tools
Cada tool no schema consome tokens e adiciona complexidade de decisao. Com 5 tools, o modelo escolhe bem. Com 25 tools, ele comeca a chamar a tool errada, inventar parametros, ou ignorar tools disponiveis. O Claude Agent SDK, por exemplo, funciona melhor com tools focadas por contexto.
📊 Metricas de Degradacao
- • System prompt > 1500 palavras: qualidade comeca a cair perceptivelmente. Acima de 3000, cai drasticamente
- • Tools > 15: taxa de selecao correta cai de ~95% para ~78% (benchmark interno com Claude Sonnet)
- • Dominios > 3 distintos: confusao de papel aparece em ~20% das respostas
- • Conversas > 50 turnos: instrucoes do system prompt sao progressivamente ignoradas
💡 Dica Pratica
Meca antes de migrar. Crie um test suite com 50 mensagens reais dos seus usuarios. Rode contra o bot unico. Se a taxa de acerto (resposta correta + tom correto + tool certa) cai abaixo de 85%, voce tem evidencia concreta para justificar a migracao para multibot. Sem dados, voce esta adivinhando.
🎯 Vantagens de Multiplos Assistentes
Quando a complexidade justifica, um sistema multibot desbloqueia capacidades que um monolito nunca vai ter. Nao e so sobre qualidade de resposta. E sobre escalabilidade, testabilidade, custo e resiliencia.
🎯 Conceito Principal
Multiplos assistentes seguem o principio da responsabilidade unica (Single Responsibility Principle) aplicado a IA. Cada bot sabe fazer uma coisa extremamente bem. O resultado e que a soma das partes e maior que o todo: um sistema com 4 bots especializados supera um unico bot tentando ser os 4.
As vantagens se dividem em cinco categorias: especializacao (qualidade), paralelismo (velocidade), testabilidade (confiabilidade), escalabilidade independente (custo) e isolamento de falhas (resiliencia).
Especializacao
System prompts curtos e focados produzem respostas melhores. Um bot de suporte com 200 palavras de instrucao supera um bot generalista com 2000 palavras na mesma tarefa.
Processamento Paralelo
Bots independentes processam mensagens simultaneamente. Enquanto o bot de suporte responde um ticket, o bot de vendas qualifica outro lead. Zero contenco de recursos.
Testabilidade
Testar um bot com escopo reduzido e ordens de magnitude mais facil. 50 test cases por dominio cobrem 95% dos cenarios. Para um bot generalista, voce precisaria de 200+ test cases com combinacoes explosivas.
Escalabilidade Independente
Bot de suporte recebe 10x mais mensagens na Black Friday? Escala so ele. Nao precisa escalar vendas, conteudo ou operacoes junto. Cada bot tem seus proprios recursos e limites.
🛡️ Isolamento de Falhas
No monolito, se a API do OpenAI cai, tudo para. No multibot, se o bot de conteudo (que usa Claude) cai, o bot de suporte (que usa Ollama local) continua funcionando normalmente. Falhas sao contidas no bot afetado.
💡 Dica Pratica
Misture modelos por funcao para otimizar custo. Suporte com FAQ repetitivo? Ollama local, custo zero. Vendas que precisa ser persuasivo? GPT-4o ou Claude Sonnet. Pesquisa que precisa de raciocinio? DeepSeek-R1 via OpenRouter. Um sistema multibot te da essa flexibilidade. Um monolito te prende num modelo so.
📐 Criterios de Decisao
A decisao entre bot unico e multibot nao e tecnica, e de negocio. Depende do seu time, do seu orcamento, da complexidade do produto e das necessidades reais dos usuarios. Use uma matriz de decisao, nao o instinto.
🎯 Conceito Principal
Quatro fatores determinam se voce precisa de 1 bot ou varios: tamanho do time (quem vai manter isso?), complexidade do dominio (quantas funcoes distintas?), orcamento (quanto pode gastar em infra e APIs?) e necessidades do usuario (o usuario percebe diferenca?).
A regra de ouro: comece com 1 bot. Divida quando a dor aparecer. A dor aparece na forma de respostas ruins, usuarios insatisfeitos, system prompt incontrolavel ou impossibilidade de testar adequadamente.
📊 Matriz de Decisao
| Fator | Bot Unico | Multibot |
|---|---|---|
| Time | 1-2 devs | 3+ devs |
| Dominios | 1-2 relacionados | 3+ distintos |
| Tools | Ate 10 | 15+ |
| Usuarios | Ate 500/dia | 1000+/dia |
| Budget | $0-500/mes | $500+/mes |
| Personalidades | 1 tom consistente | Tons conflitantes |
| SLA | Tolerante a downtime | 99.9% uptime |
🔄 Fluxo de Decisao Rapido
💡 Dica Pratica
Documente a decisao. Escreva um ADR (Architecture Decision Record) de 1 paragrafo: "Escolhemos [bot unico/multibot] porque [criterio 1], [criterio 2], [criterio 3]. Revisaremos quando [gatilho]." Isso evita debates circulares no futuro e da contexto pra quem entrar no time depois.
🔀 Padroes de Migracao
A migracao de bot unico para multibot nunca deve ser big bang. Nao desliga o monolito na sexta e liga o multibot na segunda. A evolucao e gradual, por etapas, com rollback possivel em cada passo.
🎯 Conceito Principal
A migracao segue tres etapas: extrair por dominio (tirar o primeiro especialista do monolito), introduzir router (classificar para onde cada mensagem vai) e compartilhar estado gradualmente (mover contexto e memoria para camada compartilhada).
Cada etapa deve ser reversivel. Se o bot especialista piorar a experiencia, voce redireciona de volta pro monolito sem downtime. Feature flags sao seus melhores amigos nessa transicao.
Extrair por Dominio
Identifique o dominio mais independente do seu bot. Aquele que tem menos dependencia de contexto compartilhado. Extraia ele para um processo separado com seu proprio system prompt e tools.
Introduzir Router
Quando voce tem 2+ bots, precisa de um classificador. Comece com keyword matching simples. Evolua para LLM-based quando as keywords nao forem suficientes.
Compartilhar Estado Gradualmente
O maior desafio do multibot: como os bots compartilham contexto? O usuario comeca no suporte e migra pra vendas. O bot de vendas precisa saber o que aconteceu. Solucoes: banco compartilhado, message passing, session store.
🚨 Evite Big Bang
Nunca reescreva tudo de uma vez. A maioria dos fracassos de migracao acontece quando o time tenta fazer a transicao completa num sprint. Extraia um dominio por vez. Valide por 1-2 semanas. So entao extraia o proximo. Se levar 3 meses, tudo bem. Melhor lento e funcionando que rapido e quebrado.
💡 Dica Pratica
Use feature flags para cada rota. ROUTE_FAQ_TO_SPECIALIST=true no .env. Se o especialista der problema, basta mudar pra false e a mensagem volta pro monolito. Sem deploy, sem downtime, sem stress.
🏗️ Exercicio: Avaliar seu SaaS
Teoria sem pratica e entretenimento. Nesse exercicio voce vai analisar seu proprio produto (ou um produto ficticio) e documentar a decisao arquitetural com criterios concretos.
Exercicio: Decisao Arquitetural do Bot
Tempo estimado: 20-30 minutos
Mapeie os Dominios
Liste todas as funcoes que seu bot precisa atender. Agrupe por dominio. Identifique quais dominios tem requisitos conflitantes.
Preencha a Matriz de Decisao
Para cada fator da matriz (time, dominios, tools, usuarios, budget, personalidades, SLA), marque onde seu caso se encaixa.
Defina o Plano de Migracao (se aplicavel)
Se a decisao for multibot, documente: qual dominio extrair primeiro, como sera o router, qual modelo cada bot usa.
Escreva o ADR (Architecture Decision Record)
Documente a decisao em 1 paragrafo. Inclua: decisao, justificativa e gatilho de revisao.
✅ Criterios de Sucesso
🌟 Bonus
Crie um diagrama de arquitetura do seu sistema (pode ser ASCII art, draw.io ou Excalidraw). Mostre: entrada do usuario, router (se multibot), bots, banco de dados, APIs externas. Esse diagrama vai ser a referencia visual pra todo o time.