Definição de um contrato de execução para agentes que continuam após o logout

Objetivo

Situação em 25 de outubro de 2026. Definir o que um agente pode fazer depois que seu operador se desconecta, quanto pode consumir e como sua autoridade termina. Confira novamente o comportamento de reinicialização do supervisor implantado, o ciclo de vida das credenciais e o suporte a cancelamento remoto. Este contrato proposto complementa a configuração da conta de serviço com controles sobre toda uma execução sem supervisão.

Pré-requisitos

Defina um responsável, um repositório persistente de tarefas e um supervisor que consiga interromper o trabalho independentemente do modelo. Faça um inventário dos processos locais, dos subagentes delegados e dos jobs remotos. Ao contrário de uma sessão interativa, este fluxo precisa de uma resposta definida para quando não for possível obter esclarecimentos: persistir um estado de bloqueio e notificar a pessoa responsável por um canal aprovado.

Passos

1. Registre o contrato de execução. Armazene a revisão do objetivo, os recursos e as ações permitidos, o local de saída, a validade, o orçamento e o caminho de escalonamento. Dê ao serviço uma identidade própria restrita e registre separadamente o usuário que iniciou a execução. Não use uma cópia do repositório de credenciais de uma sessão interativa como configuração de identidade do serviço.
2. Conceda apenas o acesso necessário. Use os recursos de identidade de cargas de trabalho da plataforma. A documentação de contas de serviço do Kubernetes descreve identidades distintas para cargas de trabalho e automountServiceAccountToken: false para Pods que não devem receber credenciais de API montadas automaticamente. Aplique permissões restritas no recurso acessado. A renovação de credenciais não pode ampliar silenciosamente a janela de autorização da tarefa.
3. Defina o orçamento da tarefa inteira. Persista o consumo acumulado de subagentes, novas tentativas e reinicializações de processos. Defina limites para tempo decorrido, chamadas de modelo e ferramentas, concorrência, armazenamento e serviços cobrados. Reserve capacidade antes de despachar trabalho quando processos concorrentes puderem ultrapassar um limite compartilhado. Documente quais limites o supervisor ou gateway realmente aplica; uma frase no prompt é apenas uma solicitação.
4. Crie um caminho de parada independente. Quando a autorização vencer ou o operador solicitar a parada, bloqueie novos despachos, desabilite a reinicialização automática daquela execução e solicite o cancelamento do trabalho acompanhado. Onde houver suporte, imponha o vencimento da autorização no gateway de gravação. Concilie as operações já aceitas remotamente antes de informar que a parada foi concluída. Mantenha os efeitos não resolvidos visíveis e impeça a repetição sem verificação após uma reinicialização.
5. Mapeie os controles da plataforma com precisão. Os Jobs do Kubernetes oferecem suporte a activeDeadlineSeconds e suspensão. Suspender um Job encerra seus Pods ativos; retomá-lo reinicia o temporizador de prazo ativo. Portanto, mantenha um prazo absoluto de validade da autorização fora desse temporizador. Trate a suspensão como um controle do ciclo de vida do processo, com checkpoints persistentes da aplicação necessários à recuperação, e verifique separadamente os resultados remotos.
6. Torne o estado da execução sem supervisão consultável. Registre os identificadores da tarefa e da tentativa, a revisão do objetivo, a referência da identidade, o uso do orçamento, o resultado da ferramenta e o motivo da parada, sem segredos. A propagação de contexto do OpenTelemetry fornece correlação de rastreamentos entre serviços. Exporte os logs necessários antes da limpeza da carga de trabalho. Para um Job do Kubernetes, kubectl get job JOB -o yaml mostra seu estado registrado; kubectl logs jobs/JOB é um ponto de partida para inspecionar a saída, e não um histórico completo de todas as tentativas.

Resultado esperado

Um operador desconectado consegue determinar quem autorizou uma execução, o que permanece ativo e se ainda há autorização para gravar. A reinicialização do processo de trabalho preserva o orçamento restante e a validade original. Conclusão, espera por entrada, parada em andamento e resultados remotos não resolvidos continuam distinguíveis.

Limites e base de verificação

Este é um procedimento proposto, e não uma implantação testada. Em um ambiente isolado, teste a desconexão do operador, o esgotamento da cota, a reinicialização e o vencimento da autorização enquanto uma operação remota simulada estiver pendente. Verifique se nenhuma nova ação é admitida após o limite e se os efeitos pendentes permanecem registrados. O encerramento de um processo não comprova que uma ação remota foi desfeita.