El agente recibe "actualiza el registro de Juan" y encuentra tres coincidencias posibles. Aun así, elige una y llama a la tool. En otro flujo, pregunta qué formato de archivo prefieres antes de una operación reversible que ya tiene un valor predeterminado aceptable.

El problema no es hacer preguntas. Es decidir cuándo adivinar cuesta más que esperar. Un agente debe pedir una aclaración cuando la información que falta puede cambiar el objetivo, la autoridad, la evidencia o el efecto de la siguiente acción. Si un valor predeterminado verificado y reversible sigue siendo útil, puede continuar y registrar la suposición.

Esta pregunta debe ocurrir antes de la tool, no después de que haya un efecto externo. También es distinta de cuándo un agente de IA debe pedir aprobación humana: la aclaración aporta un dato que falta; la aprobación autoriza una acción ya comprendida.

Diagrama dibujado de un agente de IA que elige entre preguntar, usar un valor predeterminado seguro y llamar a una tool.

Respuesta corta

  • Pregunta cuando la información que falta puede elegir otro registro, destinatario, recurso o efecto.
  • Continúa cuando existe un valor predeterminado conocido, reversible y compatible con el objetivo.
  • No confundas una pregunta de aclaración con aprobación, escalamiento o una tarea nueva.
  • Pausa la tool con un estado explícito y conserva el paso actual.
  • Trata la respuesta, la cancelación, el timeout y la pregunta no entregada como resultados distintos.

¿Debe preguntar o usar un valor predeterminado seguro?

La regla práctica es comparar la consecuencia de la suposición con el valor de continuar. Si un error puede cambiar un registro, enviar algo a la persona equivocada, consumir un recurso limitado o aplicar una política diferente, pregunta antes de la tool. Si la elección es reversible y la aplicación definió el valor predeterminado, continúa haciendo visible la suposición.

La guía de prompting de GPT-5.1 de OpenAI, consultada el 23 de octubre de 2026, recomienda pausar y hacer de una a tres preguntas breves cuando la información ausente cambiaría un plan concreto. La misma guía indica que se puede continuar con valores predeterminados cuando sea seguro. La condición importa más que convertir tres preguntas en una regla fija.

Usa esta matriz antes de decidir:

Situación Decisión antes de la tool Ejemplo
Falta un identificador y existen varios candidatos Preguntar "¿Qué pedido quieres cancelar?"
Falta una preferencia reversible y el valor predeterminado está documentado Continuar y registrarlo Usar Markdown cuando el proyecto define ese formato
La acción tiene un efecto externo y la persona aún no la autorizó Pedir aprobación Confirmar el envío cuando el destinatario ya esté definido
La información contradice el estado persistido Detenerse y reconciliar El registro actual no pertenece a la cuenta esperada
La respuesta no llega Mantener pendiente o terminar explícitamente No convertir un timeout en autorización

No uses la confianza textual del modelo como única señal. El agente puede decir que entendió y seguir eligiendo entre dos objetivos. La política debe revisar la acción candidata, los campos ausentes y el efecto posible. El modelo ayuda a redactar la pregunta; el runtime decide si la tool puede ejecutarse.

La ambigüedad no es el disparador. El disparador es la ambigüedad que cambia una decisión. Un nombre incompleto puede bastar para una consulta de lectura que devuelva candidatos para revisar. El mismo nombre incompleto antes de una escritura exige una pausa o una política distinta.

¿Aclaración, aprobación y escalamiento son lo mismo?

No. La aclaración responde "¿qué dato falta?". La aprobación responde "¿autorizas esta acción específica?". El escalamiento responde "¿qué persona o sistema debe hacerse cargo porque al agente le faltan autoridad o evidencia?". Mezclar estas interacciones produce pantallas confusas y estados difíciles de probar.

La guía de tools del OpenAI Agents SDK, consultada el 23 de octubre de 2026, coloca la ejecución, la aprobación, el timeout, la salida y el manejo de errores en la frontera de la tool. Esa frontera es un buen lugar para mantener la política, aunque el agente proponga la pregunta.

Una secuencia segura puede ser:

  1. El modelo propone la siguiente acción y sus posibles argumentos.
  2. El runtime comprueba si falta un campo que puede cambiar el efecto.
  3. Si falta, el runtime crea una pregunta pendiente y no llama a la tool.
  4. La persona responde, cancela o no responde dentro del plazo.
  5. El runtime valida la respuesta contra la tarea y la versión actual del estado.
  6. Solo entonces la acción vuelve a la política de aprobación o a la ejecución.

La guía de uso de tools de Anthropic, consultada el 23 de octubre de 2026, observa que un modelo puede inferir un parámetro ausente en lugar de preguntar. Por eso la decisión no debe depender solo de la conducta espontánea del modelo. Un parámetro obligatorio en el schema ayuda, pero el runtime todavía debe distinguir entre "no sé cuál es el objetivo" y "sé cuál es el objetivo, pero falta autorización".

¿Cómo se coloca la decisión en la frontera de la tool?

