Quando um agente de IA deve pedir esclarecimento?

O agente recebe "atualize o cadastro do João" e encontra três registros possíveis. Mesmo assim, escolhe um deles e chama a tool. Em outro fluxo, pergunta qual formato de arquivo você prefere antes de uma operação reversível que já tem um default aceitável.

O problema não é fazer perguntas. É decidir quando o custo de adivinhar supera o custo de esperar. Um agente deve pedir esclarecimento quando a informação ausente pode mudar o alvo, a autoridade, a evidência ou o efeito da próxima ação. Se um default verificado e reversível continua útil, ele pode prosseguir e registrar a suposição.

Essa pergunta acontece antes da tool, não depois de um efeito externo. Ela também é diferente de quando um agente de IA deve pedir aprovação humana: esclarecimento fornece um dado que falta; aprovação autoriza uma ação já compreendida.

Diagrama desenhado mostra um agente de IA escolhendo entre perguntar, usar um default seguro e chamar uma tool.

Resposta curta

Pergunte quando a informação ausente puder escolher outro registro, destinatário, recurso ou efeito.

Prossiga quando houver um default conhecido, reversível e compatível com o objetivo.

Não confunda uma pergunta de esclarecimento com aprovação, escalonamento ou uma nova tarefa.

Pause a tool com um estado explícito e preserve o passo atual.

Trate resposta, cancelamento, timeout e pergunta não entregue como resultados diferentes.

O agente deve perguntar ou usar um default seguro?

A regra prática é comparar a consequência da suposição com a utilidade de continuar. Se errar pode alterar um registro, enviar algo para a pessoa errada, gastar uma capacidade limitada ou aplicar uma política diferente, faça a pergunta antes da tool. Se a escolha é reversível e o default foi definido pela aplicação, continue com a suposição visível.

A orientação da OpenAI sobre prompting do GPT-5.1, consultada em 23 de outubro de 2026, recomenda pausar e fazer de uma a três perguntas breves quando faltam informações que mudariam um plano concreto. A mesma orientação pede que o agente avance com defaults quando isso for seguro. O valor está na condição, não em transformar três perguntas numa regra fixa.

Use esta matriz antes de decidir:

Situação	Decisão antes da tool	Exemplo
Falta um identificador e existem vários candidatos	Perguntar	"Qual pedido você quer cancelar?"
Falta uma preferência reversível com default documentado	Prosseguir e registrar	usar Markdown quando o projeto define esse formato
A ação tem efeito externo e a pessoa ainda não autorizou	Pedir aprovação	confirmar o envio depois que o destinatário estiver definido
A informação contradiz o estado persistido	Parar e reconciliar	o registro atual não pertence à conta esperada
A resposta não chega	Permanecer pendente ou encerrar	não converter timeout em autorização

Não use a confiança textual do modelo como única medida. O agente pode dizer que "entendeu" e ainda estar escolhendo entre dois alvos. A política precisa olhar para a ação candidata, os campos ausentes e o efeito possível. O modelo ajuda a formular a pergunta; o runtime decide se a tool pode ser chamada.

Ambiguidade não é o gatilho. O gatilho é a ambiguidade que muda uma decisão. Um nome incompleto em uma busca exploratória pode permitir uma consulta de leitura com resultados para revisão. O mesmo nome incompleto antes de uma escrita exige pausa ou uma política diferente.

Esclarecimento, aprovação e escalonamento são a mesma coisa?

Não. Esclarecimento responde "qual dado está faltando?". Aprovação responde "você autoriza esta ação específica?". Escalonamento responde "qual pessoa ou sistema deve assumir porque o agente não tem autoridade ou evidência suficiente?". Misturar essas três interações produz telas confusas e estados impossíveis de testar.

O guia de tools do OpenAI Agents SDK, consultado em 23 de outubro de 2026, coloca execução, aprovação, timeout, saída e tratamento de erro na fronteira da tool. Essa fronteira é um bom lugar para manter a política, mesmo que o agente proponha a pergunta.

Uma sequência segura pode ser:

