Troca de turno de agente de IA: controle de sessões ativas durante a noite

Uma troca de turno de agente de IA falha quando o engenheiro que está saindo transmite uma história em vez de transferir a responsabilidade. «O agente ainda está trabalhando na implantação» quase não informa nada à próxima pessoa. Ela precisa saber qual processo ainda tem autoridade, o que ele pode alcançar, qual solicitação aguarda uma pessoa, onde estão as evidências e como interromper ou recuperar o trabalho.

A parte incômoda é que um agente pode agir enquanto ninguém acompanha o terminal. Ele pode ter uma conexão SSH ativa, uma tarefa persistente em segundo plano, um token no ambiente, um prompt de aprovação aguardando em um laptop ou uma alteração remota parcial que só ficará visível mais tarde. Uma boa troca transforma tudo isso em um estado operacional delimitado. Uma troca ruim transfere a incerteza e a chama de continuidade.

Uma troca precisa de um registro de responsabilidade, não de um resumo no chat

Uma troca utilizável registra autoridade e estado separadamente, porque os dois falham de maneiras diferentes. O estado informa o que o agente fez e planeja fazer. A autoridade informa o que ele ainda pode fazer. As equipes costumam documentar o primeiro e omitir o segundo. É assim que uma continuação aparentemente inofensiva se transforma em uma gravação não revisada em produção.

Escreva o registro enquanto o engenheiro que está saindo ainda pode inspecionar a máquina e explicar as decisões. Não o reconstrua de memória depois que um alerta acordar alguém. Um documento curto, com identificadores exatos, vale mais que uma narrativa longa cheia de certezas.

Para cada execução ativa, registre estes fatos:

• O ID do processo do agente, o ID da sessão, o diretório de trabalho e o horário de início.
• O responsável humano que está encerrando o turno, o responsável que está assumindo e o horário da mudança.
• A tarefa pretendida, a última ação externa concluída e a próxima ação externa proposta.
• Todos os destinos alcançáveis, como alias de host, URL base de API, repositório, chamado ou ambiente de implantação.
• O comando de parada, o comando de recuperação e o local das evidências.

Não escreva «tem acesso ao staging» quando puder escrever «o processo 4182 pode chamar a API de implantação de staging pela sessão aprovada S-204». Rótulos amplos escondem o detalhe que determina se o sucessor pode continuar com segurança.

O registro de responsabilidade também precisa definir claramente o destino de cada execução: continuar, pausar, cancelar ou inspecionar antes de agir. «Monitorar» não é um destino. Essa palavra deixa o próximo engenheiro tentando deduzir se tem permissão para intervir.

A troca só termina quando o engenheiro que está entrando confirma o registro e consegue localizar o processo ativo por conta própria. Uma mensagem enviada a um canal movimentado é entrega, não transferência. Se ninguém aceitar a responsabilidade, o engenheiro que está saindo deve pausar o trabalho ou revogar a autoridade externa sempre que isso for possível.

Encontre a autoridade ativa antes de mudar o responsável

Não é possível transferir o controle de uma sessão que você não localizou. Comece pela árvore de processos local e depois inspecione conexões, exposição do ambiente e trabalhos criados fora do terminal imediato. A interface do agente pode dizer que uma tarefa terminou enquanto um processo filho, uma janela do multiplexador de shell ou uma conexão mestre SSH continua ativa.

No macOS ou Linux, comece com comandos simples e salve a saída nas evidências da troca. Substitua os identificadores de exemplo pelo processo ou pela conta reais do agente.

ps -axo pid,ppid,user,lstart,command | grep -E '[a]gent|[c]laude|[m]cp'
pgrep -P 4182 -alf
lsof -nP -p 4182

O primeiro comando produz uma linha de processo com este formato:

4182  901 alex  Tue Mar 18 22:14:07 2025  agent-runner --task deploy-api

O segundo mostra os processos filhos. O terceiro exibe arquivos abertos e endpoints de rede. Procure shells herdados, sockets Unix abertos, conexões TCP, arquivos locais de credenciais e pipes para auxiliares de aprovação. Não cole em um chamado uma saída de comando que contenha segredos. Preserve-a no registro de incidente aprovado ou oculte o valor sensível, mantendo o caminho do arquivo e os detalhes da conexão.

