Engenheiro de produtos com IA · remoto, do Brasil
Construo sistemas de IA que assumem o trabalho manual repetitivo que uma equipe faz hoje.
O ZapBeta é uma plataforma multiagente: vários Especialistas tocando os setores da empresa pelo WhatsApp e pelas outras ferramentas. Eles atendem, marcam horário, montam orçamento, fecham pedido e cobram e, quando precisam, chamam uma pessoa na hora para ajudar. Está funcionando em produção.
Criei um time de agentes para construir uma plataforma multiagente. Sou o único humano dele: dirijo, decido a arquitetura, escrevo as provas e assino o resultado.
- Node.js
- TypeScript
- React / Next.js
- APIs
- Integrations
- Automation
- AI / LLM Systems
O escritório, ao vivo
Eu montei esse cenário 3D pra qualquer pessoa conseguir ver o que está acontecendo no sistema sem precisar entender de tecnologia. Ele é moldado no ambiente da empresa e mostra, em tempo real, tudo que está rolando lá dentro, inclusive os clientes que já foram atendidos hoje. Abra em tela cheia, dê zoom e navegue pelo escritório.
02O sistema inteiro, num mapa
Do canal em que o cliente chama, até os dados em que tudo se apoia — e de volta a tudo que o dono vê. Cada case study acima entra em uma dessas caixas.
Canais
Por onde o cliente chega. Nos três é a mesma conversa: quem responde no WhatsApp responde no chat do site e na loja.
Orquestração
Quem lê a mensagem e decide o que fazer com ela. O roteador escolhe o Especialista; o supervisor do dinheiro confere tudo que tem valor antes de sair.
Especialistas
Cada um cuida de um setor da empresa, com ferramentas, regras e limites próprios — em vez de um prompt só tentando dar conta de tudo. É o que deixa testar e travar um deles sem mexer nos outros.
Capacidades
O que os Especialistas sabem fazer de verdade: as ferramentas que eles chamam, com efeito no sistema.
Verdade · dados
Onde tudo se apoia. Uma verdade só de cada coisa, com o isolamento entre empresas imposto na porta do banco.
Telas
O que o dono da empresa vê e usa no dia a dia — e onde a equipe assume quando o caso pede.
03Clientes simulados que conversam de verdade
Pra testar os Especialistas eu solto “criaturinhas”: clientes fictícios tocados por um segundo modelo, que recebe um objetivo e reage ao que o agente responde. Não é roteiro. Uma delas negocia, escolhe um horário de verdade, fecha o pedido e encerra sozinha quando conseguiu o que veio buscar.
Simular clientes
Quantas
Tamanho da conversa
Como elas se comportam
Em que idioma elas falam
- objetivo
- o agente responde
- ela reage
- [FIM] quando conseguiu
Um modelo faz o papel do cliente
Ela recebe um objetivo e uma personalidade, lê a última resposta do agente e escreve a próxima mensagem. Encerra quando cumpriu o que veio fazer, ou no teto de turnos que eu escolhi.
Foi assim que eu achei o bug de idioma
Soltei criaturinhas em seis idiomas e o Especialista respondeu em português pra uma alemã. Nenhum teste roteirizado meu ia achar isso — eu escrevo os meus testes em português.
Nada sai pra fora, por construção
O telefone delas não tem um dígito sequer, e todo envio limpa os não-dígitos antes de discar. Sobra string vazia, e aí o envio pula sozinho. Gosto da garantia morando na forma do dado: ninguém apaga um if sem querer e manda mensagem pra um estranho. Tem teste com mil amostras em cima disso.
Na simulação, o Pix é de mentira
O código de pagamento sai estático e nunca toca a API do banco. Demonstração não pode gerar cobrança de verdade.
04Números que são reais
Cada um medido com o comando que está escrito bem do lado dele no código. Nada estimado.
- 162.202
- linhas de TypeScript
- sem os tipos gerados do banco
- 219
- migrations SQL
- Postgres, com RLS em tudo
- 84
- rotas de API
- Next.js App Router
- 35
- ferramentas de function calling
- o que os agentes sabem fazer
- 26
- conversas de prova
- as mais críticas rodam mais de uma vez, porque o modelo varia
- 767
- commits
- fatias pequenas, direto para produção
Medido em 2026-07-25. Sem equipe: arquitetura, banco, agentes, front e infraestrutura são decisão minha, e as provas que cobram tudo isso também.
05Veja os detalhes do que eu construí
Cada um segue o mesmo roteiro: o problema, as restrições, a arquitetura, a parte que foi difícil de verdade, os trade-offs e o que eu faria diferente.
- 01Testar o que não é determinístico: 26 conversas de prova
- 02Roteamento multiagente e o supervisor que guarda o dinheiro
- 03Transformar rastros do agente num escritório 3D ao vivo
- 04Uma auditoria de segurança do meu próprio código com 134 agentes
- 05Rastrear um agente de LLM: depurar o que o modelo realmente fez
- 06Passar a conversa pra uma pessoa sem o cliente repetir nada
- 07Um modelo de domínio para agenda, vendas e entrega
- 08Agendar contra o mundo real
- 09Conformidade que se destila sozinha
- 10Montar um catálogo de produtos a partir de códigos de barras
06Como eu trabalho
Essa é a ordem em que eu trabalho, do primeiro arquivo até depois que o código já subiu. Não montei isso de propósito: fui percebendo que repetia sempre a mesma sequência, e cada passo aí nasceu de um erro que já me custou tempo. Vale igual pros agentes que trabalham comigo: quem executa muda, o método não.
- 01
Antes de integrar, eu vejo o que a API devolve de verdade
Quando vou plugar uma API nova, monto o fluxo no n8n antes de escrever código: disparo a chamada, olho o retorno de verdade e descubro o que a documentação não diz. Depois implemento direto no código, que é onde aquilo vai viver.
- 02
Uma regra mora num lugar só
Se a mesma regra vale em dois lugares, eu não copio. Vira parâmetro, ou função, com teste em cima. Cópia não avisa que está divergindo — quando você vê, já divergiu faz tempo.
- 03
Comentário aponta pro código, não repete o número
Comentário que repete valor mente na primeira vez que o valor muda. Ninguém volta pra arrumar texto. Ninguém mesmo.
- 04
Onde o erro é caro, mais de uma trava
Cada trava pega um jeito diferente de dar errado, então pra vazar tem que falhar mais de uma junto. E se o risco é dos silenciosos eu boto um indicador na tela, senão painel quieto não me diz nada: pode estar tudo certo, pode ser o alarme quebrado.
- 05
Testo o que o agente nunca pode fazer
Palavra exata de modelo não dá pra cobrar. O que ele nunca pode fazer: inventar preço, confirmar horário que não existe, prometer reembolso, não respeitar o compliance ou as regras da empresa. São testes simulando 26 conversas com esses pontos, uns cinco minutos, e rodam antes de todo deploy que encosta no agente.
- 06
Confiro no sistema real, não só no teste
Teste de unidade prova a lógica. Não prova que o dado chega até ela. Já tive regra com tudo verde que nunca rodou na vida real, porque a consulta não trazia a coluna.
- 07
Antes de subir: rodo, enxugo e olho na tela
Commit local, testes, corto o que ficou gordo — teto de 500 linhas por arquivo — e aí abro a tela pra ver o front e o responsivo com o olho mesmo. Só depois vai.
- 08
Depois da review, o erro vira regra
Não é corrigir e seguir. Anoto o que causou, porque senão daqui um mês eu pago o mesmo retrabalho de novo — e o tempo não é só meu, é de quem revisou também.
- 09
No fim, o módulo ganha pasta, diagrama e markdown
Escrevo como funciona e desenho o fluxo, pra próxima pessoa entender sem ler o código todo. Markdown de propósito: gente bate o olho, e uma IA lê tudo de uma vez.
07Decisões técnicas
As escolhas que deram forma ao sistema, e o que eu estava evitando com cada uma. Todas custaram alguma coisa do outro lado.
Por que vários Especialistas e não um prompt só
Um prompt que faz tudo cresce até ninguém conseguir mudar sem quebrar outra coisa. Separei por domínio: cada Especialista tem ferramentas, regras e limites próprios, e um roteador decide quem responde. Assim eu testo e travo um sem tocar nos outros.
Por que a regra de negócio mora no servidor e não no prompt
Data, preço, disponibilidade e desconto são resolvidos em código; o agente só expressa a intenção. Foi isso que matou a cadeia de bugs do "horário errado" — enquanto o modelo somava dias, cada release trazia um jeito novo de errar.
Por que RAG e não um prompt cada vez maior
Enfiar o acervo inteiro no prompt custa em todo turno e ainda afoga o que importa no meio do resto. O conhecimento fica no banco, buscado por similaridade, e no prompt entra só o trecho que responde àquela pergunta.
Por que o isolamento entre empresas fica no banco
Se ele mora no código da aplicação, basta uma consulta esquecer o filtro. No banco, a linha simplesmente não volta. São 219 migrations com essa regra valendo, e foi exatamente ela que a auditoria adversarial passou o pente.
Por que allowlist e não denylist na página pública
Num denylist, campo novo no tipo entra em produção sozinho e ninguém percebe até virar achado. A cena pública monta a resposta campo a campo: telefone, identificador de WhatsApp e e-mail nunca saem, mesmo que as três travas antes deles falhem.
08Segurança, testar atacando
Crio testes de ataque de verdade, simulando um invasor. E mesmo quando eles voltam verdes eu aplico a contra-prova, conferindo na mão por que passaram. Funciona melhor assim.
- 01
Recrutei 134 agentes pra atacar o meu próprio código
134 agentes caçando problema no meu código em paralelo, e cada achado tinha que passar por três céticos, cuja função era provar que era mentira. Sobraram 20, e quando eu juntei os que eram o mesmo bug visto duas vezes, viraram 17 correções. O pior deixava qualquer pessoa, sem login nenhum, gravar agendamento na agenda de outra empresa — fechei no banco, com regra pra não voltar. Era a terceira vez.
- 02
Quando a varredura dá zero, eu desconfio
Rodei uma varredura em todos os endpoints e voltou zero. Zero achado. Pra mim isso não é alívio, é desconfiança na hora. Fui olhar na mão, um por um, e achei um endpoint público que assinava qualquer chave contra o bucket privado: um cliente puxava arquivo de outro. A varredura tinha descartado sozinha. Essas coisas não podem passar.
- 03
Testei o agente como se eu fosse um golpista
Montei uma bateria que tenta sabotar o agente: vazar as instruções internas, arrancar desconto na marra, virar outro robô sem regra. Peguei ele admitindo que era "uma assistente virtual" — justo o que a marca não pode dizer. Consertei com uma regra que mensagem de cliente nenhuma derruba, e rodei três vezes antes de subir.
- 04
Log não precisa guardar tudo pra sempre
Os rastros guardavam nome, telefone e tudo que o cliente escreveu, pra sempre. Agora entram mascarados: fica o primeiro nome, o resto do dado pessoal some. Dado pessoal parado num log que ninguém vai abrir é risco à toa. Não ajuda em nada.
Vamos conversar
Estou aberto a trabalhos remotos construindo com LLMs: agentes, avaliação, ferramental e o produto inteiro em volta disso. Ficarei feliz em mostrar muito mais numa call. Pode chamar.