OpenClaw 2.0 pode vigiar sua caixa de entrada e avisar no Telegram só quando importa?

Fala aí, beleza? Um agente que lê a caixa de entrada por você e só te interrompe quando aparece algo que importa de verdade é provavelmente o uso mais "chato" e mais útil de IA que existe hoje

E não é ideia de post de blog: o exemplo dos e-mails da escola dos filhos, com aviso no Telegram quando chega tarefa de casa ou atividade que exige preparo, aparece no post oficial que anuncia o OpenClaw 2.0 como padrão de tarefa contínua simples

Aqui a gente vai destrinchar o que caracteriza esse tipo de monitoramento com aviso proativo, quais peças do OpenClaw entregam isso e onde o negócio costuma travar

Bora?

O que caracteriza uma tarefa de monitoramento com aviso proativo

Olha a anatomia do exemplo oficial, porque ela se repete em todo monitor que presta:

• Uma fonte que muda sozinha: a caixa de entrada recebe coisa nova sem você pedir
• Poucos itens realmente importantes: no meio de dezenas de e-mails, só a tarefa de casa e a atividade que exige preparo interessam
• Um critério de relevância: alguém precisa decidir o que é "importante", e é aí que o agente entra
• Um destino único de aviso: no exemplo, uma mensagem no Telegram

Se tirar qualquer uma dessas quatro peças, vira outra coisa

Sem critério de relevância, você só trocou o lugar do ruído

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Onde entra o OpenClaw 2.0:

O OpenClaw 2.0 corresponde à versão v2026.8.1 e é descrito como a maior atualização da história do projeto

Os números que o blog oficial divulgou no lançamento: 933 contribuidores, sendo 569 de primeira viagem, e mais de 16.000 pull requests

Ou seja, muita gente empurrando o projeto ao mesmo tempo

Por que push, e não polling:

Um detalhe que muda o desenho da coisa: a conclusão de trabalho desacoplado no OpenClaw é orientada a push

O trabalho pode notificar direto ou acordar a sessão (ou o heartbeat) que pediu aquilo

Por isso a documentação avisa que laços de polling de status geralmente são o formato errado

Não é você ficando de F5 no agente, é o agente te chamando quando tem motivo… =)

Heartbeat ou Automations: qual mecanismo usar para vigiar a caixa de entrada

O OpenClaw tem dois mecanismos que parecem a mesma coisa de longe e são bem diferentes de perto

O campo agents.*.heartbeat.every aceita string de duração (ms/s/m/h), e o valor 0m desliga a cadência recorrente

Um detalhe importante da documentação do heartbeat: a cadência é gerenciada pelo agendador de Automations, e o gateway mantém um job de automação de propriedade do sistema para cada agente com heartbeat habilitado

Tome cuidado! A edição correta é em agents.*.heartbeat, nunca no job de automação que o sistema gerou

Qual escolher para o aviso de e-mail no Telegram

A orientação oficial é direta: use Automations quando é preciso horário preciso ou execução isolada, e use Heartbeat quando o trabalho se beneficia do contexto completo da sessão e um horário aproximado já resolve

Agora o ponto duro, o que mais gera frustração:

O heartbeat padrão não deduz trabalho recorrente a partir de conversas anteriores

Checagens recorrentes de caixa de entrada, varredura de agenda ou follow-ups precisam virar automações explícitas

O prompt padrão do heartbeat é propositalmente estreito: seguir o contexto de monitoramento fornecido, manter trabalho recorrente em jobs de automação e responder NO_REPLY quando nada precisa de atenção

Isso existe pra instalação padrão ficar calada em vez de ficar repetindo tarefa velha do histórico

Então, pro seu monitor de e-mail: automação explícita

O heartbeat brilha em outro papel: percorrer o contexto de monitoramento que você já entregou pra ele, agrupando várias checagens numa rodada só do agente, com o contexto completo da sessão

O que ele não faz é criar sozinho a rotina recorrente de vigiar a sua caixa, isso segue sendo trabalho de automação

