Continue-As-New em agentes de IA: como operar

Uma execução pode continuar útil depois que seu histórico ficou pesado

Um agente acompanha uma carteira de clientes durante meses. Recebe eventos, consulta sistemas, espera aprovações, prepara ações e registra resultados. A identidade do trabalho precisa continuar. O histórico técnico da primeira execução, porém, cresce a cada timer, chamada, sinal e tentativa.

Em algum momento, manter tudo dentro da mesma execução aumenta custo de replay, tempo de recuperação e risco de atingir limites da plataforma. Reiniciar do zero também seria perigoso: o agente poderia perder pendências, repetir efeitos ou esquecer qual versão de política estava em vigor.

O padrão Continue-As-New encerra uma execução durável num ponto seguro e inicia outra com histórico limpo, carregando somente o estado necessário para continuar o mesmo trabalho lógico.

A documentação do Temporal descreve a nova execução com o mesmo Workflow ID, outro Run ID e um Event History próprio. A documentação do Microsoft Durable Task apresenta a mesma ideia operacional: preservar a identidade da instância, reiniciar a geração da orquestração e zerar o histórico acumulado.

Este guia trata o mecanismo como uma fronteira de operação. A API exata, o comportamento de eventos pendentes e os limites variam por plataforma e linguagem.

Que problema o Continue-As-New resolve

Uma execução durável registra eventos para conseguir reconstruir seu estado e retomar depois de falhas. Esse registro pode incluir:

início e conclusão de atividades;
timers criados e disparados;
sinais externos recebidos;
tentativas e erros;
decisões de branching;
chamadas de workflows filhos;
mudanças de estado reproduzíveis.

Esse histórico sustenta confiabilidade. Quando cresce sem limite, ele também se torna uma carga operacional.

Continue-As-New permite criar uma cadeia de execuções. Cada run conserva seu próprio histórico. O estado atual atravessa a fronteira como entrada explícita da próxima execução.

A separação útil é esta:

identidade lógica: o objeto empresarial acompanhado ao longo do tempo;
execução técnica: uma geração delimitada do workflow;
estado de continuidade: dados mínimos que permitem à próxima geração retomar;
arquivo de evidência: histórico anterior preservado conforme auditoria e retenção.

O padrão reduz o histórico ativo. Ele não apaga a responsabilidade pelo que aconteceu antes.

Diferença para checkpoint, retentativa e novo agendamento

Os mecanismos se relacionam, mas respondem a problemas próprios.

Checkpoint

Um checkpoint guarda estado suficiente para retomar depois de interrupção. A mesma execução pode usar vários checkpoints. Continue-As-New usa um ponto de continuidade para iniciar outra execução com histórico fresco.

O guia sobre agentes de IA para tarefas longas explica como dividir trabalho e criar checkpoints verificáveis.

Retentativa

Retentativa repete uma operação que falhou dentro de uma política de erro. Ela preserva a intenção da tentativa anterior e consome teto, tempo e orçamento definidos. Continue-As-New não serve para esconder falha nem reiniciar indefinidamente uma atividade problemática.

Novo agendamento

Uma ocorrência agendada representa outra competência ou janela de trabalho. Continue-As-New mantém a continuidade do mesmo objeto lógico. A página sobre tarefas agendadas para agentes de IA cobre calendário, sobreposição e validade de cada ocorrência.

Migração de estado

Migrar estado altera schema ou significado entre versões. Continue-As-New pode reduzir a quantidade de versões ativas, mas o payload transferido continua sujeito à compatibilidade. O guia de migração de estado de agentes trata essa transformação.

Quando considerar uma nova execução

A decisão deve ocorrer em pontos onde o workflow consegue produzir um estado consistente.

Sinais comuns incluem:

histórico se aproximando do limite recomendado pela plataforma;
replay ou retomada ficando mais lentos;
workflow periódico sem encerramento natural;
objeto durável acumulando meses de eventos;
versão antiga do código permanecendo ativa por tempo excessivo;
volume de sinais crescendo além da janela útil;
necessidade de arquivar uma fase e abrir outra;
ciclo empresarial concluído, como fechamento mensal ou renovação anual.

