Como intervir numa tarefa de agente de IA em andamento

A tarefa continua certa depois que o contexto muda?

Um agente inicia a preparação de uma análise para a diretoria. Ele reúne documentos, consulta indicadores e organiza recomendações. Vinte minutos depois, a liderança informa que uma premissa mudou: a unidade Sul saiu do escopo e o período deve terminar em setembro.

Cancelar tudo e recomeçar pode desperdiçar trabalho válido. Inserir a nova instrução diretamente no contexto pode ser pior. Parte da análise talvez já tenha produzido arquivos, criado registros ou consultado fontes com o escopo anterior.

A intervenção durante uma tarefa longa precisa entrar como uma mudança governada. O sistema registra a instrução, identifica quais partes ela afeta, chega a um ponto seguro, preserva efeitos confirmados e revalida o plano antes de continuar.

A OpenAI passou a destacar steering em trabalhos longos como uma forma de orientar agentes em marcos, sem acompanhar cada linha. Para uma empresa, a pergunta importante está na implementação: como aceitar uma correção humana sem misturar versões, repetir efeitos ou esconder o que mudou?

Este guia trata dessa fronteira. O artigo sobre cancelamento de tarefas de agentes encerra uma unidade. A aprovação assíncrona pausa diante de uma ação previamente definida. Aqui, a pessoa altera o objetivo, o escopo ou o critério de uma execução que ainda está aberta.

Quando uma intervenção é útil

A intervenção pode corrigir o trabalho sem exigir outro ciclo completo quando:

uma fonte oficial recebeu versão nova;
o escopo perdeu ou ganhou uma unidade delimitada;
uma premissa foi corrigida;
a prioridade entre entregáveis mudou;
surgiu uma restrição de prazo;
uma etapa opcional deixou de ter valor;
a pessoa pediu aprofundamento num ponto específico;
uma evidência tornou parte do plano inválida;
o agente precisa suspender ações e continuar apenas em leitura;
a entrega deve mudar de formato sem mudar seu conteúdo aceito.

Ela não deve servir como atalho para ampliar permissão, ignorar aprovação, trocar silenciosamente a fonte oficial ou alterar uma consequência já confirmada.

Uma frase como “inclua também todos os clientes” pode mudar acesso, custo, prazo e finalidade. O sistema precisa tratá-la como proposta de mudança até verificar esses limites.

Separe quatro operações

Intervir, aprovar, cancelar e iniciar outra tarefa são decisões diferentes.

Intervenção

Altera uma execução ainda válida. O sistema preserva a identidade da tarefa e cria uma nova versão do plano ou do escopo.

Aprovação

Autoriza ou rejeita uma ação delimitada, com argumentos e consequência conhecidos. Aprovar o envio de um relatório não autoriza mudar seus destinatários.

Cancelamento

Encerra trabalho futuro daquela unidade. Pode exigir limpeza, reconciliação e comunicação de resultado parcial.

Nova tarefa

Cria outra unidade quando a mudança altera finalidade, dono, dados, prazo ou resultado de forma material. Forçar uma mudança grande dentro da execução antiga destrói a legibilidade do histórico.

Defina critérios para escolher entre essas rotas. A decisão não deve depender somente da interpretação livre do modelo.

Registre a intervenção como um objeto próprio

Uma mensagem solta no chat informa intenção, mas não cria uma mudança operacional verificável.

Use um registro como:

intervention_id: int-20261002-018
run_id: analise-diretoria-2026-q3
submitted_at: 2026-10-02T18:42:11Z
submitted_by: user-184
base_plan_version: 7
requested_change:
  remove_scope: unidade-sul
  period_end: 2026-09-30
reason: fechamento revisado pela diretoria
priority: antes_da_sintese
requested_mode: aplicar_e_continuar

Acrescente:

identidade e papel de quem pediu;
canal autenticado;
versão do plano observada pela pessoa;
fonte da nova informação;
partes que podem ser afetadas;
ações que continuam proibidas;
prazo da instrução;
estado de aceite;
decisão do sistema;
evidência da aplicação.

A instrução pode chegar enquanto outra mudança já está sendo aplicada. A versão de base permite detectar que a pessoa decidiu sobre uma visão antiga.

