Nem todo trabalho termina durante uma conversa. Uma cotação espera fornecedor, uma ordem depende de peça, uma aprovação expira e uma inspeção pode ficar offline até o fim do turno. Se o agente precisa permanecer ativo por horas ou dias, memória de chat e um processo em loop não formam uma operação confiável.
Agentes de longa duração precisam separar raciocínio momentâneo de estado persistente. O sistema registra objetivo, artefatos, decisões, prazo, tentativas e próximo passo; o agente é chamado novamente quando surge um evento útil. Persistir trabalho não significa manter um modelo pensando continuamente.
Em uma frase
Um processo longo deve avançar por eventos e checkpoints persistentes, podendo pausar, retomar, expirar e trocar de responsável sem perder sua história.
A dor da automação que esquece entre um turno e outro
Um agente inicia a compra, pede três cotações e encerra a sessão. No dia seguinte, não sabe quais fornecedores responderam, qual política foi usada ou se o preço mudou depois da aprovação. A equipe recompõe a história por e-mail e planilha, anulando o ganho da automação.
Manter o agente em execução permanente cria outro risco: consumo crescente, credencial longa, retry sem fim e decisão baseada em contexto velho. Processos reais atravessam indisponibilidade, mudança de turno e cancelamento. Cada espera precisa de um estado explícito e de uma regra sobre o que torna a decisão inválida.
Longa duração é um problema de sistema, não só de janela
A engenharia da Anthropic relata desafios de agentes em tarefas que atravessam várias janelas de contexto. Para desenvolvimento de software, usou inicialização, progresso incremental e artefatos claros entre sessões. O próprio texto reconhece perguntas abertas e limita o experimento ao domínio de código.
A lição transferível não é copiar o harness, mas preservar estado fora da memória transitória. Em orientação de avaliações, a Anthropic distingue a fala final do estado real no ambiente. Para uma empresa, “aguardando aprovação” e “concluído no ERP” precisam ser eventos verificáveis.
Exemplo composto: compra de uma peça crítica
Em um exemplo composto, o agente identifica uma peça, prepara pedido de cotação e registra três tarefas externas. Cada resposta atualiza o processo por evento. Às 18h, duas propostas chegaram; a terceira tem prazo até 10h. O agente pausa sem consumir inferência e deixa resumo estruturado para o turno seguinte.
Quando a última cotação chega, preço e prazo são comparados por regra. A aprovação expira se estoque ou condição comercial mudar. Depois do aceite, uma chave idempotente cria a solicitação uma única vez e a confirmação do ERP encerra o processo. Falha abre exceção com dono, em vez de reiniciar toda a conversa.
Estado durável, evento útil e próxima ação
Modele uma máquina de estados compreensível: criado, em análise, aguardando dado, aguardando aprovação, pronto para executar, processando, confirmado, recusado, expirado e falho. Guarde entradas, versões, artefatos e responsáveis. Eventos retomam o trabalho; relógios expiram ou escalam. O modelo interpreta somente quando existe decisão a tomar.
Checkpoints precisam ser pequenos e verificáveis. Não confie apenas num resumo gerado; preserve identificadores e fatos nas fontes responsáveis. Defina prazo máximo, orçamento, cancelamento, compensação e ação segura após falha. Teste retomada com versão nova do agente e com aprovação antiga.
Controles para processos de horas ou dias
- Estados, transições e condições de término estão definidos fora do prompt.
- Cada espera possui prazo, evento de retomada, escalonamento e responsável.
- Artefatos e fatos persistem com versão, origem e acesso delimitado.
- Repetição usa idempotência e decisões sensíveis têm validade explícita.
- Pessoa consegue consultar, cancelar, corrigir ou assumir o processo.
Como a Uiless ajuda
A Uiless separa a conversa da execução. Solicitações carregam identidade, contexto e estado; ferramentas e integrações usam idempotência, timeout e circuit breaker; aprovações e evidências permanecem associadas à capacidade. O canal pode encerrar sem apagar a operação.
Isso permite que uma pessoa inicie por voz, outra aprove no painel e o sistema retorne pelo WhatsApp quando houver resultado. A plataforma não mantém um agente “pensando” durante toda a espera: organiza eventos e chama inteligência quando a próxima decisão realmente exige interpretação.
Proteja retomadas com integrações resilientes e defina falhas em rollback e fail-closed.