Empieza describiendo la acción candidata sin ejecutarla. La política recibe el campo ausente, el tipo de consecuencia, la reversibilidad y un posible valor predeterminado. Devuelve una decisión discriminada: ask, proceed, approve o stop.

El siguiente ejemplo es una fixture ilustrativa. No usa un SDK de agentes ni llama a un servicio externo. La idea es mantener la decisión determinista y dejar la interfaz del proveedor en un 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: ["Primera opción", "Segunda opción"],
    };
  }
  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" };
}

El criterio es deliberadamente simple. En una aplicación real, missing puede venir de una validación de dominio, una búsqueda ambigua o una política de autorización. La función no debe decidir que dos cuentas son iguales solo porque el modelo eligió la misma cadena para ambas.

El resultado ask es una instrucción para crear una pausa, no un mensaje final. Un adaptador puede mostrar una pregunta en una interfaz, enviar un evento a una cola o devolver una respuesta intermedia. En cualquier canal, la tool con efecto debe seguir bloqueada hasta que exista una respuesta válida.

¿Cómo se representa una pausa que se puede reanudar?

La pausa debe guardar lo necesario para reanudar sin comenzar de nuevo ni aplicar una respuesta antigua. Una versión del estado impide usar una pregunta creada antes de un cambio como si todavía estuviera vigente.

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 };
}

El estado no debe guardar solo la pregunta. currentStep indica dónde estaba la tarea, taskId evita cruzar ejecuciones y stateVersion rechaza respuestas tardías. El ejecutor puede convertir answered en argumentos para el siguiente paso, pero debe validar el dominio otra vez antes de llamar a la tool.

El escenario de evaluación de navegación de procesos de Microsoft, consultado el 23 de octubre de 2026, comprueba si un agente responde a una interrupción y reanuda el paso correcto. Una pregunta útil no puede hacer que el workflow vuelva al principio ni que salte una dependencia.

La cancelación, el timeout y el fallo de entrega necesitan estados propios. Un timeout no es una respuesta de la persona. Si el producto quiere usar un valor predeterminado después del plazo, debe ser una política explícita limitada al caso reversible. No debe convertir en answered la ausencia de forma silenciosa.

¿Cómo se hace una pregunta que reduzca la incertidumbre?

Pregunta por la decisión, no por toda la conversación. Una buena pregunta apunta a un campo que cambia la siguiente acción, usa opciones breves cuando el conjunto es finito y deja claro qué ocurrirá después. "¿Qué quieres hacer?" devuelve la planificación al usuario. "¿Cuál de estos dos pedidos debo actualizar?" reduce la elección que bloquea la tool.

El paper de Findings of ACL 2026 sobre clarificación guiada por incertidumbre estructurada, consultado el 23 de octubre de 2026, modela la decisión como una elección entre ejecutar la mejor acción candidata y preguntar. Usa un estado de creencias, preguntas dirigidas a parámetros concretos y un coste para evitar preguntas redundantes. Es investigación, no un umbral listo para copiar, pero refuerza una separación útil entre un campo incierto y una pregunta genérica.

Elige la pregunta en este orden:

  1. Enumera las acciones candidatas que tendrían efectos diferentes.
  2. Identifica el campo cuyo valor separa esas acciones.
  3. Pregunta solo por ese campo o por una opción que lo represente.
  4. Incluye una opción de cancelación cuando la tarea pueda abandonarse.
  5. Después de la respuesta, vuelve a evaluar la acción y la autoridad.

Limita las preguntas consecutivas. El número correcto depende del flujo, la interfaz y el coste de cada turno. Empezar con una pregunta que cambie la acción es mejor que obligar a cada tarea a completar un formulario. Si todavía falta contexto después de la respuesta, crea otra pausa explicable o entrega el caso a una persona.

¿Cómo se prueba el camino en que el agente no debe preguntar?

Prueba la decisión, el estado y el efecto. Un agente puede formular la pregunta correcta y fallar si la tool se llama antes de la respuesta, si una respuesta repetida ejecuta dos veces o si el modo unattended salta la pausa.

Una matriz inicial debe incluir:

  • campo ausente con consecuencia alta: debe crear waiting y hacer cero llamadas a la tool;
  • campo ausente con valor predeterminado reversible: debe continuar y registrar la suposición;
  • respuesta válida: debe reanudar el mismo taskId y currentStep;
  • respuesta fuera de las opciones: debe permanecer pendiente;
  • respuesta repetida: debe rechazarse después de consumir la pregunta;
  • versión antigua del estado: debe rechazarse;
  • cancelación: debe producir cero efectos y un motivo observable;
  • timeout: debe permanecer pendiente o terminar según la política, sin convertirse en una respuesta;
  • pregunta no entregada: no debe liberar la tool;
  • ausencia de usuario: debe respetar el modo de pausa, sin fingir que llegó una respuesta.

En un informe de regresión de Hermes WebUI, la interfaz necesitaba un callback capaz de recibir preguntas en lote y devolver un sobre estructurado de respuestas y resultado. El caso muestra por qué las pruebas deben cubrir el contrato completo de la interacción, incluida la cancelación y la entrega, no solo el texto de la pregunta.

