Agentes de IA de longa duração precisam de canais duráveis

A documentação do modo em segundo plano da OpenAI agora descreve um problema comum em agentes: tarefas de raciocínio podem levar minutos, desenvolvedores podem consultar uma resposta pelo ID, cancelar essa resposta e retomar um stream a partir de um número de sequência registrado.¹

Quais são os principais aprendizados?

• Uma execução de agente de longa duração precisa de um endereço. O cliente precisa conseguir se reconectar ao mesmo trabalho, transmitir a partir de um cursor conhecido, enviar um comando de direcionamento, cancelar a execução e inspecionar evidências.
• Polling sozinho oferece um contrato frágil. Polling pode informar o status, mas um trabalho sério de agente também precisa de comandos, histórico de eventos, streams retomáveis, artefatos, autorização e pontos de verificação.
• Execução durável resolve só parte do sistema. Fluxos de trabalho no estilo Temporal preservam o estado de execução e o histórico de eventos, mas o usuário ainda precisa de uma superfície de comunicação durável em torno do trabalho em andamento.²³
• WebSockets ajudam, mas um socket não é o endereço inteiro. Uma conexão perdida não deve apagar o caminho do usuário de volta para a execução do agente.
• A superfície do produto importa. O usuário deve ver uma execução coerente, com evidências, decisões e próximas ações, não logs espalhados e textos de status otimistas.

Agentes de IA de longa duração não cabem no antigo formato de requisição e resposta. Uma requisição normal tem um endpoint, uma resposta e um timeout. Uma execução séria de agente tem duração, histórico de eventos, artefatos intermediários, interrupções do usuário, estado de modelo e ferramentas, regras de cancelamento e uma pessoa que pode sair e voltar depois.

O objeto que falta não é mais uma mensagem de chat. O objeto que falta é um canal durável: um endereço estável para uma parte do trabalho que ainda está em execução.

Eu já argumentei que agentes gerenciados estão absorvendo a infraestrutura de execução e que rastreamentos de execução de agentes estão se tornando o contrato do ambiente de execução. Canais duráveis ficam entre essas duas ideias. Um rastreamento prova o que aconteceu. Um ambiente de execução gerenciado mantém o trabalho vivo. Um canal durável permite que o produto e o usuário conversem com o trabalho enquanto ele existe.

O que quebra no antigo modelo de requisição?

O antigo modelo web pressupõe que a computação termina dentro de uma requisição ou passa para um job em segundo plano. O banco de dados armazena o estado durável. O servidor da aplicação continua sem estado. Um cliente pode atualizar a página, cair em outro servidor e ler a mesma linha do banco.

O trabalho de agente tensiona esse modelo de três formas. Ele pode rodar por minutos ou horas. Carrega estado de processo que não se reduz bem a um único registro no banco. E precisa de controle bidirecional: acompanhar, interromper, aprovar, redirecionar, cancelar e retomar.

Zak Knill descreveu a mesma pressão como um problema de roteamento. O post dele de maio de 2026 argumenta que trabalhos de agente longos, com estado e interativos precisam de uma primitiva roteável capaz de endereçar o processo que está fazendo o trabalho, não apenas o banco de dados que armazena seus resultados.⁴ O ponto útil desse enquadramento: o cliente quer dizer “entregue o comando Y para a execução X”, mesmo que o socket, worker, aba ou processo original tenha desaparecido.

Jobs em segundo plano ainda servem para tarefas simples. Redimensionar uma imagem, exportar uma fatura ou rodar uma sincronização noturna talvez precise apenas de queued, running, succeeded ou failed. O trabalho de agente cruza outra linha quando o usuário precisa orientar o trabalho antes que ele termine.

Por que polling fica aquém?

Polling dá ao cliente uma forma de perguntar: “já terminou?” Ele não entrega ao cliente um contrato completo de interação.

O modo em segundo plano da OpenAI inclui polling porque polling resolve o problema de timeout. A documentação orienta desenvolvedores a recuperar uma resposta em segundo plano enquanto o status permanece queued ou in_progress, e então parar quando ela chega a um estado terminal.¹ A mesma página também expõe cancelamento e retomada de stream com um cursor sequence_number, o que aponta para além do polling básico, em direção a um contrato de execução mais rico.¹