Valide autoridade antes do conteúdo

O fato de a instrução parecer razoável não prova que a pessoa possui autoridade para emiti-la.

Antes de aceitar, verifique:

identidade do solicitante;
papel naquele processo;
unidade, cliente ou projeto alcançado;
tipo de mudança permitido;
dados adicionais que a mudança exigirá;
ações externas que poderão ser afetadas;
aprovações anteriores que perderiam validade;
segregação de funções aplicável.

Uma pessoa pode alterar o formato do relatório e não o período contábil. Outra pode retirar um destinatário e não acrescentar acesso a uma unidade. Modele alçadas por tipo de mudança, sem usar “pode intervir” como permissão genérica.

A identidade e credenciais de agentes ajuda a separar a conta técnica da autoridade empresarial. A intervenção precisa carregar as duas provas.

Aplique mudanças em pontos seguros

Uma tarefa longa atravessa momentos com riscos diferentes. Alguns permitem correção imediata. Outros precisam terminar, pausar ou reconciliar antes da mudança.

Exemplo de execução:

coletar_fontes
normalizar_dados
calcular_indicadores
preparar_sintese
solicitar_aprovacao
publicar_resultado

Retirar uma unidade durante coletar_fontes pode cancelar consultas ainda não iniciadas. Durante calcular_indicadores, o sistema talvez precise abandonar o cálculo parcial e refazer a etapa com o novo conjunto. Depois de publicar_resultado, a mudança não corrige retroativamente o efeito: ela exige nova versão e tratamento explícito do material anterior.

Para cada etapa, declare:

se aceita intervenção imediata;
se precisa concluir a operação atômica atual;
qual checkpoint é válido;
quais saídas parciais perdem validade;
quais efeitos já foram confirmados;
como interromper chamadas em andamento;
quando a nova versão passa a valer.

O ponto seguro pertence ao workflow e às ferramentas. Um prompt pedindo cautela não consegue interromper uma escrita que já chegou ao sistema de destino.

Classifique o impacto antes de continuar

Compare a mudança solicitada com o plano corrente.

Impacto local

Muda formato, ordem ou profundidade de uma saída ainda não comprometida. Reprocessa uma etapa estreita.

Impacto retroativo

Invalida uma entrada ou resultado usado por etapas concluídas. Exige voltar a um checkpoint anterior e descartar derivados.

Impacto de autoridade

Amplia dados, ferramentas, destinatários, autonomia ou consequência. Exige nova validação ou aprovação.

Impacto de finalidade

Altera o resultado empresarial esperado. Geralmente merece outra tarefa, com identidade e critérios próprios.

Impacto irreversível

Tenta modificar um efeito já executado, como mensagem enviada, registro aprovado ou pagamento confirmado. A rota adequada pode ser compensação, correção ou nova comunicação. Reescrever o histórico local não desfaz o mundo externo.

Essa classificação pode usar regras determinísticas para campos conhecidos. O modelo ajuda a explicar relações e localizar derivados, mas não deve conceder a própria ampliação de poder.

Preserve uma árvore de derivados

Para aplicar uma correção, o sistema precisa saber o que nasceu de cada fonte e decisão.

Considere:

fonte F17 -> tabela T8 -> indicador I4 -> parágrafo P12 -> slide S6

Se F17 muda, T8 precisa ser recalculada. I4, P12 e S6 ficam suspeitos até nova validação. Sem essa proveniência, o agente tende a corrigir a frase visível e manter cálculos ou recomendações criados com a premissa antiga.

Registre pelo menos:

identificador e versão da fonte;
etapa que consumiu a fonte;
artefato produzido;
regra ou transformação aplicada;
decisões que usaram o artefato;
efeito externo relacionado;
estado depois da intervenção.

A página sobre linhagem de dados para agentes aprofunda a trajetória entre fonte, transformação e resultado. Durante uma intervenção, essa trajetória define o raio de reprocessamento.

Use versões explícitas do plano

Uma execução pode começar com plan_version = 7. A intervenção aceita cria a versão 8.

A versão nova deve mostrar:

base_version: 7
new_version: 8
change_set:
  - unidade-sul removida
  - period_end alterado para 2026-09-30