A documentação do Temporal recomenda consultar o indicador de Continue-As-New sugerido pela própria plataforma em pontos seguros de checkpoint. Um número fixo de iterações pode servir em teste, mas tende a ignorar a diferença de peso entre execuções.

O gatilho técnico não deveria atuar sozinho. A transição também precisa respeitar o estado empresarial. Um histórico grande durante uma aprovação, uma chamada externa ou uma compensação não autoriza cortar a execução naquele instante.

Escolha uma fronteira segura

A troca entre runs precisa acontecer depois que o trabalho atual chegou a uma condição conhecida.

Uma fronteira segura costuma exigir:

atividades iniciadas concluídas ou canceladas de forma confirmada;
efeitos externos registrados com identificador e estado;
sinais recebidos incorporados ou preservados segundo a plataforma;
aprovação pendente representada no estado transferido;
timers relevantes recriados com prazo absoluto;
versão do schema declarada;
chave de idempotência preservada;
motivo da renovação registrado;
próxima ação legível;
teste de integridade aprovado.

A documentação do Microsoft Durable Task alerta que resultados de tarefas incompletas são descartados quando a orquestração chama Continue-As-New. Também registra diferenças entre SDKs para preservação de eventos externos não processados. Essa variação impede uma regra genérica de implementação.

Antes da transição, confirme o comportamento da versão e da linguagem adotadas.

Transfira estado mínimo, mas suficiente

Copiar todo o histórico para a entrada seguinte apenas muda o excesso de lugar. Resumir demais pode eliminar evidência, autoridade e proteção contra duplicidade.

Um estado de continuidade pode conter:

{
  "workflow_id": "conta-ACME-renovacao",
  "state_schema_version": 3,
  "process_policy_version": "renovacao-2026-09",
  "cycle": 7,
  "business_state": "aguardando_aprovacao",
  "customer_id": "CLI-1042",
  "completed_steps": ["coletar_uso", "validar_entregas"],
  "pending_step": "aprovar_condicao_comercial",
  "pending_approval_id": "APR-8831",
  "confirmed_effects": ["briefing:BRF-771"],
  "idempotency_keys": ["CLI-1042:briefing:v2"],
  "open_questions": ["prazo final não confirmado"],
  "expires_at": "2026-10-08T18:00:00Z",
  "previous_run_id": "RUN-006",
  "renewal_reason": "history_limit_suggested"
}

O exemplo é sintético. Ele mostra cinco grupos que merecem separação:

identidade e versão;
estado empresarial;
trabalho concluído e pendente;
efeitos e chaves de proteção;
validade e vínculo com a execução anterior.

Não coloque credenciais, documentos completos ou dados sem função no payload. Use referências protegidas quando a próxima execução puder consultar a fonte autorizada.

Preserve a cadeia de evidência

A nova execução precisa apontar para a anterior. A anterior precisa registrar que terminou por renovação planejada, não por sucesso final ou falha.

Mantenha pelo menos:

Workflow ID ou identidade lógica;
Run ID anterior e seguinte;
motivo da transição;
horário;
versão do código, schema e política;
hash ou versão do estado transferido;
contagem de eventos ou indicador que motivou a troca;
tarefas abertas no instante da transição;
eventos preservados, descartados ou reencaminhados;
responsável técnico pela configuração;
dono operacional do objeto.

Essa ligação permite responder a uma pergunta simples meses depois: qual execução tomou cada decisão e com quais entradas?

O histórico antigo pode ir para retenção mais barata ou arquivo, conforme a plataforma e a política. Arquivamento não deve romper acesso a evidências necessárias para auditoria, incidente ou disputa.

Trate sinais e eventos em trânsito

A fronteira mais delicada costuma envolver informação que chegou perto da renovação.

Considere três classes.

Evento já aplicado

O estado transferido precisa refletir o efeito. Registre o identificador do evento e o resultado. Reaplicar na execução nova criaria duplicidade.

Evento recebido e ainda não processado

