Checkpoints: como não perder um workflow longo de IA

Rodei um workflow grande com vários agentes em paralelo. A primeira janela de uso foi consumida rápido, em torno de vinte minutos. Quando o limite resetou e pedi pra continuar, o Claude respondeu que tinha perdido o estado da execução e não conseguia retomar de onde parou. Todo o progresso acumulado evaporou.

Mudei a estratégia. Pedi explicitamente, antes de começar, pra ele implementar checkpoints e salvar os resultados parciais em arquivos .md conforme avançava. Na execução seguinte o limite bateu de novo, mas dessa vez os resultados já estavam no disco. Em vez de recomeçar, dava pra retomar do último ponto concluído.

A diferença entre as duas execuções não foi o modelo nem a tarefa. Foi uma única instrução no início do prompt.

A técnica

Um workflow longo (ou multiagente) tem um ponto cego: o estado vive na sessão. Se a sessão é interrompida (limite de uso, queda, timeout), o que estava em memória e ainda não foi escrito em lugar nenhum se perde. O modelo não tem como adivinhar onde parou se não deixou rastro.

A solução é forçar o rastro. Você instrui o modelo a tratar a própria execução como algo que pode ser interrompido a qualquer momento, e a persistir o progresso em arquivos à medida que conclui cada etapa. Quando você reabre e pede pra continuar, ele lê os arquivos e sabe exatamente o que já está feito.

Cole isto no começo do prompt, antes da tarefa em si:

Garanta que a execução seja resiliente a limites de uso e interrupções.
Salve checkpoints frequentes e persista resultados parciais em arquivos
(um por etapa ou por agente) de forma que o trabalho possa ser retomado
exatamente do último ponto concluído. Ao retomar, leia os arquivos já
salvos antes de refazer qualquer coisa.

O ganho é direto: o pior caso deixa de ser “perdi tudo” e vira “perdi a etapa que estava em andamento”. Em workflow com muitos agentes, onde cada um produz um pedaço, isso é a diferença entre uma execução descartada e uma execução que você emenda em duas ou três sessões.

Como aplicar

1. Coloque a instrução de resiliência no topo, separada da tarefa. Ela governa como o modelo executa, não o que ele executa.
2. Peça um arquivo por unidade de trabalho (uma etapa, um agente, um item da lista). Quanto mais granular o checkpoint, menos você perde numa interrupção.
3. Quando reabrir, comece pedindo pra ele ler os arquivos salvos e te dizer o que falta. Só depois mande continuar. Isso evita refazer o que já existe.

Funciona melhor em ferramentas que escrevem arquivos de verdade no seu disco (Claude Code, por exemplo), porque o checkpoint sobrevive ao fim da sessão. Num chat puro, sem acesso a arquivos, o efeito é menor: o “checkpoint” fica preso na conversa e cai junto com ela.

Um experimento que ainda não testei

Tenho uma hipótese que ainda não confirmei, então trato como especulação, não como técnica comprovada.

A ideia é esperar faltar pouco pro reset da janela de uso e só então iniciar o workflow. Se o consumo atravessar o horário de reset, talvez ele aproveite o resto da janela atual e já comece a consumir a próxima, emendando duas janelas numa execução contínua.

Não sei se o sistema recalcula os limites no meio da execução ou se simplesmente encerra quando a janela original esgota. Pode ser que não funcione assim. Vou testar e, se der em algo, atualizo aqui. Por enquanto, a parte que funciona de verdade é a dos checkpoints: essa eu já vi salvar um trabalho que teria ido pro lixo.