O modelo propõe a próxima ação e os argumentos possíveis.
O runtime verifica se falta um campo que pode mudar o efeito.
Se faltar, o runtime cria uma pergunta pendente e não chama a tool.
A pessoa responde, cancela ou não responde dentro do prazo.
O runtime valida a resposta contra a tarefa e a versão do estado.
Só então a ação volta para a política de aprovação ou para a execução.

O guia de uso de tools da Anthropic, consultado em 23 de outubro de 2026, observa que um modelo pode inferir um parâmetro ausente em vez de perguntar. Isso é precisamente o motivo para não deixar a decisão apenas no comportamento espontâneo do modelo. Um parâmetro obrigatório no schema ajuda, mas o runtime ainda precisa distinguir "não sei qual alvo" de "sei o alvo, mas falta autorização".

Como colocar a decisão na fronteira da tool?

Comece descrevendo a ação candidata sem executar nada. A política recebe o campo ausente, o tipo de consequência, a reversibilidade e um default possível. Ela devolve uma decisão discriminada: ask, proceed, approve ou stop.

O exemplo abaixo é uma fixture ilustrativa. O código não usa um SDK de agente e não chama um serviço externo. A ideia é manter a decisão determinística e deixar a interface do provedor para um adaptador separado.

type Consequence = "low" | "high";

type NextDecision =
  | { kind: "ask"; question: string; options?: string[] }
  | { kind: "proceed"; assumption: string | null }
  | { kind: "approve" }
  | { kind: "stop"; reason: string };

type DecisionInput = {
  missing?: string;
  consequence: Consequence;
  reversible: boolean;
  safeDefault?: string;
  needsApproval: boolean;
};

function decideNext(input: DecisionInput): NextDecision {
  if (input.missing && !(input.reversible && input.safeDefault)) {
    return {
      kind: "ask",
      question: input.missing,
      options: ["Primeira opção", "Segunda opção"],
    };
  }
  if (input.needsApproval) return { kind: "approve" };
  if (input.consequence === "low" && input.reversible) {
    return { kind: "proceed", assumption: input.safeDefault ?? null };
  }
  return { kind: "stop", reason: "no safe decision is available" };
}

O critério é deliberadamente simples. Em uma aplicação real, missing pode ser produzido por validação de domínio, por uma busca ambígua ou por uma política de autorização. A função não deve decidir que duas contas são iguais só porque o modelo escolheu a mesma string para ambas.

O resultado ask é uma instrução para criar uma pausa, não uma mensagem final. O adaptador pode mostrar uma pergunta em uma interface, enviar um evento para uma fila ou devolver uma resposta intermediária. Em qualquer canal, a tool de efeito continua bloqueada até existir uma resposta válida.

Como representar uma pausa que pode ser retomada?

A pausa precisa guardar o mínimo que permita retomar sem recomeçar e sem aplicar uma resposta velha. Uma versão de estado impede que uma pergunta criada antes de uma alteração seja usada depois como se ainda fosse atual.

type ClarificationState = {
  taskId: string;
  stateVersion: number;
  currentStep: string;
  status: "waiting" | "answered" | "cancelled" | "timed_out" | "undelivered";
  question: string;
  options: string[];
  answer?: string;
};

function acceptAnswer(
  state: ClarificationState,
  answer: string,
  expectedVersion: number,
): ClarificationState {
  if (state.status !== "waiting") throw new Error("clarification is no longer pending");
  if (state.stateVersion !== expectedVersion) throw new Error("stale clarification");
  if (state.options.length > 0 && !state.options.includes(answer)) {
    throw new Error("answer is outside the allowed options");
  }
  return { ...state, status: "answered", answer };
}

O estado não deve guardar apenas a pergunta. currentStep informa onde a tarefa estava, taskId impede cruzamento entre execuções e stateVersion rejeita respostas atrasadas. O executor pode transformar answered em argumentos para a próxima etapa, mas deve revalidar o domínio antes da tool.