O SSH precisa de uma inspeção separada, porque seu modelo de conexão pode sobreviver a um único comando. O manual ssh_config do OpenSSH informa que ControlPersist pode manter uma conexão mestre aberta depois que o cliente inicial termina. Esse comportamento economiza tempo em comandos repetidos. Durante uma troca, também significa que «o comando terminou» não prova que o acesso remoto acabou.

Verifique sockets mestre e processos de encaminhamento:

ps -axo pid,ppid,command | grep '[s]sh'
find ~/.ssh -type s -name '*control*' -print
lsof -nP -iTCP -sTCP:ESTABLISHED | grep '[s]sh'

Depois faça uma pergunta mais importante que «está conectado?»: o que o lado remoto ainda executa? Uma compilação remota pode continuar depois que o cliente local desaparece. Um comando de implantação pode ter aplicado uma alteração e falhado antes de informar a próxima. Capture o identificador do trabalho remoto, o registro da implantação ou o estado do serviço antes de decidir se deve retomar.

Não confunda uma porta aberta com atividade maliciosa. Trate todo canal aberto sem explicação como autoridade não resolvida. O engenheiro que está entrando precisa entendê-lo, fechá-lo ou escalá-lo.

Aprovações pendentes precisam de um destino e de uma expiração

Uma aprovação pendente é uma ação proposta, não uma reserva feita pelo engenheiro que está saindo. Quem assume o turno nunca deve herdar um prompt de aprovação acompanhado apenas de uma mensagem como «clique aqui se aparecer». Essa frase pede que a pessoa aprove uma decisão sem o contexto necessário.

Associe cinco informações a cada solicitação pendente:

1. A ação exata, incluindo método e destino. «Atualizar serviço» é insuficiente. «Fazer POST no endpoint de implantação de production-api» dá um ponto de partida.
2. O motivo da ação e a condição que a tornou necessária.
3. O resultado esperado e a evidência observável que o confirma.
4. O prazo depois do qual a solicitação deve expirar e ser criada novamente.
5. A pessoa nomeada que pode aprová-la ou rejeitá-la.

Uma aprovação sem essas informações deve expirar. Emitir uma nova solicitação custa menos que recuperar uma gravação feita às cegas. Essa regra parece exagerada durante um turno tranquilo. Ela se torna óbvia depois que um cartão de aprovação sobrevive ao bloqueio do laptop, a uma reconexão e a uma mudança no escopo do incidente.

Não use uma troca de turno para ampliar a autoridade de aprovação. Se o engenheiro que está saindo podia aprovar uma alteração em staging, isso não autoriza o engenheiro que está entrando a aprovar a versão correspondente em produção. O escopo pode ter mudado enquanto a solicitação aguardava. Revise o destino, o payload e o estado atual do incidente antes de uma pessoa agir.

Também existe uma questão de tempo. Se uma ferramenta pode solicitar uma ação muito depois de o agente ter criado a solicitação, inclua a expiração no desenho do pedido. Uma aprovação antiga pode agir sobre um sistema que se recuperou, sofreu failover ou foi alterado manualmente. O prompt pode descrever uma operação tecnicamente válida que já não é a decisão operacional correta.

Prefiro uma nota de aprovação curta a um transcript enorme. O próximo engenheiro deve conseguir responder em menos de um minuto a três perguntas: o que vai acontecer, onde vai acontecer e por que ainda precisa acontecer agora? Se não conseguir, rejeite a solicitação e peça ao agente que inspecione o estado atual antes de propor uma nova ação.

A responsabilidade pela sessão e pelos segredos deve permanecer separada

A pessoa que supervisiona uma sessão não precisa receber uma cópia de todas as credenciais que a sessão pode usar. Confundir esses papéis cria uma confusão conhecida e cara: alguém exporta um token para o perfil do shell «só para a troca», e o token sobrevive ao incidente, à função do engenheiro e à lembrança do motivo pelo qual existia.

Uma transferência adequada muda quem pode supervisionar, aprovar, pausar ou revogar uma ação. Ela não envia tokens de API, chaves privadas SSH, cookies de navegador ou credenciais temporárias de nuvem por chat, anotações ou prompt de agente. O sucessor recebe a referência da sessão e as evidências necessárias para operá-la. O executor da ação mantém o segredo.