O que você precisa antes de montar o monitor de e-mail

Antes de sair criando job, três coisas precisam estar de pé:

1. Gateway rodando: as automações rodam dentro do processo do Gateway, não dentro do modelo. Gateway desligado, nenhum agendamento dispara
2. Canal Telegram habilitado, com token de bot configurado
3. Um caminho de entrada de e-mail

As duas entradas de e-mail:

O OpenClaw trata e-mail como automação, e existem dois caminhos

Gmail via Pub/Sub: o setup instala gcloud e gog se estiverem faltando, autentica o gcloud, cria o tópico e a subscription, inicia o Gmail watch e grava a config hooks.gmail

Os pré-requisitos desse caminho incluem a CLI do gcloud, o gog, hooks habilitados e um endpoint HTTPS público

"Endpoint HTTPS público?" É o endereço que o Google vai chamar quando um e-mail novo chegar, então ele precisa ser alcançável de fora

Plugin de gatilho de e-mail por IMAP: observa uma caixa IMAP existente sem depender de Google Pub/Sub nem de webhook público, roteando o e-mail de entrada para uma sessão isolada, com a política de ferramentas do agente leitor que você escolher

Se a ideia de expor endpoint público te deixou desconfortável, esse é o caminho mais curto

Não gosta de editar arquivo de config?

A UI de controle do OpenClaw roda em http://127.0.0.1:18789 e tem a aba Config, que monta um formulário a partir do schema de configuração vivo

Dá pra mexer por ali em vez de abrir o arquivo na mão

Como montar o aviso: do @BotFather ao agendamento

1. Crie o bot no Telegram: fale com o @BotFather e use o comando /newbot (também dá pelo app web do BotFather) pra pegar o token

O erro comum deste passo: procurar um openclaw channels login telegram

Esse fluxo não existe para o Telegram, você define o token em config ou em variável de ambiente e sobe o gateway

2. Configure o token no OpenClaw: defina channels.telegram.enabled como true e preencha o botToken, com fallback pela variável de ambiente TELEGRAM_BOT_TOKEN

O erro comum deste passo: contar com a env numa conta que não é a padrão

A ordem de resolução é tokenFile acima de botToken acima da env, e a variável de ambiente só resolve na conta padrão

3. Ligue a entrada de e-mail: escolha entre o Gmail via Pub/Sub (com hooks habilitados e endpoint HTTPS público) ou o plugin de gatilho IMAP

Se você já passou por um agente cuidando da caixa de entrada em outra ferramenta, a lógica de entrada aqui vai soar familiar

4. Crie a automação pela CLI: as automações são gerenciadas pelo openclaw automations, com openclaw cron mantido como alias dos mesmos comandos (e create é alias de add)

Este é o exemplo de automação com entrega no Telegram que está na documentação:

openclaw automations create "*/15 * * * *" \
  --name "Queue depth probe" \
  --command "scripts/check-queue.sh" \
  --command-cwd "/srv/app" \
  --announce \
  --channel telegram \
  --to "-1001234567890"

Repare no trio que faz o aviso chegar: --announce, --channel telegram e --to

O agendador suporta lembrete único, expressões cron recorrentes e gatilhos por webhook de entrada, e a entrega pode ir para um canal de chat, para um webhook ou para lugar nenhum

5. Ajuste a cadência do heartbeat, se esse for o caminho que você escolheu:

openclaw config set agents.defaults.heartbeat.every "2h"

Lembrando que 0m desliga a cadência recorrente

O erro comum deste passo: editar o job de automação gerado pelo sistema em vez de mexer em agents.*.heartbeat

6. Escreva a regra de relevância como standing order: standing orders dão ao agente autoridade permanente de operação dentro de programas definidos, com escopo, gatilhos e regras de escalonamento

Elas ficam em arquivos do workspace do agente, e a recomendação é colocá-las no AGENTS.md, que é injetado automaticamente em toda sessão

É ali que mora o "o que conta como importante" do seu monitor