O cenário de avaliação de navegação de processos da Microsoft, consultado em 23 de outubro de 2026, testa se o agente responde uma interrupção e retoma o passo correto. Uma pergunta útil não pode fazer o workflow voltar ao começo ou pular uma dependência.

Cancelamento, timeout e falha de entrega precisam parar em estados próprios. Um timeout não é uma resposta do usuário. Se o produto deseja seguir com um default depois do prazo, isso deve ser uma política explícita e limitada ao caso reversível, não uma conversão silenciosa de ausência em answered.

Como fazer uma pergunta que realmente reduz a incerteza?

Pergunte sobre a decisão, não sobre a conversa inteira. Uma boa pergunta aponta para um campo que muda a próxima ação, usa opções curtas quando o conjunto é finito e deixa claro o que acontece depois. "O que você quer fazer?" devolve o planejamento ao usuário. "Qual destes dois pedidos devo atualizar?" reduz a escolha que bloqueia a tool.

Um paper dos Findings of ACL 2026 sobre clarificação guiada por incerteza estruturada, consultado em 23 de outubro de 2026, modela a decisão como uma escolha entre executar a melhor ação candidata e perguntar. O trabalho usa estado de crença, perguntas que atingem parâmetros específicos e um custo para evitar perguntas redundantes. Isso é pesquisa, não um limiar pronto para copiar, mas reforça uma separação útil entre campo incerto e pergunta genérica.

Escolha a pergunta nesta ordem:

Liste as ações candidatas que teriam efeitos diferentes.
Identifique o campo cujo valor separa essas ações.
Pergunte apenas por esse campo ou por uma escolha que o represente.
Inclua uma opção de cancelamento quando a tarefa puder ser abandonada.
Depois da resposta, reavalie a ação e a autoridade.

Limite perguntas consecutivas. O número certo depende do fluxo, da interface e do custo de cada turno. Começar com uma pergunta load-bearing é melhor do que obrigar toda tarefa a responder um formulário completo. Se ainda faltar contexto depois da resposta, crie outra pausa explicável ou encaminhe para uma pessoa.

Como testar o caminho em que o agente não deve perguntar?

Teste a decisão, o estado e o efeito. Um caso em que o agente faz a pergunta certa ainda pode falhar se a tool for chamada antes da resposta, se uma resposta repetida executar duas vezes ou se o modo unattended pular a pausa.

Uma matriz inicial deve incluir:

campo ausente com consequência alta: deve criar waiting e zero chamadas à tool;
campo ausente com default reversível: deve prosseguir e registrar a suposição;
resposta válida: deve retomar o mesmo taskId e currentStep;
resposta fora das opções: deve permanecer pendente;
resposta repetida: deve ser rejeitada depois de consumir a pergunta;
estado com versão antiga: deve ser rejeitado;
cancelamento: deve produzir zero efeitos e um motivo observável;
timeout: deve continuar pendente ou encerrar conforme a política, sem virar resposta;
pergunta não entregue: não deve liberar a tool;
execução sem usuário disponível: deve respeitar o modo de pausa, não fingir que recebeu uma resposta.

No relato de uma regressão no Hermes WebUI, a interface precisava adaptar um callback para receber perguntas em lote e devolver um envelope estruturado de respostas e resultado. O caso mostra por que o teste deve cobrir o contrato completo da interação, incluindo cancelamento e entrega, não apenas o texto da pergunta.

O teste de caminho negativo é tão importante quanto o de pergunta. Dê ao agente uma solicitação suficientemente determinada e confirme que nenhuma pergunta aparece. Depois forneça uma ambiguidade que muda o alvo e confirme que a execução fica bloqueada. Essa comparação impede que uma regra de "sempre pergunte" pareça segura apenas porque nunca deixa o agente agir.

O guia de trajetória do agente amplia a matriz para ordem de tools, argumentos e parada. Já o guia de validação de tool calls em TypeScript cobre schema e fronteiras de dados. Este post fica no ponto anterior: decidir se a ação deve existir antes de validar ou executar seus argumentos.

Quando a pergunta não é a melhor saída?