Essa distinção é mais importante quando o engenheiro que está saindo deixa um terminal aberto. Um shell desbloqueado não é um mecanismo legítimo de transferência. Ele entrega à próxima pessoa um conjunto de estados herdados: variáveis exportadas, histórico de comandos, credenciais em cache, funções de shell, encaminhamentos de porta e comandos inacabados. Parte disso pode ser útil. Nada disso define claramente a responsabilidade.

Use uma destas abordagens:

• Continue a sessão existente apenas quando a operação ativa for compreendida, o escopo estiver delimitado, o engenheiro que está entrando tiver aceitado a sessão e interromper o trabalho criar um resultado operacional pior.
• Pare a sessão antiga e inicie uma nova sob responsabilidade do engenheiro que está entrando quando a tarefa for investigativa, a autoridade for ampla, o histórico do prompt for importante ou o agente estiver ocioso.

A segunda abordagem costuma ser mais segura do que as equipes admitem. As pessoas resistem porque temem perder contexto. Preserve o contexto no pacote de troca, não dentro de um processo que não foi inspecionado. Um processo novo tem um limite de aprovação limpo e deixa evidente a responsabilidade do novo dono.

Para equipes que usam o Sallyport, o agente pode executar ações HTTP e SSH sem receber os segredos subjacentes. Assim, uma mudança de turno transfere a supervisão, não o material de credenciais. O bloqueio do cofre impede ações enquanto ele está bloqueado, criando uma pausa deliberada antes que o engenheiro que está entrando autorize qualquer continuidade.

Não confunda separação com imunidade. Se o sucessor pode aprovar ações em uma sessão, ainda precisa aplicar a mesma disciplina ao escopo e às evidências. Manter um segredo fora do prompt evita uma classe de falhas. Isso não torna segura uma solicitação insegura.

A recuperação deve começar pela contenção, não pela continuidade

Quando uma execução do agente fica silenciosa ou o engenheiro que está saindo se torna inacessível, o engenheiro que está entrando deve primeiro impedir novas alterações externas. Não deve passar dez minutos tentando restaurar o contexto exato da conversa enquanto um processo em segundo plano continua gravando.

A recuperação tem dois caminhos: preservar evidências e estabelecer o estado atual. Execute-os nessa ordem sempre que houver alguma chance de o processo ou o host desaparecer. Copie identificadores de sessão, saída do terminal, definições de tarefas, aprovações, listas de processos e referências de auditoria para o registro do incidente. Depois pare, revogue ou bloqueie o caminho de ação de acordo com os controles normais do sistema.

Depois da contenção, inspecione o sistema de destino. A afirmação do agente de que uma chamada falhou é menos confiável que um registro no destino. Um timeout HTTP pode significar que o servidor rejeitou uma solicitação, aceitou uma vez ou aceitou e perdeu a resposta. Repetir a chamada sem um mecanismo de idempotência pode duplicar a ação.

Use as evidências naturais do destino:

• Para uma gravação em uma API, inspecione o objeto, o registro de alteração, o ID da solicitação ou o registro de idempotência.
• Para trabalho via SSH, inspecione o processo remoto, o estado do serviço, o histórico do gerenciador de pacotes ou o marcador de implantação.
• Para uma alteração de código, inspecione separadamente o diff do repositório, o commit, a execução de CI e o estado da implantação.
• Para uma operação enfileirada, inspecione a fila e o estado do worker antes de enviar outro trabalho.

A diferença entre repetir uma solicitação e recuperar uma operação importa. Repetir refaz uma tentativa de transporte. Recuperar estabelece se o estado subjacente mudou e então escolhe a próxima ação. As equipes confundem os termos quando um agente apresenta um timeout como convite para clicar em «executar novamente». Não é isso.

Uma anotação de recuperação deve nomear a última observação confiável, não a última coisa que o agente disse. Por exemplo: «O agente atingiu o tempo limite depois de solicitar a implantação D42. O serviço de implantação registra D42 como em execução em duas instâncias. Novos envios foram pausados às 02:17.» Isso dá ao próximo operador um ponto factual para retomar.

Se não conseguir estabelecer o estado, abra o incidente e mantenha a autoridade restrita. Uma implantação parada costuma ser tolerável. Uma migração de esquema duplicada, uma cobrança repetida ou uma exclusão acidental em produção talvez não sejam.

