Como implementei WhatsApp-first sem notar

Source: Dev.to

Introdução

Tudo começou há mais de três anos, quando conheci o Whaticket, quase por acidente, em um freela que parecia simples e que mudou completamente a direção do que eu faria dali pra frente. Na época, ele era praticamente sinônimo de atendimento via WhatsApp para muita gente. Só que eu nunca consegui olhar para uma ferramenta pronta e usar do jeito que veio. Eu não gostava muito da arquitetura dele nem do frontend.

O primeiro nicho

Em um freela o cliente pediu basicamente que eu transformasse o WhatsApp para o chat do Facebook, identicamente. Quando finalizei, o cliente ficou impressionado, e aí eu entendi que tinha achado um nicho dentro de um nicho. Passei a oferecer o serviço de modificação visual do Whaticket. As pessoas pagavam por isso, porque finalmente existia algo diferente no mercado. Isso me diferenciou de um jeito curioso: eu não estava competindo com o sistema, estava competindo com a mesmice.

O teto da plataforma de terceiros

Com o tempo, porém, comecei a sentir que viver dentro de uma plataforma de terceiros tinha um teto bem definido. Posso customizar, posso modificar, mas no fim do dia estou construindo em cima de uma fundação que não é minha.

A virada: comandos via WhatsApp

Foi quando, há cerca de dois anos, comecei a brincar com uma ideia diferente, e o que nasceu dali parece óbvio só em retrospecto. Eu tinha um servidor de teste meu e comecei a criar comandos que eu enviava pelo próprio WhatsApp para disparar ações:

• Um comando disparava uma rotina, criava registro, consultava algo, acionava fluxo.
• Percebi que não precisava de um dashboard completo para gerenciar operações, pois antes disso eu já usava o WhatsApp para enviar alertas do servidor.
• A interface já estava no meu bolso, já estava aberta, já era o canal onde tudo acontecia de qualquer forma.

WhatsApp como interface administrativa

Essa percepção abriu uma fratura no jeito que eu pensava sobre interfaces. O controle real estava na API, não no painel. Quando comecei a orquestrar ações por mensagem, percebi que o WhatsApp podia ser interface administrativa, não só canal de atendimento. Se analisarmos friamente, isso já se encaixa como um quase WhatsApp‑first. Não era purista, porque ainda existiam funções externas, mas a ideia de que o centro operacional poderia viver dentro da conversa já estava ali germinando.

2025: foco total no WhatsApp

Em 2025, esse pensamento tomou forma mais concreta nas escolhas que fiz:

• Passei a pegar apenas projetos cujo núcleo fosse a criação de alguma funcionalidade diretamente no WhatsApp (atendimento, vendas, agendamento), integrada com algum sistema já existente do cliente.
• Evitei ERP completo do zero ou painéis corporativos pesados.
• Concentrei‑me no que conectava ação real à conversa real.

Quanto mais eu fazia, mais ficava claro que estava acumulando conceitos de IA, arquitetura de automação, orquestração assíncrona, eventos, agentes especializados, mas aplicando tudo em projetos fragmentados.

Decisão: criar um CRM próprio

Foi aí que pensei: vou criar um CRM próprio. Não para competir com o mercado, mas para ter um sistema onde pudesse implementar tudo que aprendi (e ainda estou aprendendo) sobre inteligência artificial agêntica, sem precisar pedir permissão a nenhuma plataforma de terceiro (mas eu usava Baileys, Whatsmeow ou EvolutionAPI).

Arquitetura event‑driven

Como já tinha desenvolvido uma arquitetura event‑driven assíncrona baseada em Entity Agents e AtomicBehavior Agents, o processo ficou quase automático:

1. Crio uma funcionalidade nova na API.
2. Já a integro com o WhatsApp no mesmo ciclo.
3. Não preciso construir módulo inteiro para depois “conectar”.
4. A conexão é parte da própria concepção.

Cada entidade reage a eventos, cada comportamento é pequeno, isolado e acionável por mensagem. A conversa deixa de ser apenas interface e passa a ser gatilho semântico. O WhatsApp vira sistema operacional conversacional.

Descoberta do termo “WhatsApp‑first”

Um dia, pesquisando sobre o nome dos padrões das funcionalidades que eu criei, encontrei o termo WhatsApp‑first. O mais curioso é que, antes mesmo de terminar de ler o que o conceito significava, eu já o tinha conectado ao que estava fazendo. Não foi uma descoberta, foi um reconhecimento. Eu não tinha estudado o conceito antes; estava resolvendo problemas e depois descobri que havia nome para aquilo. O nome só chegou depois.

A trajetória prática → arquitetura → conceito

• Diferenciar visualmente um sistema saturado.
• Automatizar ações via comando.
• Perceber que o servidor era o verdadeiro núcleo.
• Escolher projetos alinhados à conversa como interface primária.
• Consolidar tudo em um CRM fértil para IA agêntica.

Cada etapa parecia isolada, mas, ao olhar para trás, vejo uma linha contínua: a interface virou evento, o evento virou agente, o agente virou comportamento atômico, e o WhatsApp deixou de ser canal para virar sistema operacional conversacional.

Resultado prático

Esse modelo me levou a construir um e‑commerce + CRM + mini‑ERP operável via WhatsApp, com:

• Execução, rastreabilidade e recuperação no próprio canal.
• Não é “um bot”, é uma camada operacional conversacional.

Próximos passos – Série de artigos

Nessa série de artigos para explicar como criei o termo/conceito/arquitetura FullAgenticStack, você notará que boa parte do nome dos conceitos veio após eu ter implementado a solução.

• Objetivo: demonstrar, ao longo do ano, o caminho de engenharia que sai do “WhatsApp‑first” e chega a um sistema completo.
• Entrega final: até o fim do ano, fechar com 3 módulos bônus essenciais (os que amarram as pontas que normalmente ficam soltas) para formar um Sistema FullAgenticStack de verdade.

Se você quer a definição mínima do que é o FullAgenticStack, continue acompanhando a série.

O que considero “WhatsApp‑first System” (WFS Basic)

WFS Basic (o mínimo “Pass/Fail”)

• 100 % das capabilities executáveis via WhatsApp (inclui admin e recovery)
• Entrada por texto e áudio (STT) em qualquer capability
• Nenhuma mutação de estado exclusiva do dashboard
• Comandos com confirmação + idempotência (não pode cobrar/cancelar duas vezes)
• Observabilidade via conversa (status/erro/última decisão sem painel obrigatório)
• Recovery via conversa (retry/cancel/reprocess/compensate quando aplicável)

Se quiser a engenharia pesada (protocolos, evidência, observabilidade e recovery), deixei esse post técnico linkado.

Quer aprender mais sobre WhatsApp‑first?

Conheça o primeiro curso focado nesse conceito/arquitetura:
fullagenticstack.dev/whatsapp-first

Quer entender mais sobre os padrões abertos do WhatsApp‑first?

Acesse o artigo correspondente (link a ser inserido).

---

Próximo artigo: Como eu implementei Conversational Agentic UX