Uma plataforma de IA omnichannel, do primeiro commit à produção

O problema

Pequenas e médias empresas no Brasil fazem atendimento pelo WhatsApp. Os times estão sobrecarregados, a resposta depende de quem está no turno e os gestores têm pouca visibilidade sobre a qualidade.

Construímos a resposta como uma joint venture com um provedor de cloud brasileiro: agentes de IA que conhecem cada negócio, respondem na hora em todos os canais e passam a conversa para uma pessoa quando devem. Eu lidero engenharia e produto, da arquitetura à produção.

Arquitetura

Três serviços principais e alguns menores. Não é um sistema de microsserviços, de propósito: só separamos serviços onde o runtime precisa ser diferente.

• API da plataforma (NestJS). Um monólito modular responsável por tenants, autenticação, inbox em tempo real e todas as integrações. PostgreSQL via Prisma, BullMQ no Redis para trabalho em segundo plano e Socket.IO para tempo real.
• Motor de IA (Python, FastAPI e LangGraph). Sem estado. Cada requisição chega com o contexto de que precisa e sai com uma decisão. Cada fluxo de IA é um grafo LangGraph próprio.
• Gateway de WhatsApp (Go). Um serviço enxuto que gerencia as conexões do WhatsApp e envia webhooks assinados para a API.
• Clientes. Um app web em Nuxt para os times e um widget de chat para sites.

Como uma conversa é tratada

1. Buscar. O agente consulta o conhecimento da própria empresa (RAG agêntico no Qdrant), isolado por tenant.
2. Agir. O modelo pode chamar ferramentas em um loop limitado, incluindo as ferramentas SaaS conectadas pelo cliente e a passagem para um humano.
3. Checar. A resposta é validada antes de sair. Se o agente não consegue responder com segurança, uma pessoa assume.

Decisões que valem explicar

1. Um monólito modular, não microsserviços

   Para um time pequeno, fronteira de rede custa mais do que protege. As fronteiras entre módulos são garantidas por regras de lint nos imports, e só separamos serviços onde o runtime muda: Python para IA, Go para WhatsApp.

   Trade-offA maior parte da plataforma é uma unidade de deploy só, então os deploys precisaram ficar entediantes e seguros. Isso virou um projeto próprio: deploys sem downtime.

2. Uma camada de LLM independente de provedor

   OpenAI, Anthropic, Gemini e xAI ficam atrás de uma interface única, com fallback quando um provedor falha. Nenhuma funcionalidade depende de um fornecedor só.

   Trade-offOs fluxos usam os recursos que todos os provedores têm em comum, a não ser que um deles opte explicitamente por algo específico de um provedor.

3. MCP para integrações, controlado pela plataforma

   As ferramentas SaaS dos clientes se conectam via MCP. A plataforma decide o que cada conversa pode usar, e o motor de IA só executa as chamadas. Quando uma ferramenta está indisponível, a conversa vai para um humano em vez de falhar em silêncio.

4. Assumir a camada de WhatsApp

   Começamos com um gateway de WhatsApp de terceiros. Ele era pesado e fazia muito mais do que precisávamos. Troquei por um serviço enxuto em Go: só as operações que usamos, com reconexão supervisionada.

   Trade-offEle roda como instância única, de propósito. Uma conexão de WhatsApp só pode ficar com um processo por vez, então esse serviço reinicia de forma graciosa em vez de usar blue-green.

5. Saber quanto custa cada conversa

   Cada requisição de IA é medida por cliente e conciliada com o que os provedores de modelo cobram de fato, então o custo de uma conversa é medido, não estimado.

Resultado

A plataforma roda em produção para clientes empresariais e vai ao ar várias vezes por dia, com deploys sem downtime.

Nomes de clientes, volumes, números financeiros e detalhes internos do produto não são divulgados. O código é privado.