Talk | ExpoStacker

PRODUTO EM PRODUÇÃO

talk.expostacker.com.br

live preview

Talk — Agentes de IA para WhatsApp

Usar agora Arquitetura

Stack tecnológica: IA WhatsApp Business API Multi-tenant LLM RAG Cloudflare Workers

4
Planos: 6
Passos onboarding: 100%
Tenant isolado

Cliente

Talk

Setor

SaaS e IA Conversacional

Linha do tempo

Iteracao continua · 2026-09

Produto ao vivo

Usar agora

Resultados

Resultados reportados pelo cliente durante o rollout

4 Planos comerciais

6 Passos de onboarding

100 % Tenant isolado

Dados reportados pelo cliente

O desafio

Talk e a plataforma da ExpoStacker para agentes de IA no WhatsApp Business. Diferente de bots que usam bibliotecas nao oficiais — e terminam banidos pela Meta — o Talk roda sobre a Cloud API oficial: cada empresa tem um tenant isolado, um agente com tom e politicas configuraveis, knowledge base propria e um kill switch sempre a mao.

Pequenas e medias empresas querem atendimento automatico no WhatsApp, mas automacao com bibliotecas nao oficiais gera banimento da Meta. Era preciso um produto que usasse a API oficial, isolasse dados por empresa, desse controle real ao dono (kill switch, handoff, politicas) e respondesse com base no catalogo real — nunca inventando preco ou estoque.

A abordagem

Plataforma SaaS multi-tenant sobre a WhatsApp Business Cloud API oficial da Meta. Cada tenant tem agente de IA com guardrails: o LLM gera texto, mas codigo decide desconto, estoque e preco a partir do catalogo real (StackPost). Inbox unificada com estado AI/humano por thread, score de lead, handoff com contexto e resumo, knowledge/RAG por empresa, opt-out STOP/PARAR, supressao e kill switch por tenant. Onboarding self-service em 6 passos e planos comerciais via StackPost.

A solução

O produto combina LLM para linguagem natural com codigo determinista para regras de negocio: o agente nunca inventa preco, desconto ou estoque. O humano assume quando precisa — com contexto e resumo prontos.

Agente de IA com guardrails: LLM gera, codigo decide — desconto, estoque e preco sempre do catalogo real
API oficial da Meta: janela 24h, templates aprovados, opt-out STOP/PARAR e supressao
Multi-tenant com isolamento total de dados por empresa
Inbox unificada com estado AI/humano por conversa e score de lead
Handoff humano com contexto e resumo automatico
Knowledge/RAG por empresa: politicas, FAQ e catalogo
Kill switch por tenant sempre acessivel
Onboarding self-service em 6 passos sem tecnico
Planos comerciais integrados ao StackPost (R$197 a R$1.497/mes + Agency)

Linha do tempo

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

Metodologia

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

Arquitetura

→ Next.js + Cloudflare Workers — frontend e API no mesmo runtime edge
→ Meta Cloud API oficial do WhatsApp Business — sem biblioteca não-oficial
→ Supabase multi-tenant com RLS — cada cliente isolado por linha
→ Agente IA com RAG conectado ao catálogo real do cliente
→ Guardrails: políticas configuráveis, kill switch e handoff humano com resumo
→ Planos comerciais cobrados via StackPost/Billing em BRL

Diagrama conceitual — não reflete implementação real

Stack tecnológica

Escolhas técnicas e o que ficou para fora.

Decision log

O que escolhi, o que rejeitei e por quê.

Next.js 15 em vez de SPA

Por que: Escolhi uma arquitetura com renderização híbrida para ganhar SEO, SSR e melhor performance inicial — combinado com Next.js + Cloudflare Workers, Meta Cloud API oficial, Supabase (Postgres + Auth + RLS), AI + RAG + Guardrails.. Uma SPA pura teria dificultado a indexação e a experiência no primeiro carregamento.

Alternativas rejeitadas: SPA tradicional com React Router — rejeitada por falta de SSR e metadados dinâmicos.

PostgreSQL em vez de MongoDB

Por que: Optei por um banco relacional por causa dos catálogos, estoque e pedidos, que exigem consistência e relacionamentos bem definidos — combinado com Next.js + Cloudflare Workers, Meta Cloud API oficial, Supabase (Postgres + Auth + RLS), AI + RAG + Guardrails..

Alternativas rejeitadas: MongoDB — rejeitado porque o modelo de dados do projeto se beneficia mais de esquemas rígidos e transações ACID.

Gamificação por tiers em vez de leaderboards abertos

Por que: Criei um sistema de tiers fechado para reconhecer progresso sem expor todos os usuários em rankings públicos — combinado com Next.js + Cloudflare Workers, Meta Cloud API oficial, Supabase (Postgres + Auth + RLS), AI + RAG + Guardrails., evitando desmotivação dos participantes que estão começando.

Alternativas rejeitadas: Leaderboard global aberto — rejeitado por pressionar usuários iniciantes e mascarar evolução individual.

Segurança e acesso

Lições aprendidas

Nem tudo saiu como planejado.

— Vendedores adotam quando o gerente adota primeiro

— Gamificação funciona até virar rotina — precisa de mecânicas sazonais

— Content curation é mais importante que a tecnologia em si

Nexus IA

Nexus IA — Plataforma de IA

Plataforma de IA com 620+ endpoints REST, Nexus Auto com roteamento automático entre 20+ modelos, workspace com agente autônomo, multimodal e 6 planos comerciais.

Ver case →