Agentes de IA com tarefas agendadas: como rodar rotinas com segurança

Agentes de IA com tarefas agendadas ficam seguros quando cada execução é tratada como um trabalho pequeno e delimitado: uma tarefa escrita, um gatilho claro, uma regra para execuções perdidas, uma proteção contra sobreposição e um relatório que alguém lê. O modelo é a parte menor do problema. A maioria das falhas vem do agendamento ao redor dele, como uma execução que nunca começou, começou duas vezes ou terminou sem que ninguém percebesse.

Principais pontos

• Mantenha o relógio fora do agente. Um software de agendamento comum dispara a execução, e o agente faz apenas o trabalho de julgamento lá dentro.
• Decida com antecedência o que uma execução perdida significa para cada tarefa: ignorar, rodar atrasada dentro de uma janela ou recuperar a partir do último ponto bem-sucedido.
• Permita uma única execução ativa por tarefa, dê um identificador a cada execução e torne seguras de repetir as ações que saem da empresa.
• Trate o silêncio como falha. A ausência de um relatório deve gerar alerta, assim como uma execução que falhou.
• Comece em modo rascunho, ensaie falhas de propósito e amplie a autoridade do agente um limite de cada vez.

Por que tarefas agendadas de agentes precisam de proteções próprias?

Uma conversa no chat tem uma pessoa no circuito. Quando uma resposta parece errada, ela percebe, pergunta de novo ou para. Uma execução agendada elimina tudo isso. Ninguém está lá para notar um resultado estranho, ninguém esclarece uma entrada ambígua, ninguém vê que o mesmo trabalho começou duas vezes e ninguém percebe quando simplesmente nada acontece.

Isso muda o desenho da solução. Uma tarefa que funciona bem numa conversa pode ser arriscada num agendamento, porque seus erros passam a se repetir em ritmo fixo e chegam sem testemunha. Duas consequências decorrem disso.

Primeiro, pergunte se a tarefa recorrente precisa mesmo de um agente. Boa parte do que roda em horário fixo é previsível: buscar os registros de ontem, comparar duas listas, enviar um aviso se um número passar de um limite. Isso pertence a um fluxo comum. O guia sobre agente de IA ou fluxo determinístico mostra como traçar essa linha. Muitas vezes o melhor desenho é um trabalho determinístico que cuida do gatilho, da coleta de dados e da entrega, e chama o agente apenas para a etapa que exige leitura, resumo ou julgamento.

Segundo, dê às execuções agendadas permissões mais estreitas do que uma sessão interativa teria. Se o agente pode ler bastante, mas só escrever rascunhos, uma execução ruim custa uma revisão. Se ele pode enviar e alterar, uma execução ruim custa uma limpeza. A autoridade deve acompanhar o quanto a execução é observada, e uma execução sem supervisão é a menos observada de todas.

Como definir uma tarefa recorrente para rodar sem supervisão?

A tarefa escrita é a base. Um trabalho recorrente precisa de mais que um prompt: precisa de um contrato que um colega consiga ler e testar. O guia sobre como escrever um contrato de tarefa de IA detalha as partes. Para trabalho agendado, deixe explícito:

• Gatilho: o horário, o fuso e as regras de calendário. Diga o que acontece em feriados, no fim do mês e na mudança de horário, quando houver.
• Janela de entrada: o recorte exato de dados que a execução cobre, como tudo o que ocorreu desde a última execução bem-sucedida, fixado no momento em que a execução começa.
• Ações permitidas: o que a execução pode ler, preparar, gravar e enviar, sistema por sistema.
• Limite de aprovação: quais resultados esperam por uma pessoa antes de qualquer coisa sair da empresa.
• Condições de parada: uma duração máxima, um número máximo de itens por execução e o que fazer quando a entrada não se parece com nada do esperado.
• Destino: para onde vão o resultado e o relatório, e em que formato.
• Responsável: uma pessoa nomeada que recebe as falhas e decide o que fazer.
• Evidência de sucesso: o que um revisor pode conferir para confirmar que a execução cumpriu seu papel.

A janela de entrada merece ênfase. Uma tarefa descrita como revisão dos últimos sete dias quebra na primeira vez que uma execução atrasa ou se duplica. Uma tarefa descrita como revisão de tudo o que veio depois do último corte bem-sucedido resiste aos dois casos, porque é definida por dados e não pelo relógio. Guarde esse corte como um pequeno estado que o harness controla, e não como algo que o agente precisa lembrar.