A plataforma pode preservar, descartar ou exigir configuração específica. O Microsoft Durable Task documenta diferenças entre .NET, Java, Python e JavaScript. Teste o SDK real e declare a política.

Quando a preservação automática não for adequada, grave o evento numa caixa durável própria com identidade, ordem e estado de consumo.

Evento que chega durante a transição

A entrada precisa ter um dono único. Use a identidade estável do workflow e a garantia oferecida pelo orquestrador. Evite publicar diretamente para um Run ID que mudará.

Teste concorrência com eventos antes, durante e depois do corte. O caso de borda é exatamente onde uma demonstração feliz costuma ficar criativa demais.

Recrie timers com prazo absoluto

Um timer relativo pode mudar de significado entre execuções.

Se a aprovação expira em 8 de outubro às 18h, transfira esse horário absoluto. A próxima execução calcula o tempo restante. Criar outro timer de sete dias renovaria indevidamente a autorização.

Faça o mesmo com:

prazo de resposta;
janela comercial;
validade de preço;
retenção de pendência;
revisão periódica;
timeout total do caso;
data de encerramento.

Quando o prazo já venceu, a nova execução entra no estado de expiração ou revalidação. Ela não deve recriar uma espera positiva apenas porque começou agora.

Não carregue aprovação sem verificar o objeto

Uma aprovação pertence ao conteúdo que a pessoa examinou.

Ao atravessar Continue-As-New, preserve:

identificador da aprovação;
ator e função;
objeto apresentado;
parâmetros aprovados;
versão e hash;
horário e expiração;
restrições;
efeito ainda permitido.

Se o estado foi compactado, migrado ou enriquecido entre runs, compare o objeto atual com o aprovado. Mudança de destinatário, preço, canal, documento ou ação pede revalidação.

A renovação técnica da execução não renova autoridade humana.

Separe continuidade de atualização de versão

Continue-As-New pode ajudar a tirar workflows antigos de uma versão de código. Isso exige uma política explícita.

Existem três possibilidades:

iniciar a próxima execução na mesma versão e migrar depois;
iniciar na versão atual compatível com o estado transferido;
bloquear a transição até transformar ou revisar o estado.

Não use a fronteira como conversor implícito. Registre state_schema_version, valide os campos e encaminhe qualquer ambiguidade. Uma execução fresca com estado mal interpretado continua errada, só ficou mais ágil.

Exemplo: agente que acompanha uma conta B2B

Considere um agente fictício que reúne sinais de uma conta, prepara briefing semanal e acompanha pendências de renovação.

Identidade lógica

conta:CLI-1042

Trabalho contínuo

receber eventos de atendimento, entrega e comercial;
atualizar estado confirmado;
preparar briefing semanal;
abrir perguntas para o gerente da conta;
aguardar aprovações antes de qualquer comunicação.

Critério de renovação

O orquestrador sugere Continue-As-New ou o ciclo mensal fecha, desde que não exista atividade em andamento nem efeito incerto.

Estado transferido

versão do schema;
saúde da conta por componentes confirmados;
compromissos abertos com fonte;
próxima revisão;
aprovação pendente;
efeitos já confirmados;
IDs dos últimos eventos consumidos;
prazos absolutos;
referência ao run anterior.

Estado que fica no histórico anterior

chamadas intermediárias já consolidadas;
timers concluídos;
tentativas encerradas;
eventos antigos incorporados;
detalhes técnicos sem utilidade para a próxima decisão.

Gate

Antes de iniciar o novo run, um teste confirma que contagens, pendências, IDs de eventos e efeitos externos coincidem com as fontes oficiais.

O objeto empresarial continua. A carga de replay recomeça pequena.

Teste a fronteira, não apenas o caminho feliz

Inclua casos como:

Continue-As-New sugerido durante atividade ativa;
sinal chegando no instante da transição;
timer pendente;
aprovação próxima da expiração;
escrita externa confirmada com resposta perdida;
payload sem campo obrigatório;
schema antigo;
execução nova iniciada duas vezes;
falha ao criar a próxima geração;
evento reaparecendo depois do corte;
cancelamento solicitado durante a renovação;
histórico anterior indisponível para auditoria;
versão nova incapaz de ler o estado;
workflow que deveria encerrar, mas renova outra vez.