Um produto que para no polling costuma espalhar o estado do agente por lugares demais:

Polling pode continuar sendo um caminho de acesso. O erro é tratar polling como o contrato do produto.

O que um canal durável deve conter?

Um canal durável é um contrato de comunicação nomeado em torno de uma execução. A implementação pode usar um motor de fluxo de trabalho, fila, tabela de eventos, WebSocket, stream SSE, tópico pub/sub, sessão de agente gerenciado ou uma mistura dessas peças. O contrato do produto importa mais que o transporte.

O contrato mínimo tem nove partes:

Cada evento precisa de tipo, número de sequência, timestamp, ator, referência de payload e política de ocultação. Sem essa estrutura, o log de eventos vira só mais uma transcrição de chat.

O canal também precisa de bom senso de produto. Não transmita cada token quando o usuário precisa de decisões. Não esconda falhas de ferramentas atrás de um spinner simpático. Não transforme um agente em execução numa tempestade de notificações. Um bom canal mostra os poucos eventos que ajudam o usuário a confiar, orientar ou interromper o trabalho.

Como os sistemas existentes apontam para esse padrão?

Temporal dá ao lado da execução um vocabulário maduro. Uma execução de fluxo de trabalho tem histórico de eventos, replay, código determinístico de fluxo de trabalho e atividades para trabalhos no mundo externo, como chamadas de API, consultas de banco de dados, chamadas de LLM e I/O de arquivos.² A documentação de troca de mensagens no TypeScript SDK do Temporal descreve fluxos de trabalho como serviços com estado que recebem consultas, sinais e atualizações. Clientes podem recuperar um identificador de fluxo de trabalho pelo ID do fluxo de trabalho, consultar estado, enviar sinais e executar atualizações.³

Esse modelo se encaixa bem em trabalho de agente. Consultas respondem “que estado a execução informa?” Sinais respondem “por favor, mude de direção.” Atualizações respondem “faça uma mudança rastreada e retorne um resultado.” O histórico de eventos responde “o que aconteceu?” Uma equipe não precisa usar Temporal para aprender com esse formato, mas o formato oferece aos produtos de agente um vocabulário melhor que “job em segundo plano mais chat”.

Cloudflare Durable Objects apontam para outra parte: coordenação endereçável. A Cloudflare descreve cada Durable Object como uma instância globalmente única, com armazenamento, útil para coordenação com estado entre múltiplos clientes.⁵ A documentação de WebSocket descreve conexões bidirecionais de longa duração e hibernação que mantém clientes conectados enquanto o objeto dorme, e depois acorda o objeto quando uma mensagem chega.⁶ Isso não torna Durable Objects um ambiente de execução universal para agentes. Mas mostra por que um objeto de coordenação endereçável parece natural para superfícies de agente ao vivo.

O texto da Anthropic sobre agentes de longa duração acrescenta o lado do trabalho humano. O post diz que agentes ainda têm dificuldade ao atravessar muitas janelas de contexto e descreve um padrão em que sessões posteriores fazem progresso incremental enquanto deixam artefatos claros para a próxima sessão.⁷ Canais duráveis devem levar esses artefatos para a superfície do produto, não enterrá-los em logs privados.

O que eu construiria primeiro?

Eu começaria com um pequeno serviço de execuções, não uma grande plataforma de orquestração.

Crie uma tabela runs com proprietário, status, timestamps e resumo atual. Crie uma tabela ou stream run_events com números de sequência monotonicamente crescentes. Armazene payloads grandes e artefatos separadamente, depois referencie-os a partir dos eventos. Adicione um endpoint de stream retomável e um endpoint de sinal tipado. Torne o cancelamento idempotente. Registre toda transição de estado no log de eventos.

Depois, limite o vocabulário de eventos:

Agora a UI consegue mostrar uma execução coerente. O usuário pode sair, voltar, revisar eventos, inspecionar artefatos e orientar tudo a partir do mesmo endereço. O agente pode parar de afirmar sucesso em prosa e começar a anexar evidências às transições de estado.

