OpenClaw na prática: como criar um agente de atendimento ao público que não seja uma bomba-relógio

O que você vai construir aqui

Um agente de atendimento público com estas características:

• responde dúvidas frequentes sem alucinar à toa;
• coleta dados mínimos de contato e contexto;
• registra o que foi coletado;
• separa memória operacional de memória sensível;
• encaminha casos que exigem humano;
• fica isolado do seu agente pessoal ou operacional;
• abre com segurança razoável, sem sair dando acesso demais para qualquer estranho.

A arquitetura recomendada é esta:

Cliente → Telegram ou WhatsApp → Gateway OpenClaw
                                   ↓
                          Agente "atendimento"
                                   ↓
                1) responde FAQ
                2) coleta dados
                3) registra lead/incidente
                4) escala para humano quando necessário
                                   ↓
                        Agente interno / operador

A ideia central é simples: não misture o agente público com o seu agente privado. O OpenClaw suporta múltiplos agentes isolados, cada um com workspace, arquivos de identidade, sessão e diretório de estado próprios.^[1]

1) Antes de instalar: entenda o terreno

O OpenClaw é, na prática, um gateway local/self-hosted que conecta canais como WhatsApp, Telegram, Discord, Signal, iMessage e outros a um runtime de agente, com UI web, sessões, ferramentas e roteamento multiagente.^[2][3]

Isso tem consequências diretas:

1. o canal é só a porta de entrada;
2. o comportamento real do bot nasce do workspace do agente;
3. memória não é mágica — ela vive em arquivos;
4. segurança depende mais da sua configuração do que do seu entusiasmo.

O runtime do OpenClaw injeta no contexto do agente arquivos como AGENTS.md, SOUL.md, USER.md e arquivos de memória do workspace em sessões novas. Em outras palavras: se você quer um bot bom, não adianta só “escrever um prompt legal”; você precisa montar o workspace direito.^[4][5][6]

2) Escolha do canal: Telegram primeiro, WhatsApp depois

Minha recomendação direta

Se você quer subir rápido, testar o fluxo e validar o atendimento, comece por Telegram.

O motivo é objetivo:

• o canal de Telegram está documentado como production-ready para DMs e grupos;
• o setup é limpo com token do BotFather;
• o fluxo é previsível;
• você evita parte da fricção operacional do WhatsApp.^[7]

E o WhatsApp?

Dá para usar, sim. O OpenClaw trata o WhatsApp como canal via WhatsApp Web (Baileys), com login por QR code. A própria documentação recomenda usar um número dedicado quando possível, porque isso reduz confusão operacional e melhora os limites de acesso e roteamento.^[8]

Isso importa muito em atendimento. Misturar o seu número pessoal com o bot é preguiça operacional — e preguiça operacional vira incidente.

3) Instalação base

O caminho recomendado pelo projeto é o onboarding guiado.

npm install -g openclaw@latest
openclaw onboard --install-daemon

O guia oficial informa Node 24 como recomendado, com Node 22.16+ também suportado, e o onboarding é o fluxo preferido para configurar gateway, workspace, canais e skills.^[9][10]

Depois disso, abra a interface web:

openclaw dashboard

O dashboard é servido pelo próprio gateway, normalmente em http://127.0.0.1:18789/.^[11]

Figura 2 — Exemplo de interface do ecossistema OpenClaw. Fonte: assets oficiais do repositório.^[3:1]

4) Crie um agente isolado só para atendimento

Não use o agente principal para falar com cliente. Isso é erro básico.

Crie um agente próprio:

openclaw agents add atendimento
openclaw agents list --bindings

A própria CLI mostra openclaw agents add e openclaw agents bind como fluxo padrão para agentes isolados e bindings de roteamento.^[12] A documentação de multi-agent explica que cada agente tem:

• workspace próprio;
• agentDir próprio;
• sessões próprias;
• identidade e arquivos próprios.^[1:1]

Isso significa que você pode ter:

• main: seu agente privado;
• atendimento: bot público;
• ops: bot interno para time ou operador.

E é exatamente assim que deveria ser.

5) Trave a segurança antes de abrir a porta

Essa é a parte que todo mundo tenta pular. Não pule.

