Um agente sempre ativo também precisa de uma condição para parar

Em 29 de setembro, a OpenAI apresentou dots: agentes que continuam trabalhando em seus próprios computadores na nuvem. O anúncio torna concreta uma questão de projeto: se um agente pode seguir trabalhando depois do fim da conversa, o que lhe indica que a tarefa deixou de ser válida? [1]

Imagine uma equipe de conteúdo que pede a um agente para preparar materiais para um lançamento. Depois, o lançamento é adiado, o vídeo de origem muda ou a pessoa responsável sai do projeto. Cumprir as instruções antigas com zelo pode agora produzir o trabalho errado. Defendemos que uma tarefa recorrente precisa de um ciclo de vida: objetivo atual, escopo definido, responsável e condições para parar. Essas são recomendações para implantar agentes contínuos, não recursos de dots que tenhamos verificado.

A OpenAI separa a pesquisa proativa de dots das ações seguintes. Sua explicação sobre segurança diz que a pesquisa em segundo plano usa ferramentas somente de leitura; as ações posteriores continuam sujeitas às regras e verificações habituais. Esse modo específico de pesquisa não deve ser confundido com toda tarefa autorizada que continua em segundo plano. [2]

Para uma equipe, a decisão de projeto correspondente é separar perceber, preparar e publicar. Um novo arquivo de entrevista pode justificar a preparação de um rascunho de vídeo. Isso, por si só, não autoriza a publicação em uma conta da marca. A tarefa deve especificar quais materiais podem ser usados, qual é o destino, de quem é necessária a aprovação, quando couber, e quais mudanças invalidam essa aprovação. Se o usuário já autorizou uma ação recorrente e delimitada, ela deve avançar dentro desse escopo; a intenção não é voltar a pedir permissão a cada passo inofensivo.

A documentação de MCP Events da OpenAI descreve processamento assíncrono, novas tentativas e a possível chegada de eventos fora de ordem. Ela pede IDs de evento estáveis entre tentativas e ferramentas de escrita idempotentes. Portanto, confirmar o recebimento de uma entrega e concluir o trabalho solicitado são marcos distintos. Essas são regras de integração documentadas, não evidência de que testamos um plugin específico. [3]

Em um fluxo de vídeo, receber duas vezes a notificação de envio não deve gerar duas publicações. Um comentário de revisão antigo também não deve substituir uma versão posterior já aprovada. Uma solução prática é registrar juntos o item de origem, sua versão e a ação pretendida, e conferir essa identidade antes de repetir uma escrita. A pessoa que opera o fluxo deve distinguir entre recebido, em preparação, aguardando decisão, concluído e interrompido. Um rótulo genérico de «em execução» esconde justamente a diferença de que ela precisa para decidir se deve intervir.

O mesmo guia de MCP Events exige o tratamento do vencimento das assinaturas de eventos e a interrupção das entregas quando o acesso é revogado. A duração da assinatura rege a entrega; ela não determina, por si só, quando o objetivo de negócio expirou. Esse segundo limite ainda precisa ser definido. [3]

Sugerimos registrar responsável, data de revisão, escopo permitido e condições de parada para cada tarefa recorrente. O fim de uma campanha, a retirada de uma fonte ou a saída da pessoa responsável podem provocar uma revisão. Antes de uma mudança externa, verifique se a tarefa e a versão relevante da fonte ainda são atuais. Quando o agente delegar, transmita os limites aplicáveis ao trabalho delegado e teste o que acontece quando a tarefa principal para. Um pedido de parada deve produzir um resultado observável, incluindo as etapas já concluídas e as que ainda estão em andamento.

As perguntas frequentes de dots da OpenAI dizem que desconectar um plugin impede novos acessos, mas não apaga o contexto já retido. Também distinguem a exclusão de um dot da exclusão de arquivos ou conversas armazenados separadamente. Esses são fatos específicos do produto; a lição operacional mais ampla é identificar qual estado está sendo alterado. [4]

Cancelar um projeto pode significar parar trabalhos futuros, revogar uma conexão, arquivar materiais de trabalho ou remover o contexto retido. São resultados diferentes. Quem opera o sistema precisa saber quais já ocorreram e quais exigem outra ação. Não exiba «cancelado» como se isso também desfizesse uma mensagem já enviada. Da mesma forma, não presuma que remover uma integração elimine todas as cópias do material obtido antes. Defina o resultado desejado e confirme-o nos sistemas que mantêm o estado relevante.

Um primeiro teste útil é um fluxo restrito e reversível: acompanhar uma fonte aprovada e preparar um rascunho para uma pessoa revisora identificada. Depois, envie deliberadamente um evento duplicado, atualize a fonte durante a preparação, revogue o acesso, cancele a tarefa principal e esgote um orçamento de tempo ou custo escolhido. Verifique se surgem mudanças duplicadas, rascunhos obsoletos ou trabalhos delegados que continuam ativos, e se há explicações claras para a interrupção do progresso. O orçamento precisa ser imposto pelo sistema real de execução; uma frase no prompt não comprova a existência de um limite rígido.

Há uma escolha real a fazer: confirmações em excesso podem transformar o agente em mais uma caixa de entrada para administrar. O melhor é explicitar a autoridade para ações rotineiras e reservar a intervenção para mudanças de escopo, etapas de maior consequência ou condições não resolvidas. A documentação pública não demonstra com que confiabilidade cada integração lida com esses casos, e não fizemos uma avaliação em produção. A pergunta que esse lançamento torna atual é: o sistema consegue parar o trabalho que já não deve continuar com a mesma confiabilidade com que inicia trabalho útil?