Confirme o registro com as evidências antes de aceitá-lo

Um documento de troca é a interpretação de um operador. Um registro de auditoria é a evidência do que o sistema registrou. Você precisa dos dois, mas não deve tratá-los como equivalentes.

Antes de aceitar uma sessão ativa, o engenheiro que está entrando deve comparar o registro de responsabilidade com evidências que o engenheiro que está saindo não tenha editado manualmente. Verifique os horários de início e fim da sessão, os nomes dos destinos, a sequência de ações e a disposição de aprovação informada. Investigue as divergências antes que alguém continue a execução.

Uma cadeia de hashes ajuda porque torna detectáveis a remoção e a reordenação de registros. Ela não prova intenção, correção ou a sensatez de uma aprovação. É saudável declarar esse limite com clareza. A continuidade criptográfica responde «essa sequência registrada permaneceu intacta?». Ela não responde «deveríamos ter enviado essa solicitação?».

Com o Sallyport, as equipes podem verificar offline a cadeia de auditoria criptografada com este comando:

sp audit verify

Salve o resultado do verificador ao lado do registro de troca, junto do horário em que a verificação foi executada e do intervalo de logs revisado. A verificação não precisa de acesso ao cofre, o que é útil quando o engenheiro que está entrando precisa conferir a continuidade antes de desbloquear qualquer autoridade de ação.

Não transforme em hábito copiar grandes trechos de auditoria para o chat. Os logs podem conter metadados operacionais sensíveis mesmo quando não incluem segredos. Armazene uma referência ao registro aprovado, cite apenas o pequeno trecho necessário para explicar a troca e dê ao engenheiro acesso pelo caminho normal do incidente.

A revisão de auditoria também identifica um problema banal, mas sério: um engenheiro pode ter iniciado dois agentes com tarefas parecidas e esquecido um deles. A lista de processos mostra o que existe agora. A sequência de auditoria mostra o que cada execução já tentou fazer. Leia as duas antes de aceitar a responsabilidade.

Um pacote de troca deve funcionar quando ninguém se lembra do incidente

Um pacote útil permite que um engenheiro que estava dormindo cinco minutos antes tome uma decisão segura. Ele não deve exigir a rolagem por centenas de mensagens de chat ou a reabertura de um transcript de prompt sem limites. Mantenha o pacote perto do registro do incidente, use sempre a mesma ordem de campos e atualize-o quando a autoridade mudar.

Use este modelo como ponto de partida:

Incidente ou alteração:
Responsável que sai / responsável que entra / horário da transferência:

Execução do agente:
- ID da sessão e PID local:
- Espaço de trabalho e referência da tarefa:
- Estado atual: continuar | pausar | cancelar | inspecionar
- Última ação externa confirmada:
- Próxima ação proposta:

Autoridade:
- Destinos alcançáveis por esta execução:
- Estado e expiração da aprovação:
- Método para revogar ou parar a sessão:
- Credenciais continuam sob responsabilidade de:

Evidências:
- Referência ao registro de atividade ou auditoria:
- Evidência verificada no destino:
- Captura de processos e conexões:

Recuperação:
- Estado parcial conhecido:
- Primeira ação segura para o responsável que entra:
- Responsável pelo escalonamento e gatilho:

A linha «primeira ação segura» merece seu espaço. Escreva uma ação que reúna informações sem aumentar o impacto, como verificar um registro de implantação, ler a profundidade de uma fila ou comparar a versão de um serviço. Não escreva «continuar a investigação». Essa frase não define nenhum limite operacional.

O pacote também deve dizer o que mudou desde o início do agente. Talvez tenha começado um congelamento de releases, uma réplica do banco tenha ficado atrasada, um cliente tenha relatado um sintoma ou outro engenheiro tenha feito uma correção manual. Os agentes agem com base no contexto que recebem. A pessoa que entra precisa conhecer o contexto que surgiu depois do início do prompt.

Mantenha a linguagem factual. «O agente parece confuso» diz ao sucessor para desconfiar, mas não oferece nada para verificar. «O agente propôs o mesmo POST depois que o serviço mostrou o ID de solicitação 7f3 como aceito» identifica um risco de duplicação e sugere a verificação correta.