invalidated_outputs:
  - tabela-por-unidade-v3
  - sintese-executiva-draft-2
preserved_outputs:
  - inventario-fontes-v5
required_revalidation:
  - indicadores consolidados
  - destinatarios da entrega

Workers e ferramentas recebem a versão aplicável. Resultado produzido com versão anterior não entra silenciosamente na consolidação nova.

Quando duas intervenções chegam próximas, use controle de concorrência. Uma mudança baseada na versão 7 não deve sobrescrever outra já aceita na versão 8. O sistema devolve conflito e pede revisão sobre o estado atual.

Escolha entre continuar, voltar, pausar ou abrir outra tarefa

A decisão de aplicação pode usar quatro rotas.

Continuar do ponto atual

Adequado quando a mudança afeta somente trabalho futuro e nenhum resultado anterior precisa ser revisto.

Voltar a um checkpoint

Use quando uma etapa concluída depende da premissa alterada. Marque derivados como inválidos e retome do último estado comprovadamente compatível.

Pausar para decisão

Necessário quando o impacto alcança permissão, finalidade, contrato, dado sensível ou efeito incerto. Preserve estado e apresente as alternativas a uma pessoa autorizada.

Encerrar e criar nova unidade

Escolha quando o objetivo mudou de forma material ou quando misturar versões prejudicaria auditoria, cobrança, SLA ou responsabilidade.

Registre o motivo da rota. “O agente decidiu reiniciar” ajuda pouco. “A mudança retirou uma unidade usada em três cálculos e numa aprovação pendente; retomada no checkpoint anterior à agregação” permite operar e revisar.

Não confunda correção com edição do histórico

O histórico deve preservar:

instrução original;
plano anterior;
trabalho já concluído;
intervenção recebida;
validações feitas;
decisão de aplicação;
versão nova;
partes invalidadas;
ações compensatórias;
resultado final.

Mostrar apenas a versão mais recente apaga a explicação de por que o agente consultou uma fonte, abandonou um cálculo ou repetiu uma etapa.

A interface pode destacar o estado corrente, mas o registro de auditoria precisa manter a sequência. A pessoa que revisa o resultado deve conseguir separar o que foi produzido antes e depois da mudança.

Trate ferramentas em andamento de forma individual

Ao receber uma intervenção, liste as chamadas ativas.

Para cada uma, verifique:

pode ser cancelada?
o cancelamento é confirmado?
produz somente leitura?
pode ter concluído apesar da resposta ausente?
possui chave idempotente?
aceita versão ou condição na escrita?
o resultado ainda terá validade?
exige reconciliação?

Uma consulta de leitura pode terminar e ter a saída descartada. Uma criação de tarefa no CRM precisa ser consultada antes de repetição ou compensação. Um envio externo talvez não possa ser recolhido.

O kill switch para agentes contém autonomia diante de risco. A intervenção é mais estreita: altera uma unidade com intenção de continuar, mantendo os mesmos controles sobre ferramentas e efeitos.

Exemplo: análise trimestral em andamento

A tarefa analise-diretoria-2026-q3 usa quatro unidades e fecha o trimestre em 30 de setembro.

O agente concluiu a coleta, normalizou os dados e iniciou a síntese. A pessoa responsável envia duas correções:

1. Remover a unidade Sul porque seus números ainda estão em revisão.
2. Manter o período encerrado em 30/09. Não usar a parcial de outubro.

O sistema:

autentica a solicitante e confirma alçada sobre o relatório;
registra a intervenção sobre plan_version = 7;
impede que a síntese atual chegue à aprovação;
termina a operação local de gravação do rascunho;
marca indicadores consolidados e trechos derivados como inválidos;
preserva fontes das outras unidades;
volta ao checkpoint anterior à consolidação;
cria plan_version = 8;
recalcula os indicadores com três unidades;
registra a exclusão da Sul como limite de cobertura;
exige nova revisão antes de publicar.

O relatório final informa que a unidade Sul ficou fora por decisão registrada. A versão anterior permanece no histórico e não aparece como resultado vigente.

Estados que deixam a intervenção legível

Um modelo de estados pode usar:

recebida
validando_autoridade
avaliando_impacto
aguardando_ponto_seguro
aceita
rejeitada
conflito_de_versao
aplicando
revalidando
aplicada
aplicacao_parcial
exige_nova_tarefa
exige_reconciliacao

Cada transição registra horário, ator, versão, motivo e evidência. Estados finais precisam indicar se a execução continuará, ficará pausada ou encerrará.

Teste mudanças durante o trabalho real

Inclua cenários como:

correção antes da primeira ferramenta;
mudança durante uma consulta longa;
retirada de escopo depois de um cálculo;
ampliação de dados sem permissão;
alteração de destinatário depois da aprovação;
instrução baseada numa versão antiga;
duas intervenções conflitantes;
cancelamento de ferramenta sem confirmação;
efeito externo concluído com resposta perdida;
worker antigo entregando resultado da versão anterior;
retomada depois de reinício do processo;
mudança que exige nova tarefa;
intervenção expirada antes da aplicação;
solicitante que perde o papel durante a pausa;
reprocessamento que ultrapassa o prazo final.

Confirme versão final, efeitos externos, itens descartados, fontes preservadas, aprovações invalidadas e linguagem exibida à pessoa.

Métricas para operar intervenções

Acompanhe:

intervenções por tipo de tarefa;
tempo entre recebimento e ponto seguro;
mudanças aceitas, rejeitadas e conflitantes;
etapas reprocessadas;
saídas invalidadas;
efeitos que exigiram reconciliação;
execuções convertidas em nova tarefa;
intervenções por problema de briefing;
intervenções por mudança real do ambiente;
falhas causadas por resultado de versão antiga;
custo e prazo adicionais por mudança;
qualidade final depois da revalidação.

Muitas intervenções podem indicar um briefing fraco, fontes voláteis ou ausência de marcos de revisão. Poucas intervenções também não provam bom desenho: a interface pode simplesmente impedir supervisão útil.

Checklist de implementação

[ ] Cada execução possui identidade e versão do plano?
[ ] A intervenção registra pessoa, papel, versão e motivo?
[ ] Autoridade é verificada por tipo de mudança?
[ ] O workflow declara pontos seguros?
[ ] Chamadas ativas podem ser listadas e tratadas?
[ ] Derivados mantêm vínculo com fonte e versão?
[ ] Resultados antigos são invalidados de forma explícita?
[ ] Workers recusam saída de versão superada?
[ ] Efeitos confirmados não são apagados do histórico?
[ ] Mudanças de permissão voltam para aprovação?
[ ] Conflitos entre intervenções são detectados?
[ ] Existe critério para criar outra tarefa?
[ ] A retomada usa checkpoint compatível?
[ ] O resultado final mostra limites e mudanças materiais?
[ ] Testes cobrem ferramenta em andamento e resposta incerta?

Supervisão precisa conseguir mudar a rota

Agentes que executam trabalho longo encontram um ambiente que continua mudando. Documentos recebem versões novas, prioridades mudam e premissas caem enquanto a tarefa ainda está aberta.

Uma intervenção segura combina identidade, autoridade, versão, análise de impacto, ponto seguro, linhagem, checkpoint e revalidação. A pessoa consegue corrigir o rumo. O sistema continua responsável por mostrar onde a correção entrou e o que precisou ser refeito.

Fontes oficiais verificadas em 2 de outubro de 2026:

OpenAI: A model guide for the GPT-6 family, para a orientação de usar steering, ferramentas assíncronas e delegação em trabalhos longos, além de medir sucesso, latência e custo antes da produção.
OpenAI Developers: Run long horizon tasks with Codex, para o padrão de orientar trabalhos longos em marcos e manter especificação, verificação e correção de falhas.
OpenAI Agents SDK: Running agents, para execução, streaming, estado de retomada, cancelamento após turno e integrações de execução durável.
OpenAI Agents SDK: Human-in-the-loop, para pausa, interrupções, serialização de estado, aprovação e retomada de runs.
OpenAI Agents SDK: Run state, para o estado serializável usado como fronteira durável de pausa e retomada.

As fontes confirmam mecanismos e padrões do ecossistema citado. A política de intervenção, as alçadas, os pontos seguros e o tratamento de efeitos externos pertencem à arquitetura de cada empresa e precisam ser testados no ambiente adotado.