Não pergunte quando a resposta não mudaria a próxima decisão. Se todas as opções levam à mesma leitura segura, a pergunta só transfere trabalho para a pessoa. Use um default documentado, registre-o e permita correção quando o efeito for reversível.

Também não tente resolver uma falta de autoridade com uma pergunta de preferência. Se o agente não pode acessar o registro, a resposta "sim" não concede permissão. Use a política de aprovação ou encaminhe para o responsável. O guia sobre pausar e retomar um agente sem reiniciar cobre a fronteira de pausa; aqui, o ponto é decidir se a ausência pede dado, autorização ou parada.

Se a informação está em uma fonte que a aplicação pode consultar com segurança, uma tool de leitura pode ser melhor que uma pergunta. O agente pode localizar candidatos, mostrar a ambiguidade e só então pedir a escolha. Isso reduz a carga sobre a pessoa sem transformar uma busca aproximada em uma escrita automática.

Por fim, não transforme o prompt em um contrato de execução. A instrução pode orientar o modelo a perguntar, mas o runtime precisa bloquear a tool, validar a resposta e preservar o estado. Sem essa barreira, o agente pode produzir uma pergunta correta no texto e ainda executar a ação errada no turno seguinte.

Checklist para liberar esclarecimentos em um agente

A política diz qual consequência torna uma informação load-bearing?
O agente diferencia default seguro, esclarecimento, aprovação, escalonamento e parada?
A pergunta acontece antes da tool com efeito?
O estado guarda taskId, versão, passo e status?
Uma resposta é validada contra a tarefa atual e as opções permitidas?
Cancelamento, timeout e falha de entrega permanecem diferentes de resposta?
A retomada volta ao passo certo sem repetir efeitos?
Existe um caso de teste em que o agente não deve perguntar?
O modo unattended tem uma regra explícita para perguntas pendentes?
O log registra a decisão sem guardar dados desnecessários ou segredos?

Um agente confiável não é o que pergunta mais. É o que reconhece quais lacunas mudam a ação e transforma essa decisão em um estado que o código consegue bloquear, testar e retomar.

Perguntas rápidas

O agente deve perguntar sempre que faltar um parâmetro?

Não. Se o parâmetro tiver um default verificado e a operação for reversível, o agente pode prosseguir registrando a suposição. Pergunte quando a ausência puder mudar o alvo, a autorização, a evidência ou o efeito. O schema da tool ajuda a encontrar campos obrigatórios, mas não decide sozinho a consequência de cada valor.

Uma pergunta de esclarecimento substitui aprovação humana?

Não. Esclarecimento completa a informação necessária para definir a ação. Aprovação autoriza uma ação já definida, com alvo e argumentos que a pessoa consegue revisar. Mantenha os estados separados para não interpretar uma resposta de preferência como autorização para executar um efeito externo.

O que acontece se a pessoa não responder?

A tarefa deve ficar pendente ou terminar com um resultado explícito de timeout, cancelamento ou falha de entrega. Não trate silêncio como resposta. Um default após timeout só é aceitável quando foi definido pela aplicação e continua seguro, reversível e observável para aquele fluxo.

Como este artigo foi produzido

Samuel Fajreldines é o autor responsável por este artigo. A pesquisa comparou a documentação atual da OpenAI, do OpenAI Agents SDK e da Anthropic, um paper primário dos Findings of ACL 2026, o material de avaliação da Microsoft e discussões públicas recentes. Uma fixture equivalente em JavaScript foi executada localmente com sete assertions sobre decisão, pausa, retomada, resposta repetida, cancelamento, timeout e versão antiga. O código TypeScript é uma adaptação ilustrativa e não chamou um modelo, um provedor ou um serviço externo.

A assistência de IA apoiou descoberta de fontes, organização, redação, localização, geração da imagem e revisão de consistência. Ela não forneceu teste de produção, benchmark, entrevista ou incidente de cliente. Para manter contexto entre sessões, o autor usa o RemoteCode, uma ferramenta própria; isso não é evidência de desempenho do padrão descrito.

Quando um agente de IA deve pedir esclarecimento antes de usar uma tool?