Trocas de turno criam uma lacuna de autorização quando o tempo é ignorado

A lacuna aparece quando o engenheiro que está saindo já deixou mentalmente o turno, mas a sessão ainda pode agir. Ela aumenta quando o engenheiro que está entrando ainda não aceitou a responsabilidade, não consegue ver o estado da aprovação ou presume que o agente está apenas lendo dados. Durante esse intervalo, o processo tem autoridade sem uma pessoa atenta responsável pelo uso dela.

Uma falha comum acontece assim. No fim do turno, um engenheiro pede a um agente que corrija uma implantação com problemas. O agente abre uma conexão SSH, edita um arquivo de configuração e aguarda aprovação para reiniciar um serviço. O engenheiro escreve «reinicialização pendente, deve estar tudo bem» no chat e encerra o turno.

O próximo engenheiro vê o prompt uma hora depois. Nesse intervalo, uma mitigação manual mudou a topologia do serviço. A reinicialização pendente agora afeta um nó que recebe tráfego, algo que o engenheiro anterior desconhecia. A aprovação ainda descreve um comando válido, mas a situação que o justificava mudou.

Essa falha não exige uma ferramenta comprometida ou uma pessoa descuidada. Ela surge quando a autorização é tratada como permanente enquanto o contexto operacional muda. Uma aprovação deve estar vinculada a uma solicitação de curta duração e a um responsável atual. A sessão deve perder autoridade quando nenhuma dessas condições existir.

Defina um prazo explícito para a transferência. Se o engenheiro que está entrando não aceitar a sessão até esse horário, pause o agente e invalide as aprovações pendentes. Se uma tarefa não puder ser pausada com segurança, registre esse fato no runbook antes do incidente, defina quem pode aceitá-la e estabeleça uma rota direta de escalonamento. Não descubra a exceção durante a troca de turno.

Às vezes as equipes mantêm todas as sessões ativas porque reiniciar agentes custa tempo. Essa recomendação é popular porque preserva o contexto local e evita explicar a tarefa novamente. Ela está errada para autoridades amplas ou incertas. Os poucos minutos gastos para iniciar uma sessão limpa custam pouco em comparação com tentar explicar por que um processo abandonado alterou um sistema depois que seu responsável ficou offline.

O engenheiro que entra deve aceitar a responsabilidade em uma ordem fixa

O engenheiro que está entrando precisa de uma sequência repetível de aceitação, porque as trocas acontecem quando a atenção está fragmentada. Isso não é burocracia para um dia tranquilo. Evita que a pessoa acordada por um alerta aprove uma ação antes de saber qual autoridade ainda está ativa.

Use esta ordem:

1. Leia o estado atual do incidente e o registro de responsabilidade, depois confirme o engenheiro que está saindo e o horário da transferência.
2. Localize o processo ou a sessão indicados e inspecione conexões ativas, processos filhos e solicitações pendentes.
3. Compare o registro com as evidências de auditoria e o estado no destino.
4. Escolha continuar, pausar ou cancelar. Rejeite toda aprovação pendente que já não tenha uma justificativa clara e atual.
5. Registre a aceitação, a primeira ação segura e o próximo horário de revisão.

A ordem importa. Se você aprovar primeiro e inspecionar depois, já terá aceitado o maior risco. Se inspecionar o destino antes de preservar o registro da sessão, poderá perder evidências quando um processo terminar ou uma máquina reiniciar. Uma sequência fixa protege contra o impulso natural de «fazer a coisa andar».

O engenheiro que está saindo também tem uma obrigação fixa: permanecer disponível até que o sucessor aceite a responsabilidade ou a sessão pare. Se a cobertura terminar antes disso, faça o escalonamento em vez de deixar silenciosamente um agente em execução. Uma escala de plantão atribui uma pessoa, não uma esperança vaga de que alguém verá um prompt.

Inclua essas regras na prática de incidentes antes que uma falha noturna obrigue a equipe a lidar com o problema. Comece adicionando os campos de responsabilidade a uma anotação de troca já existente e exigindo um destino para cada execução de agente. Na primeira vez que encontrar uma conexão SSH sem explicação ou uma aprovação sem responsável, você terá encontrado uma lacuna real, não teórica.