A documentação de segurança do OpenClaw é cristalina em dois pontos:

• se várias pessoas podem mandar DM para o bot, você deve isolar sessão por remetente;
• prompt injection não é resolvido por “instruções bonitas”; o que realmente limita dano é política de ferramentas, sandbox, allowlists e escopo.^[13]

Baseline mínimo recomendado

O guia de segurança publica um baseline endurecido com:

• session.dmScope: "per-channel-peer";
• tools.profile: "messaging";
• bloqueio de grupos de ferramentas de automação, runtime e filesystem amplo;
• exec negado;
• elevated desligado.^[13:1]

Exemplo inspirado diretamente nesse baseline:

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "troque-por-um-token-longo-e-aleatorio"
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "tools": {
    "profile": "messaging",
    "deny": [
      "group:automation",
      "group:runtime",
      "group:fs",
      "sessions_spawn",
      "sessions_send"
    ],
    "fs": {
      "workspaceOnly": true
    },
    "exec": {
      "security": "deny",
      "ask": "always"
    },
    "elevated": {
      "enabled": false
    }
  }
}

Por que isso é obrigatório?

Porque, por padrão, o OpenClaw pode operar com leitura/escrita de arquivos, acesso de rede e envio de mensagens, dependendo do que você habilitou. A superfície de risco é real.^[13:2]

Comando obrigatório depois de cada ajuste

openclaw security audit

E, quando fizer mudanças maiores:

openclaw doctor

Se você pretende abrir DMs públicas sem auditoria e sem reduzir ferramentas, você não está montando atendimento. Está montando uma armadilha.

6) Estruture o workspace como um sistema, não como um prompt

A pior forma de montar esse bot é jogar tudo dentro de um único AGENTS.md e rezar.

A melhor forma é organizar o workspace por função.

Estrutura sugerida

~/.openclaw/workspace-atendimento/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── knowledge/
│   ├── faq.md
│   ├── produtos.md
│   ├── politicas.md
│   └── horarios.md
├── policies/
│   ├── intake.md
│   ├── escalacao.md
│   └── tom_de_voz.md
├── data/
│   ├── leads/
│   │   └── intakes.ndjson
│   ├── incidents/
│   │   └── casos_abertos.md
│   └── faq/
│       └── open_questions.md
├── memory/
│   └── YYYY-MM-DD.md
├── MEMORY.md
└── skills/
    └── lead_capture/
        └── SKILL.md

O papel de cada arquivo