As condições de parada protegem você de falhas silenciosas. Se uma execução que normalmente trata um lote modesto encontra de repente um lote enorme, o comportamento correto é parar, relatar e perguntar, não seguir adiante a qualquer custo. O mesmo vale para uma entrada vazia quando não deveria estar.

O que deve acontecer quando uma execução é perdida?

Execuções são perdidas por motivos comuns: o agendador ficou fora do ar durante uma manutenção, uma conexão expirou, uma dependência ficou indisponível ou a execução anterior ainda estava rodando. O erro não é perder execuções. O erro é não ter uma regra, de modo que o sistema improvisa: ou nada acontece, ou várias execuções disparam de uma vez quando o serviço volta.

Escolha uma política por tarefa. Este guia de decisão cobre a maioria dos casos:

• Ignorar: use quando o resultado só tem valor num momento específico, como um resumo matinal que estaria velho à tarde. Registre que foi ignorada e avise o responsável.
• Rodar atrasada dentro de uma janela: use quando o resultado mantém o valor por algumas horas. Defina a janela e, depois dela, ignore e avise.
• Recuperar de uma vez: use quando a tarefa processa tudo o que veio desde o último corte bem-sucedido. Uma execução cobre a lacuna, e o corte guardado garante que nada seja contado duas vezes.
• Recuperar em sequência: use quando cada período precisa de seu próprio registro, como resumos periódicos separados. Rode os períodos perdidos em ordem, um de cada vez, e não em paralelo.
• Perguntar a uma pessoa: use quando a tarefa toma uma ação voltada para fora e sensível ao tempo, como mensagens a clientes. Um envio atrasado pode ser pior que nenhum envio.

Uma execução perdida só é recuperável se você souber que ela foi perdida. Adicione uma verificação independente, separada do agendador e do agente, que procure o registro da execução esperada no horário esperado. Se o registro não existir, alerte o responsável. A ausência de sinal é o sinal.

Cenário ilustrativo: uma empresa tem uma tarefa semanal que revisa conversas de clientes ainda sem resposta e prepara, para o responsável da conta, um resumo com rascunhos de acompanhamento. Numa segunda-feira, o agendador fica fora do ar por manutenção. A política dessa tarefa diz para rodar atrasada até o meio-dia de terça e, depois disso, ignorar e avisar. O agendador volta na tarde de segunda, a execução começa, lê o corte da última execução bem-sucedida e cobre toda a lacuna de uma só vez. Como o corte está guardado, nenhuma conversa aparece duas vezes. Se o agendador tivesse voltado só na quarta, a execução teria sido ignorada, o responsável teria sido avisado e a próxima execução regular ainda cobriria a lacuna. Nos dois casos, o responsável sabe o que aconteceu sem precisar perguntar.

Como evitar execuções sobrepostas e ações duplicadas?

A sobreposição acontece com mais frequência do que se imagina. Uma execução leva mais tempo que o intervalo. Alguém a dispara manualmente para testar enquanto o agendamento também dispara. Uma nova tentativa começa enquanto a original ainda está trabalhando. Existem dois agendadores depois de uma migração e ninguém desligou o antigo. O resultado é processamento em dobro, edições conflitantes ou a mesma mensagem enviada duas vezes.

Estes controles são os mais importantes, aproximadamente nesta ordem:

• Uma execução ativa por tarefa. Use um bloqueio com prazo de validade, para que uma execução que travou acabe liberando a vez e não bloqueie a tarefa para sempre.
• Uma política de sobreposição definida. Quando um gatilho chega com uma execução ativa, ou você ignora o novo e registra, ou enfileira no máximo um. Ignorar é o padrão mais seguro, porque uma fila ilimitada transforma um atraso em uma rajada.
• Um identificador de execução formado pela tarefa e pelo período coberto. Ele liga cada linha de log, rascunho e relatório a uma execução e permite reconhecer uma segunda tentativa para o mesmo período.
• Repetição segura para ações que saem da empresa. Envios, criações e atualizações devem carregar uma chave derivada da execução e do item, de modo que uma repetição seja reconhecida e ignorada. Esse padrão se chama idempotência, e provedores de pagamento publicam um exemplo conhecido no desenho de suas requisições idempotentes.
• Progresso retomável. Uma execução longa que falha no meio deve continuar de um ponto salvo, em vez de recomeçar e repetir o trabalho inicial. Veja checkpoints de agentes de IA para entender como isso funciona.
• Propriedade clara dos registros. Se duas tarefas agendadas podem editar o mesmo registro, uma delas vai acabar errada. Atribua cada tipo de alteração a uma única tarefa.