Verifique:

uma única execução recebe novos eventos;
nenhuma atividade incompleta é tratada como concluída;
efeitos externos não se repetem;
timers mantêm o prazo original;
aprovações conservam objeto e validade;
a cadeia anterior e seguinte é consultável;
o dono operacional enxerga o mesmo estado antes e depois;
cancelamento e encerramento definitivo continuam possíveis.

Métricas para operar a cadeia

Acompanhe:

tamanho do histórico por run;
tempo de replay e recuperação;
quantidade de runs por objeto;
renovações sugeridas e executadas;
transições bloqueadas por atividade ou estado incerto;
sinais preservados, repetidos ou perdidos;
timers recriados incorretamente;
aprovações revalidadas;
duplicidades evitadas ou produzidas;
payloads incompatíveis;
tempo entre o encerramento de um run e o início do seguinte;
objetos sem dono ou sem data de encerramento.

Menos eventos no histórico ativo não prova continuidade correta. Leia desempenho ao lado de integridade, duplicidade e capacidade de auditoria.

Erros comuns

Renovar em qualquer ponto

A execução corta enquanto uma atividade, timer ou sinal ainda precisa de tratamento. Escolha fronteiras depois de estado consistente.

Transferir todo o histórico

O payload fica pesado, mistura fato com tentativa e prolonga dados sem necessidade. Transfira estado atual, referências e evidências essenciais.

Resumir até perder autoridade

“Cliente aprovado” não informa quem aprovou, qual objeto, quando e até quando. Preserve decisões com identidade e validade.

Usar Continue-As-New como retentativa infinita

Uma falha permanente reaparece em runs sucessivos. Erro precisa de classificação, teto e destino.

Supor que todos os SDKs preservam eventos igualmente

A documentação oficial mostra comportamentos diferentes. Valide plataforma, linguagem, versão e configuração.

Nunca encerrar o objeto

Uma execução eterna pode representar um objeto durável. O objeto ainda precisa de critério para conclusão, cancelamento, arquivamento ou transferência.

Fontes oficiais verificadas em 30 de setembro de 2026

Temporal: Continue-As-New, para identidade do workflow, Run ID, Event History, estado transferido e indicação de renovação.
Microsoft Learn: Eternal Orchestrations in Durable Task, para reset de histórico, identidade da instância, tarefas incompletas, eventos externos, encerramento e diferenças entre SDKs.

As fontes descrevem mecanismos de plataformas específicas. O desenho empresarial de estado, aprovação, idempotência, retenção e dono continua sob responsabilidade da aplicação e da empresa.

Checklist antes de renovar uma execução

[ ] A identidade lógica permanece estável?
[ ] Existe motivo verificável para abrir outro run?
[ ] A transição acontece num ponto seguro?
[ ] Atividades incompletas foram concluídas ou tratadas?
[ ] Eventos em trânsito possuem política testada?
[ ] O payload contém estado mínimo e suficiente?
[ ] Schema, código e política estão versionados?
[ ] Efeitos externos e chaves de idempotência atravessam a fronteira?
[ ] Timers usam prazo absoluto?
[ ] Aprovações mantêm objeto, ator e validade?
[ ] A execução nova aponta para a anterior?
[ ] O histórico anterior continua acessível conforme retenção?
[ ] O SDK real foi testado para sinais e eventos pendentes?
[ ] Cancelamento e encerramento definitivo continuam possíveis?
[ ] O dono operacional consegue conferir a continuidade?

A execução muda; a responsabilidade continua

Continue-As-New permite que um agente acompanhe trabalho durável sem carregar uma história técnica ilimitada em cada retomada. O ganho aparece quando a fronteira conserva identidade, estado empresarial, efeitos confirmados, eventos pendentes, prazos e aprovações.

Defina pontos seguros, transfira somente o necessário, preserve a cadeia de evidência e teste os eventos que chegam durante o corte. Assim, uma execução fresca continua o trabalho certo, em vez de começar outra interpretação sobre a mesma realidade.