El camino negativo importa tanto como el camino de pregunta. Dale al agente una solicitud suficientemente determinada y confirma que no aparece ninguna pregunta. Después proporciona una ambigüedad que cambie el objetivo y confirma que la ejecución queda bloqueada. Esta comparación evita que una regla de "preguntar siempre" parezca segura simplemente porque nunca permite actuar al agente.

La guía de trayectoria de agentes amplía la matriz con el orden de las tools, los argumentos y la detención. La guía de validación de tool calls en TypeScript cubre schemas y fronteras de datos. Este artículo se queda un paso antes: decidir si la acción debe existir antes de validar o ejecutar sus argumentos.

¿Cuándo no es la pregunta la mejor salida?

No preguntes cuando la respuesta no cambiaría la siguiente decisión. Si todas las opciones llevan a la misma lectura segura, la pregunta solo traslada trabajo a la persona. Usa un valor predeterminado documentado, regístralo y permite corregirlo cuando el efecto sea reversible.

Tampoco intentes resolver una falta de autoridad con una pregunta de preferencia. Si el agente no puede acceder al registro, un "sí" no concede permiso. Usa la política de aprobación o entrega el caso a la persona responsable. La guía para pausar y reanudar un agente sin reiniciarlo cubre el límite de la pausa; aquí el punto es decidir si lo que falta es un dato, autorización o una detención.

Si la información está en una fuente que la aplicación puede consultar con seguridad, una tool de lectura puede ser mejor que una pregunta. El agente puede encontrar candidatos, mostrar la ambigüedad y pedir entonces que la persona elija. Eso reduce la carga sin convertir una búsqueda aproximada en una escritura automática.

Por último, no conviertas el prompt en un contrato de ejecución. La instrucción puede decirle al modelo que pregunte, pero el runtime debe bloquear la tool, validar la respuesta y conservar el estado. Sin esa barrera, el agente puede escribir una pregunta correcta y aun así ejecutar la acción equivocada en el turno siguiente.

Checklist para liberar aclaraciones en un agente

  • ¿La política dice qué consecuencia hace que la información sea necesaria para decidir?
  • ¿El agente diferencia valor predeterminado seguro, aclaración, aprobación, escalamiento y detención?
  • ¿La pregunta ocurre antes de la tool con efecto?
  • ¿El estado guarda taskId, versión, paso y estado?
  • ¿La respuesta se valida contra la tarea actual y las opciones permitidas?
  • ¿La cancelación, el timeout y el fallo de entrega siguen siendo distintos de una respuesta?
  • ¿La reanudación vuelve al paso correcto sin repetir efectos?
  • ¿Existe una prueba en la que el agente no debe preguntar?
  • ¿El modo unattended tiene una regla explícita para preguntas pendientes?
  • ¿El log registra la decisión sin guardar datos innecesarios o secretos?

Un agente confiable no es el que pregunta más. Es el que reconoce qué carencias cambian la acción y convierte esa decisión en un estado que el código puede bloquear, probar y reanudar.

Preguntas rápidas

¿El agente debe preguntar cada vez que falta un parámetro?

No. Si el parámetro tiene un valor predeterminado verificado y la operación es reversible, el agente puede continuar registrando la suposición. Pregunta cuando la ausencia pueda cambiar el objetivo, la autorización, la evidencia o el efecto. El schema de la tool ayuda a encontrar campos obligatorios, pero no decide por sí solo la consecuencia de cada valor.

¿Una pregunta de aclaración sustituye la aprobación humana?

No. La aclaración completa la información necesaria para definir la acción. La aprobación autoriza una acción ya definida cuyo objetivo y argumentos la persona puede revisar. Mantén los estados separados para no interpretar una respuesta de preferencia como autorización de un efecto externo.

¿Qué ocurre si la persona no responde?

La tarea debe quedar pendiente o terminar con un resultado explícito de timeout, cancelación o fallo de entrega. El silencio no es una respuesta. Un valor predeterminado después del timeout solo es aceptable cuando la aplicación lo definió y sigue siendo seguro, reversible y observable para ese flujo.

Cómo se produjo este artículo

Samuel Fajreldines es responsable de este artículo. La investigación comparó la documentación actual de OpenAI, OpenAI Agents SDK y Anthropic, un paper primario de Findings of ACL 2026, el material de evaluación de Microsoft y discusiones públicas recientes. Una fixture equivalente en JavaScript se ejecutó localmente con siete assertions sobre decisión, pausa, reanudación, respuesta repetida, cancelación, timeout y versión antigua. El código TypeScript es ilustrativo y no llamó a un modelo, proveedor o servicio externo.

La asistencia de IA apoyó la búsqueda de fuentes, la organización, la redacción, la localización, la generación de la imagen y la revisión de consistencia. No aportó una prueba de producción, benchmark, entrevista ni incidente de cliente. Para mantener el contexto entre sesiones, el autor usa RemoteCode, una herramienta propia; esto no demuestra que el patrón mejore el rendimiento.

Fuentes consultadas