Novas tentativas também são uma forma de sobreposição. Se uma etapa falha e o harness tenta de novo, a etapa já precisa ser segura de repetir antes de as tentativas serem ativadas.

O que cada execução deve relatar e como colocar no ar?

Um relatório não é um log. Logs servem para diagnóstico de quem já está olhando. O relatório é para o responsável que não está, e deve ser lido em menos de um minuto. Use sempre o mesmo formato, para que qualquer desvio seja visível de relance. Cada relatório deve dizer:

• Qual foi a execução e qual período ou corte ela cobriu.
• O status: concluída, parcial, ignorada ou com falha.
• O que ela examinou e quanto.
• O que ela alterou, preparou ou enviou, com links para a evidência.
• O que precisa de decisão humana, escrito como uma decisão e não como um monte de contexto.
• O que ela escolheu não fazer, e por quê.

Guarde os rastros detalhados separadamente, para diagnóstico. O material introdutório sobre observabilidade do OpenTelemetry é uma boa referência para os tipos de sinais envolvidos, e as notas de engenharia da Anthropic sobre harnesses para agentes de longa duração mostram por que a estrutura ao redor do modelo, e não um único prompt, mantém o trabalho repetido consistente.

Depois, coloque a tarefa no ar em etapas:

• Rode manualmente em um ambiente de teste, com dados parecidos com os reais, e leia cada resultado.
• Ative o agendamento em modo somente rascunho, de modo que todo resultado espere revisão.
• Ensaie falhas de propósito: expire a conexão, atrase o gatilho, inicie duas execuções juntas, ofereça uma entrada vazia. Confirme que as políticas acima se comportam como escritas.
• Revise os relatórios em uma cadência fixa. Quando eles se mantêm corretos, amplie um limite de cada vez, como deixar uma ação de baixo risco seguir sem aprovação.
• Marque uma data para revisar o próprio agendamento. Tarefas sobrevivem ao seu propósito, e um relatório que ninguém lê é um custo.

A Be Human trata o agendamento como parte do harness, e não como uma instrução dentro de um prompt. Em um projeto gerenciado, cada função recorrente começa com uma tarefa escrita, um limite de aprovação, uma política para execuções perdidas e sobrepostas e um formato de relatório combinado antes da primeira execução. A operação contínua pode incluir monitoramento de execuções que não apareceram, avaliações recorrentes, revisão de integrações e permissões, e resposta a incidentes com uma pessoa nomeada recebendo o escalonamento.

Perguntas frequentes

Com que frequência um agente de IA agendado deve rodar? Na mesma frequência com que muda a decisão que ele apoia, e não mais que isso. Uma revisão semanal que ninguém usa no dia a dia não ganha nada com uma execução diária, e cada execução extra aumenta a carga de revisão e a chance de sobreposição. Comece com um ritmo mais lento e acelere quando os relatórios mostrarem que o trabalho chega tarde demais para ser útil.

Um agente agendado pode enviar mensagens a clientes por conta própria? No início, não. Comece com rascunhos que uma pessoa aprova e passe tipos individuais de mensagem para envio automático só depois que os relatórios se mostrarem corretos de forma consistente por um bom tempo. Mantenha atrás de aprovação, de forma permanente, tudo o que for sensível ou difícil de retirar.

E se o resultado do agente for um pouco diferente a cada execução? Isso é esperado, então teste propriedades e não a redação exata. Verifique se o relatório tem as partes obrigatórias, se a evidência citada existe, se as contagens batem com a entrada e se nada fora das ações permitidas aconteceu. Um conjunto de avaliação recorrente, montado com exemplos reais, ajuda a detectar desvios depois de mudanças em instruções ou ferramentas.

Quem deve ser o responsável por uma tarefa agendada? Uma pessoa nomeada que perceberia se o resultado estivesse errado, e não apenas quem configurou a tarefa. Ela recebe os alertas de falha, lê os relatórios e decide quando a tarefa deve mudar ou acabar. Sem esse responsável, até um agendamento bem construído vira aos poucos uma fonte de ruído que ninguém lê.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.