Skip to main content
O Zatten-OS trabalha como um desenvolvedor de software trabalha: parte de um sinal, entende o estado atual, decide quem resolve, entrega e confere se resolveu. O loop é curto e se repete a cada pedido.
1

1. Sinal

O que disparou o trabalho: um pedido da agência (“monta o follow-up da clínica”), uma reclamação de cliente final (“o agente não marcou a consulta da Maria”), um erro numa conversa, uma nota do MCP, um teste que falhou.
2

2. Estado atual

Antes de mudar qualquer coisa, o assistente descobre como as coisas estão:
  • Esta doc. Uma busca (search_docs_zatten) devolve o título e a descrição das páginas; ele lê só as que batem com o assunto. Vale em toda tarefa nova, mesmo quando ele acha que sabe: o produto muda.
  • O projeto. get_template (configuração e o bloco project, com plano, WhatsApp e versões do agente), find_contacts e a API do dia a dia para chegar a uma conversa.
  • A pasta do cliente. O CLIENTE.md e a memória (MEMORIA.md): o que foi decidido antes e por quê (Organizar sua agência).
3

3. Triagem: do assistente ou da pessoa?

A pergunta é uma só: o assistente consegue conferir sozinho que a correção funcionou?Se for dos dois, ele faz a parte dele e diz exatamente o que fica com a pessoa.
4

4. Entrega

Com plano e “sim” (As regras), pelo MCP, pela API ou pelo navegador. O que é da pessoa vai em Para você fazer no painel, passo a passo.
5

5. Conferir e voltar ao sinal

Relê o projeto, lê as notes, testa o agente, olha a conversa de novo. Se o resultado surpreendeu (uma nota inesperada, um teste que falhou), volta ao passo 2, começando pela doc, antes de tentar outra vez. Errar duas vezes do mesmo jeito é sinal de que falta informação, não de que falta insistência.
No fim, o assistente registra na memória do cliente e chama send_feedback, contando à Zatten como foi e onde travou.

​
Três exemplos

​
Um pedido de configuração

“Cria um follow-up de 24h para quem parou de responder.”
  1. Sinal: o pedido.
  2. Estado: busca “follow-up” na doc e lê Follow-up (o follow-up sempre envia um template da Meta); get_template do projeto, para ver os templates que já existem em meta_templates e as automações que já rodam.
  3. Triagem: montar o follow-up é verificável (ele relê). Ligar é da pessoa.
  4. Entrega: plano, “sim”, update_template com o follow-up desligado.
  5. Conferir: relê, lê as notes, e reporta “ligar o follow-up” em Para você fazer no painel — ou pergunta se pode ligar.

​
Uma reclamação de cliente final

“O agente não marcou a consulta da Maria ontem.”
  1. Sinal: a reclamação.
  2. Estado: find_contacts com query: "Maria" e o período de ontem → o número dela → GET /leads/{numero}/threads e GET /messages/history pela API do dia a dia. Com o LangSmith ligado, o trace da resposta mostra se a tool de agendamento foi chamada e o que voltou.
  3. Triagem: se a tool falhou porque a API do cliente recusou, a correção é na tool (verificável). Se o agente não devia agendar naquele caso, é regra de negócio (da pessoa).
  4. Entrega: corrige a tool numa versão nova.
  5. Conferir: test_agent com a mesma mensagem da Maria. Passou: diz à pessoa que a versão N está pronta para publicar.

​
Um cliente novo inteiro

“Fechei com uma clínica, monta tudo.”
  1. Estado: a pasta do cliente ainda não existe; ele pergunta o que não dá para inferir (objetivo, público, regras) e lê o playbook do nicho.
  2. Entrega: create_project (com “sim”; o projeto nasce com a assinatura pendente), depois funil, tags e propriedades por update_template, depois o agente, iterando com testes.
  3. Da pessoa: conectar o WhatsApp (e assinar), publicar o agente, ligar as automações.

​
Por que assim

  • Ler a doc primeiro evita o erro mais comum de um assistente: agir com o que ele “sabe” de uma versão velha do produto.
  • A triagem pela verificação não depende de o assistente adivinhar o que é arriscado. Se ele não consegue conferir o efeito, a decisão não é dele.
  • Voltar ao sinal faz cada entrega ser conferida, em vez de dada como pronta.

​
Para saber mais