• AGENTS.md: regras de operação do agente.
• SOUL.md: identidade, postura e limites.
• USER.md: perfil do operador/dono, não do cliente.
• knowledge/*.md: base factual que o agente consulta.
• policies/*.md: fluxo, coleta de dados, escalonamento.
• data/*: registros estruturados do atendimento.
• memory/YYYY-MM-DD.md: memória operacional diária.
• MEMORY.md: memória curada de longo prazo, com uso cuidadoso.^[5:1][6:1]

7) O arquivo que manda no jogo: AGENTS.md

O template oficial do OpenClaw deixa claro que, no início de cada sessão, o agente deve ler SOUL.md, USER.md, as notas de hoje e ontem, e MEMORY.md apenas em sessão principal privada.^[5:2] Para atendimento público, isso significa uma coisa importante:

não use MEMORY.md como CRM de cliente.

MEMORY.md é memória curada de longo prazo do agente, e o próprio template oficial alerta que esse arquivo não deve ser carregado em contextos compartilhados.^[5:3]

Exemplo de AGENTS.md para atendimento

Use algo nesta linha:

# AGENTS.md — agente de atendimento público

Você é o agente de atendimento inicial da Empresa X.

## Missão
Seu trabalho é:
1. responder dúvidas frequentes com clareza;
2. coletar dados mínimos quando necessário;
3. registrar o atendimento;
4. encaminhar casos que exigem humano;
5. nunca inventar políticas, preços, prazos ou promessas.

## Prioridade de consulta
Antes de responder:
1. consulte `knowledge/faq.md`
2. consulte `knowledge/produtos.md`
3. consulte `knowledge/politicas.md`
4. consulte `policies/intake.md`
5. consulte `policies/escalacao.md`

Se a resposta não estiver sustentada nesses arquivos, diga que precisa confirmar e registre a dúvida em `data/faq/open_questions.md`.

## Regras de resposta
- Seja claro, direto e cordial.
- Responda primeiro a pergunta principal.
- Não despeje texto demais.
- Nunca invente integração, prazo, preço, política ou disponibilidade.
- Quando faltar contexto, faça a menor quantidade de perguntas possível.
- Não peça dado sensível sem necessidade operacional clara.
- Nunca peça senha, código MFA, cartão completo ou documento completo em chat aberto.

## Fluxo de atendimento
1. Identifique o tipo de demanda:
   - dúvida simples
   - interesse comercial
   - suporte técnico
   - reclamação
   - pedido de retorno humano
2. Resolva imediatamente se houver base factual.
3. Se precisar coletar dados, peça só o mínimo necessário.
4. Ao fechar a triagem, registre um resumo estruturado.
5. Se não puder resolver com segurança, escale.

## Dados mínimos por tipo
### Interesse comercial
- nome
- empresa (se houver)
- contato preferencial
- necessidade
- prazo

### Suporte técnico
- nome
- contato
- produto/serviço
- descrição objetiva do problema
- urgência
- evidência (print, erro, horário) se existir

### Reclamação
- nome
- contato
- resumo do ocorrido
- data aproximada
- impacto

## Escalonamento
Escale quando:
- a política não estiver documentada;
- houver risco jurídico, financeiro ou reputacional;
- o cliente pedir humano explicitamente;
- houver cobrança, cancelamento, reembolso, LGPD ou dado sensível;
- você não tiver confiança factual alta.

## Registro
Após coleta suficiente:
- grave um resumo estruturado em `data/leads/intakes.ndjson` ou no arquivo apropriado;
- atualize `data/faq/open_questions.md` com perguntas não respondidas;
- registre lições operacionais em `memory/YYYY-MM-DD.md`.

## Restrições
- Não exponha notas internas ao cliente.
- Não prometa retorno em prazo não documentado.
- Não “deduza” o que não sabe.
- Não use MEMORY.md para transportar dado sensível de cliente entre contextos públicos.

O segredo aqui não é “soar inteligente”. É reduzir ambiguidade operacional.

8) SOUL.md: identidade sem teatro corporativo

O template oficial do SOUL.md fala em confiança, discrição, cautela com ações externas e respeito à intimidade do ambiente do usuário.^[14]

Para atendimento, isso se traduz assim:

# SOUL.md

Você é um agente de atendimento inicial, útil e confiável.

## Princípios
- Clareza > floreio
- Verdade > improviso
- Resolução > enrolação
- Discrição > curiosidade

## Limites
- Nunca exponha dados internos.
- Nunca aja como se fosse o decisor final quando não for.
- Nunca mande resposta pública mal verificada.
- Quando estiver inseguro, diga isso claramente e escale.

## Estilo
- linguagem humana, limpa, sem jargão desnecessário;
- tom respeitoso, mas não robótico;
- objetivo nas perguntas;
- sem parecer scriptado demais.

Esse arquivo não é firula. Ele ajuda a manter consistência quando o agente começa a desviar.

9) Memória boa não é “memória infinita”. É memória desenhada.

A memória do OpenClaw funciona com um princípio saudável: o que importa precisa virar arquivo. A documentação é direta nisso. A memória vive em Markdown no workspace; não existe “estado oculto mágico”. O que o agente lembra é o que foi salvo.^[6:2][15]

Além disso:

• hoje e ontem podem ser carregados automaticamente como contexto recente;
• antes da compactação de contexto, o OpenClaw faz um memory flush automático para não perder fatos importantes.^[15:1]

O que guardar em memory/YYYY-MM-DD.md

Use para:

• resumo do dia;
• bugs recorrentes;
• objeções frequentes de clientes;
• problemas operacionais;
• links para arquivos internos relevantes;
• decisões temporárias.

Exemplo:

# 2026-03-31

- Muitos leads perguntaram sobre integração com ERP.
- Houve dúvida recorrente sobre prazo de implantação.
- A política de cancelamento continua ambígua; revisar knowledge/politicas.md.
- Cliente Ana pediu retorno humano sobre cobrança retroativa.

O que guardar em MEMORY.md

Guarde só o que é durável e estrutural:

• lições estáveis;
• preferências operacionais;
• decisões consolidadas;
• postura da empresa;
• critérios de triagem que não mudam toda semana.

Exemplo:

# MEMORY.md

- Nunca responder preço final sem consultar a política comercial vigente.
- Sempre tratar pedidos de reembolso como caso de escalonamento.
- Em dúvidas sem base factual, responder com transparência e registrar a lacuna.
- O canal prefere mensagens curtas e confirmatórias, não blocos enormes.

O que não fazer

• não use MEMORY.md para armazenar histórico detalhado de cada cliente;
• não use memória como substituto de base de conhecimento;
• não confie em memória para algo que exige estrutura — use arquivo estruturado.

Se dado importa, registre fora da conversa.

10) Sessões: se você errar aqui, um cliente vaza para o outro

A documentação de sessões não deixa margem para romantismo: por padrão, todas as DMs podem compartilhar a mesma sessão em setups single-user. Se mais de uma pessoa falar com o bot, você precisa habilitar isolamento de DM. Caso contrário, o contexto de Alice pode vazar para Bob.^[16]

Configuração certa

{
  "session": {
    "dmScope": "per-channel-peer",
    "reset": {
      "idleMinutes": 720
    }
  }
}

O per-channel-peer é o recomendado para isolar por canal + remetente.^[16:1]

E se a mesma pessoa falar por dois canais?

A documentação recomenda session.identityLinks quando você quer que a mesma pessoa compartilhe uma identidade entre canais diferentes.^[16:2]

Meu conselho: só faça isso quando tiver certeza de que sabe o que está unificando. Senão você cria um Frankenstein de contexto.

11) Configure o canal: tutorial rápido para Telegram

Para um primeiro bot público, Telegram é o caminho mais limpo.

Passo 1 — criar token

No Telegram, fale com @BotFather, rode /newbot e guarde o token.^[7:1]

Passo 2 — configurar o canal

Exemplo mínimo:

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "COLE_SEU_TOKEN_AQUI",
      "dmPolicy": "pairing",
      "groups": {
        "*": {
          "requireMention": true
        }
      }
    }
  }
}

Esse é o padrão seguro de entrada: pairing em DMs e menção exigida em grupos.^[7:2][17]

Passo 3 — subir gateway e aprovar o primeiro contato

openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <CODIGO>

Os códigos de pairing expiram em uma hora.^[7:3]

Quando abrir para o público de verdade?

A documentação admite dmPolicy: "open" para Telegram, mas isso exige allowFrom com "*".^[7:4] Em português claro: isso transforma seu bot em porta aberta.

Faça isso só depois de:

• reduzir ferramentas;
• testar prompt injection;
• validar o fluxo de atendimento;
• confirmar que o agente não executa nada perigoso.

12) Se for WhatsApp, faça direito

O setup rápido oficial é:

{
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "allowFrom": ["+5511999999999"],
      "groupPolicy": "allowlist",
      "groupAllowFrom": ["+5511999999999"]
    }
  }
}

Depois:

openclaw channels login --channel whatsapp
openclaw gateway
openclaw pairing list whatsapp
openclaw pairing approve whatsapp <CODIGO>

O OpenClaw recomenda usar um número separado quando possível.^[8:1] E isso não é preciosismo. Em atendimento, número dedicado significa:

• identidade clara do bot;
• menos confusão com self-chat;
• menos chance de política mal configurada;
• fronteira operacional mais limpa.

Outro detalhe importante: o canal de WhatsApp do OpenClaw é baseado em WhatsApp Web (Baileys); a própria doc observa que não existe um canal nativo separado via Twilio no registro embutido de canais.^[8:2]

Isso significa: se você precisava de uma stack de WhatsApp corporativo gerenciada e certificada, você precisa pensar duas vezes antes de enfiar tudo no OpenClaw.

13) Faça a base de conhecimento parar o bot de inventar

O erro clássico de agente de atendimento é responder com confiança usando nada além de probabilidade.

A solução é simples: dê uma base curta, clara, atualizada e verificável.

Exemplo de knowledge/faq.md

# FAQ operacional

## Horário de atendimento humano
- Segunda a sexta: 9h às 18h
- Sábado: 9h às 12h
- Domingo: sem atendimento humano

## Prazo de retorno
- Dúvidas simples: tentativa de resposta imediata pelo agente
- Casos humanos: retorno em até 1 dia útil
- Casos financeiros ou cancelamento: prioridade alta

## Política de preço
- O agente não fecha preço final sem consultar a política comercial vigente.
- Em pedidos comerciais, coletar contexto e encaminhar ao time humano.

## Política de cancelamento
- O agente não promete cancelamento instantâneo.
- Todo pedido de cancelamento deve ser escalado.

Regras que você deve colocar no agente

1. responder apenas com base no que estiver documentado;
2. quando não souber, dizer isso claramente;
3. registrar a pergunta aberta em data/faq/open_questions.md;
4. nunca tratar suposição como política.

Isso parece óbvio. Mesmo assim, quase ninguém faz.

14) Coleta de dados: o bot precisa ser eficiente, não policialesco

Um agente bom coleta o mínimo necessário para destravar o próximo passo.

Fluxo de coleta que funciona

1. entende a categoria da demanda;
2. pede só os campos mínimos;
3. resume de volta para confirmar;
4. registra;
5. resolve ou escala.

Exemplo de abordagem

Cliente: “Quero entender melhor o serviço de vocês.”

Bot:
“Perfeito. Posso te orientar já. Para eu te direcionar melhor, me diga só três coisas:

1. seu nome,
2. empresa ou contexto de uso,
3. o principal objetivo com o serviço.”

Curto. Direto. Nada de formulário vomitado em chat.

Campos mínimos por cenário

Regra de ouro

Nunca colete porque “vai que ajuda”.
Colete porque sem aquele dado o próximo passo trava.

15) Para dados importantes, memória não basta: registre de forma estruturada

Se o objetivo é “coletar dados”, você precisa de registro estruturado, não só conversa.

A forma mais simples é pedir que o agente registre cada triagem concluída em um arquivo NDJSON dentro do workspace, por exemplo:

data/leads/intakes.ndjson

Exemplo de linha:

{"timestamp":"2026-03-31T14:32:00-03:00","canal":"telegram","nome":"Ana","contato":"ana@empresa.com","tipo":"interesse_comercial","objetivo":"automatizar triagem de leads","urgencia":"media","status":"triado","resumo":"Lead qualificado; pediu retorno humano"}

Por que isso é melhor?

Porque depois você consegue:

• exportar;
• integrar com outro sistema;
• auditar;
• procurar padrões;
• saber o que o bot realmente coletou.

Conversa é contexto.
Arquivo estruturado é operação.

16) Skills: como disciplinar o agente sem transformar tudo em gambiarra

O OpenClaw usa skills como diretórios com SKILL.md em Markdown com frontmatter YAML. Elas servem para ensinar ao agente quando e como agir.^[18][19]

Exemplo de skill para captura de lead

Crie:

mkdir -p ~/.openclaw/workspace-atendimento/skills/lead_capture

E dentro dela, SKILL.md:

---
name: lead_capture
description: Registra atendimentos concluídos e dúvidas abertas em arquivos estruturados do workspace.
---

# Lead Capture

Use esta skill quando uma conversa atingir triagem suficiente para registro.

## Objetivo
Registrar dados coletados sem depender apenas da memória da conversa.

## Regras
- Nunca invente campo ausente.
- Se um dado não foi fornecido, use `null`.
- Não registrar segredo, senha, MFA, cartão ou documento completo.
- Sempre confirmar o resumo antes de registrar quando a conversa estiver ambígua.

## Registro principal
Ao concluir triagem, registre um objeto JSON em `data/leads/intakes.ndjson` com:
- timestamp
- canal
- nome
- contato
- tipo
- objetivo ou problema
- urgência
- status
- resumo

## Perguntas sem resposta
Se a resposta não estiver sustentada por `knowledge/*.md`, adicione a dúvida em `data/faq/open_questions.md` com:
- data
- pergunta
- contexto
- motivo da escalada

Depois recarregue a sessão:

/new

ou reinicie o gateway:

openclaw gateway restart

E confira:

openclaw skills list

Esse fluxo é exatamente o modelo documentado para criação de skills locais no workspace.^[18:1]

17) Hooks e webhooks: quando você quer parar de depender só da conversa

O OpenClaw oferece duas coisas diferentes:

• hooks, que rodam dentro do gateway quando eventos acontecem;
• webhooks, que deixam sistemas externos dispararem ações no OpenClaw.^[20][21]

Quando hooks ajudam no atendimento

Use hooks quando você quiser, por exemplo:

• manter trilha de auditoria;
• salvar contexto em reset;
• disparar automação ao fechar atendimento;
• empurrar um resumo para um sistema externo.^[20:1]

Os hooks são scripts pequenos descobertos automaticamente, com HOOK.md e handler.ts, e o próprio projeto já traz hooks empacotados como session-memory e command-logger.^[20:2]

Quando webhooks ajudam

Use webhooks quando outro sistema precisa acionar o agente — por exemplo:

• formulário do site;
• CRM;
• inbox;
• fila de novos leads;
• formulário de “fale conosco”.

A documentação mostra /hooks/agent e mapeamentos via hooks.mappings, além de um config recomendado com hooks.enabled, token e defaultSessionKey fixo.^[21:1]

Exemplo mínimo de postura segura, baseado na doc:

{
  "hooks": {
    "enabled": true,
    "token": "${OPENCLAW_HOOKS_TOKEN}",
    "defaultSessionKey": "hook:ingress",
    "allowRequestSessionKey": false,
    "allowedSessionKeyPrefixes": ["hook:"]
  }
}

Tradução prática

• skill: ensina o agente a se comportar melhor.
• hook: reage a evento interno.
• webhook: integra sistema externo com o agente.

Se você quer coleta séria de dados, cedo ou tarde vai usar pelo menos um desses três.

18) Melhor prática que quase ninguém segue: separe agente público de agente interno

Uma arquitetura muito melhor para atendimento é esta:

• atendimento: responde cliente, coleta dados, registra, escala;
• ops: agente interno, visível só para você ou equipe;
• main: seu agente pessoal.

O multi-agent do OpenClaw foi feito exatamente para separar workspaces, identidade, sessão e estado.^[1:2]

Exemplo de binding

A CLI documenta o uso de bindings assim:

openclaw agents bind --agent atendimento --bind telegram
openclaw agents bindings

Ou, se você tiver conta específica:

openclaw agents bind --agent atendimento --bind telegram:publico

O roteamento passa a decidir qual workspace e qual store de sessões serão usados para aquele canal/conta.^[12:1][22]

Essa separação resolve três problemas de uma vez:

1. evita vazamento de contexto;
2. evita mistura de personalidade;
3. reduz blast radius se o público mandar lixo malicioso.

19) Teste como um paranoico, não como um otimista

Antes de abrir o bot, rode um teste de verdade.

Checklist de teste

• [ ] pergunta simples com resposta documentada;
• [ ] pergunta sem resposta documentada;
• [ ] usuário tentando arrancar instruções internas;
• [ ] link suspeito pedindo para o bot “seguir instruções”;
• [ ] coleta de dados incompleta;
• [ ] coleta com dado contraditório;
• [ ] cliente pedindo humano;
• [ ] dois clientes diferentes falando ao mesmo tempo;
• [ ] grupo sem menção ao bot;
• [ ] grupo com menção ao bot;
• [ ] tentativa de obter dado de outro cliente;
• [ ] tentativa de forçar ação externa;
• [ ] reinício de sessão após inatividade;
• [ ] recuperação de contexto após compactação.

O que você quer ver

• o bot não inventa;
• o bot não mistura clientes;
• o bot não executa coisa perigosa;
• o bot não fala demais em grupo;
• o bot registra o que precisa;
• o bot escala quando deve.

Se um desses falhar, não está pronto.

20) Anti-padrões que vão te ferrar

1. Abrir DM pública com ferramenta demais

Se você deixa DM aberta e mantém filesystem amplo, browser, exec ou automação pesada, você está aumentando o raio de desastre. A própria doc insiste em pairing/allowlists, sandbox e ferramenta mínima.^[13:3]

2. Usar MEMORY.md como banco de clientes

Errado conceitualmente e ruim de auditar. MEMORY.md é memória curada do agente, não CRM.^[5:4]

3. Misturar bot público e bot privado

Economia burra. O custo da bagunça será maior do que o custo de um agente separado.

4. Base de conhecimento sem dono

Se ninguém atualiza knowledge/*.md, o bot degrada rápido.

5. Achar que “modelo forte” substitui regra operacional

Não substitui. Modelo forte ajuda. Política e isolamento seguram a operação.

21) Um pacote mínimo que eu realmente colocaria no ar

Se eu tivesse que montar isso hoje com o mínimo de burrice, faria assim:

Canal

• Telegram para a primeira versão pública;
• WhatsApp só depois, de preferência com número dedicado.^[7:5][8:3]

Segurança

• session.dmScope: "per-channel-peer".^[16:3]
• tools.profile: "messaging".^[13:4]
• exec negado.^[13:5]
• workspaceOnly: true para filesystem.^[13:6]
• pairing no staging; abertura pública só depois de teste sério.^[7:6][8:4]

Estrutura

• um agente atendimento;
• um agente ops;
• base factual em knowledge/;
• política em policies/;
• registros em data/;
• skill local de captura de lead;
• hook ou webhook quando integração externa fizer sentido.^{[18:2][20:3][21:2]}

Rotina

• revisar data/faq/open_questions.md toda semana;
• consolidar aprendizados em knowledge/faq.md;
• auditar logs e registros;
• rodar openclaw security audit sempre que abrir superfície nova.^[13:7]

22) Conclusão

O OpenClaw é forte quando você o trata como o que ele é: um gateway de agente self-hosted, com canais, sessões, memória em arquivos, skills e automações.^[2:1][3:2]

Para atendimento ao público, a receita que funciona não é “prompt mágico”. É esta:

• isolar o agente;
• reduzir ferramentas;
• desenhar memória;
• documentar fatos;
• registrar dados de forma estruturada;
• escalar sem vergonha quando faltar base.

A pior decisão é querer um bot “autônomo” demais logo de cara.
Comece com um agente bom de triagem, FAQ e coleta. Depois, se ele provar valor, você integra com o resto.

Esse é o caminho adulto. O outro caminho é demo bonita e incidente feio.

Apêndice A — exemplo de knowledge/faq.md mais robusto

# FAQ

## O que fazemos
A Empresa X oferece suporte de implantação, automação de processos e integração de sistemas.

## Para quem é
Empresas pequenas e médias que precisam reduzir trabalho manual e padronizar operação.

## O que o agente pode responder sozinho
- visão geral do serviço
- horário de atendimento
- como funciona o primeiro contato
- documentos e informações iniciais necessárias
- diferenças básicas entre planos, quando isso estiver documentado

## O que o agente NÃO pode responder sozinho
- preço final
- desconto
- exceção contratual
- cancelamento final
- prazo garantido fora da política
- posição jurídica
- tratamento de incidente crítico sem validação humana

## Horário humano
Segunda a sexta, 9h às 18h.

## Escalonamento obrigatório
- cobrança
- contrato
- LGPD
- cancelamento
- reembolso
- incidente com impacto operacional alto

## Última revisão
2026-03-31
Responsável: time de operações

Apêndice B — exemplo de policies/intake.md

# Política de intake

## Objetivo
Coletar só o mínimo necessário para responder, qualificar ou encaminhar.

## Ordem
1. entender o tipo de demanda
2. pedir os dados mínimos
3. confirmar o resumo
4. registrar
5. resolver ou escalar

## Regra de ouro
Se a resposta puder ser dada sem pedir dado pessoal, responda primeiro.

## Dados proibidos em chat aberto
- senha
- token
- código MFA
- cartão completo
- documento completo
- credenciais internas

Apêndice C — exemplo de prompt de teste para o agente

Use o próprio CLI para testar comportamento sem depender do canal:

openclaw agent --agent atendimento --message "Um cliente quer cancelar o serviço e pede prazo imediato. Como você responde e quais dados você coleta?"

A CLI oficial documenta openclaw agent --agent <id> --message "..."
como forma de disparar uma rodada de agente pelo terminal, útil para teste e automação.^[23]

Referências