O que as equipes devem evitar?

Evite três atalhos.

Primeiro, evite uma transcrição puramente em chat. O chat pode iniciar trabalho e coletar esclarecimentos. Ele não deve ser o único objeto de execução para uma tarefa de longa duração.

Segundo, evite streaming bruto de tokens como principal superfície de progresso. Streams de tokens ajudam um desenvolvedor a depurar latência, mas a maioria dos usuários precisa de marcos, bloqueios, artefatos e decisões. Um canal durável ainda pode expor eventos brutos para inspeção especializada.

Terceiro, evite vazamento de processos privados. Uma superfície pública de produto deve mostrar evidências, não prompts privados, corpos de hooks, caminhos de arquivos locais ou mecanismos internos de pontuação. O usuário precisa do suficiente para confiar no trabalho. Ele não precisa de cada truque interno que tornou o trabalho possível.

Essa linha de privacidade também vale para textos públicos sobre sistemas de agentes. Compartilhe o contrato. Mantenha a máquina privada em privado.

Como um canal durável muda a avaliação?

Um canal durável torna a avaliação menos teatral.

Em vez de perguntar se a resposta final parece plausível, o avaliador pode inspecionar a execução:

• A execução começou com o proprietário, as permissões e o escopo corretos?
• O agente emitiu um plano antes de agir?
• Todo artefato alegado veio de um evento registrado?
• As falhas produziram pontos de verificação úteis?
• Os sinais do usuário mudaram a execução da forma esperada?
• O cancelamento terminou com um único estado terminal?
• O relatório final citou evidências do log de eventos?

Essa lista transforma a barreira de evidências em algo que o ambiente de execução pode sustentar diretamente. Ela também se conecta à camada de limpeza: muitos produtos de agente vão vencer ao tornar execuções confusas compreensíveis, retomáveis e revisáveis.

Resumo rápido

Agentes de IA de longa duração precisam de canais duráveis porque o usuário precisa de um caminho estável de volta ao trabalho. Polling pode informar status, mas não consegue carregar o contrato inteiro sozinho. Uma boa execução de agente precisa de um ID de fluxo de trabalho, eventos ordenados, streams retomáveis, sinais tipados, cancelamento idempotente, referências a artefatos, permissões e pontos de verificação legíveis por humanos. Execução durável mantém o trabalho vivo; canais duráveis permitem que o usuário e o produto interajam com ele.

FAQ: agentes de IA de longa duração e canais duráveis

Agentes de IA de longa duração exigem Temporal?

Não. Temporal dá às equipes um vocabulário forte de fluxo de trabalho e um modelo de execução maduro, mas o contrato de canal durável pode rodar em infraestrutura mais simples. Comece com IDs estáveis de execução, eventos ordenados, streams retomáveis, comandos tipados e artefatos. Migre para um motor de fluxo de trabalho quando novas tentativas, replay, temporizadores e escala operacional justificarem.

WebSockets bastam para progresso de agentes?

Não. WebSockets oferecem uma conexão bidirecional ao vivo. O produto ainda precisa de um endereço durável, histórico de eventos, cursor de reconexão, permissões e estados terminais. Um socket pode transportar um canal, mas não deve definir o canal inteiro.

Polling é sempre ruim?

Não. Polling funciona para verificações simples de status e pode continuar como caminho de fallback. Os problemas começam quando polling vira a única forma de observar, orientar ou recuperar uma execução de agente de longa duração.

O que uma equipe pequena deve construir primeiro?

Construa um recurso runs e um log run_events somente para anexação. Adicione um stream retomável quando o log de eventos tiver números de sequência. Adicione sinais tipados apenas para comandos que o produto consegue cumprir com segurança: aprovar, pausar, revisar, adicionar contexto e cancelar.

O que pertence aos eventos de execução de agentes?

Registre transições de estado, planos, início e fim de ferramentas, criação de artefatos, sinais humanos, bloqueios, cancelamentos, falhas e conclusões. Mantenha payloads sensíveis fora do texto embutido dos eventos. Armazene detalhes privados atrás de referências com informações ocultadas e verificações de acesso.

Referências