Não chega aviso nenhum (ou chega ruído demais): o que checar

Sintoma: nada dispara, em horário nenhum

Causa provável: Gateway desligado

As automações rodam dentro do processo do Gateway, então sem ele nenhum agendamento acorda

Sintoma: o agente fica calado sempre

Causa provável: o token de silêncio

Quando a execução isolada devolve só NO_REPLY (ou no_reply), o OpenClaw suprime a entrega direta e também o caminho de resumo enfileirado, então nada é postado no chat

Isso é design, não bug: o padrão é ficar quieto quando não há o que dizer

Sintoma: você pediu o monitoramento no chat e nada recorrente aconteceu

Causa: o heartbeat não transforma conversa em rotina

Checagem recorrente de caixa de entrada precisa virar automação explícita, ponto

Sintoma: o aviso não chega, mas o agente parece "saber" do assunto depois

Causa: um resultado de heartbeat_respond com notify: false permanece silencioso, porém é guardado como contexto interno limitado para o próximo turno do usuário naquela sessão

Silêncio com memória, digamos assim

Como inspecionar:

Os registros de trabalho desacoplado (execuções ACP, subagentes, execuções de cron, operações via CLI) ficam nas background tasks, que são registro de atividade e não agendador

openclaw tasks list
openclaw tasks audit

O list mostra as tarefas e o audit aponta problemas

E tem a parte da retenção, que quase ninguém olha antes de precisar: registros terminais são mantidos por 7 dias (os perdidos, por 24 horas) e depois removidos automaticamente

Esses registros persistem em SQLite e sobrevivem a reinícios do gateway, então reiniciar não apaga a sua pista

Onde esse padrão rende (e onde ele não é a ferramenta certa)

O e-mail da escola é só o exemplo mais simpático

A mesma anatomia serve pra:

• Varredura de agenda, procurando compromisso que exige preparo
• Follow-ups, aquilo que você prometeu responder e sumiu
• Checagens com cadência independente, cada uma virando a sua própria automação
• Checklist de monitoramento agrupada no heartbeat, quando várias checagens que você já definiu podem viajar juntas na mesma rodada com o contexto completo da sessão

O recorte de segurança que não dá pra pular:

Caixa de entrada é conteúdo que qualquer estranho pode escrever, beleza?

A recomendação da documentação para caixas não confiáveis é rotear o hook para um agente leitor dedicado, com acesso somente leitura ou nenhum acesso ao workspace, negando escrita em arquivos, shell, browser e outras ferramentas desnecessárias

Permissão mínima pro cara que lê e-mail de desconhecido, sempre

Onde não usar:

Montar um laço de polling de status, ficando perguntando "já terminou? já terminou?"

A conclusão de trabalho desacoplado é orientada a push, então esse formato costuma ser o errado desde o começo

Vídeo relacionado do canal

Pra pegar contexto geral sobre os modelos de IA que rodam por trás desse tipo de agente, tem o vídeo "FABLE 5 ESTÁ DE VOLTA! O MODELO MAIS PODEROSO DA ANTHROPIC RETORNA" aqui do canal

Conclusão

Respondendo a pergunta do título: sim, o padrão existe, e usar o OpenClaw para monitorar e-mail e avisar no Telegram é o exemplo que a própria página oficial do OpenClaw 2.0 usa pra ilustrar tarefa contínua simples

O que segura o negócio de pé são três peças: entrada de e-mail (Gmail via Pub/Sub ou gatilho IMAP), canal Telegram configurado e agendamento, com o Gateway ligado pra qualquer coisa disparar

E a lição mais barata do post: heartbeat é checklist agrupada com contexto de sessão, automação é a rotina de verdade

Próximo passo concreto? Comece pelo caminho de entrada de e-mail mais simples que você conseguir ligar, escreva a regra de relevância no AGENTS.md e crie uma automação com entrega no Telegram

Só depois que essa uma funcionar direitinho é que vale multiplicar monitores

até o próximo post! 😀