Respuesta correcta: A)

Por qué es correcto: Cuando stop_reason es tool_use, el modelo está esperando que la aplicación ejecute la herramienta y devuelva el resultado. El contrato del agentic loop requiere agregar el bloque tool_result al historial con role: "user" antes de llamar de nuevo a la API.

Por qué las otras opciones son incorrectas:

• B) Llamar de nuevo sin el resultado causa que el modelo repita la misma llamada a herramienta indefinidamente.
• C) stop_reason: "tool_use" nunca produce texto parcial listo para el usuario — el modelo está a mitad de su razonamiento.
• D) Solo stop_reason: "end_turn" o "max_tokens" indica que el modelo terminó. "tool_use" es una pausa explícita para ejecución de herramienta.

Respuesta correcta: B)

Por qué es correcto: tool_choice: { type: "any" } obliga al modelo a llamar al menos una herramienta del conjunto disponible, sin importar cuál. Es la forma de garantizar uso de herramienta sin forzar una herramienta específica.

Por qué las otras opciones son incorrectas:

• A) "auto" permite al modelo decidir si usa o no una herramienta — puede responder solo con texto.
• C) { type: "tool", name: "..." } fuerza una herramienta específica, no “cualquier herramienta”.
• D) Las instrucciones en el system prompt no garantizan comportamiento estructural; el modelo puede ignorarlas bajo ciertos contextos. Para garantías de comportamiento se usan parámetros de API.

Respuesta correcta: C)

Por qué es correcto: El patrón más robusto para imponer orden de herramientas es el control dinámico del conjunto de herramientas disponibles. Hasta que get_customer no responda exitosamente, process_refund simplemente no existe para el modelo — es imposible que la llame. Esto garantiza el invariante sin depender de instrucciones que el modelo podría ignorar.

Por qué las otras opciones son incorrectas:

• A) Instrucciones en system prompt son guías, no restricciones estructurales. Un modelo puede inferir que el cliente es conocido sin llamar explícitamente a get_customer.
• B) Los hooks PreToolUse son válidos pero requieren estado compartido entre turnos, que es frágil en sesiones stateless. Además, el hook bloquea pero no redirige — el modelo puede quedar en un estado de error.
• D) Forzar get_customer en el primer turno no impide que el modelo llame process_refund antes en un turno posterior si las herramientas están todas disponibles.

Respuesta correcta: B)

Por qué es correcto: En Claude Code, un hook que retorna exit code 2 comunica una decisión de bloqueo estructurada. El JSON en stdout con "decision": "block" le informa al agente orquestador que la herramienta fue bloqueada y por qué, permitiendo que el agente tome la siguiente acción correcta (en este caso, escalar).

Por qué las otras opciones son incorrectas:

• A) Exit code 1 indica error genérico, no bloqueo intencional. El comportamiento resultante es ambiguo.
• C) Un hook no debe ejecutar lógica de negocio por su cuenta — su rol es gate-keeping, no acción. Llamar herramientas desde hooks crea loops y efectos secundarios difíciles de rastrear.
• D) Mutar parámetros de herramientas en hooks es un anti-patrón grave de seguridad — introduce comportamiento no auditado y viola el principio de transparencia.

Respuesta correcta: B)

Por qué es correcto: La escalación debe activarse por dos criterios claros: (1) preferencia explícita del cliente por atención humana y (2) incapacidad del agente para resolver con sus herramientas actuales. En este caso, el cliente dice “quiero hablar con una persona” — criterio 1 se cumple directamente.

Por qué las otras opciones son incorrectas:

• A) El análisis de sentimiento por palabras sueltas produce falsos positivos. “Quiero un reembolso” no requiere escalación humana.
• C) Esperar 3 fallos es demasiado tarde — el cliente ya expresó preferencia humana antes de cualquier intento.
• D) El tiempo de espera es un dato, no un criterio de escalación por sí solo. Puede resolverse automáticamente con lookup_order.

Respuesta correcta: B)

Por qué es correcto: El modelo infiere el orden de herramientas desde sus descripciones. Si get_customer no documenta explícitamente que es prerequisito de lookup_order, y si lookup_order no documenta que requiere el output de get_customer, el modelo tomará el orden que le parezca más lógico según el contexto del mensaje del usuario.

Por qué las otras opciones son incorrectas:

• A) La temperatura afecta creatividad/variabilidad de texto, no la selección de orden de herramientas de forma sistemática (el 40% es un patrón, no aleatoriedad).
• C) La validación de inputs en el schema arroja un error después de que la herramienta es llamada, no previene que sea llamada en el orden incorrecto.
• D) Un system prompt largo puede afectar el seguimiento de instrucciones, pero si el problema es sistemático (40%), la causa más probable es la falta de documentación en las tool descriptions.

Respuesta correcta: B)

Por qué es correcto: Plan Mode (flag --plan) hace que Claude genere un plan de acción sin ejecutar ningún cambio. Es ideal para cambios multi-archivo o estructurales donde el costo de revertir errores es alto. El desarrollador aprueba el plan antes de cualquier modificación.

Por qué las otras opciones son incorrectas:

• A) El tiempo no es el criterio — una tarea de 10 minutos en un solo archivo puede ejecutarse directamente. El criterio es el riesgo y la amplitud del cambio.
• C) Plan Mode tiene costo de latencia pero reduce el riesgo de cambios incorrectos en código crítico. Para un módulo de 800 líneas, el tradeoff favorece Plan Mode.
• D) Plan Mode es sobre control y revisión, no sobre la competencia del desarrollador.

Respuesta correcta: B)

Por qué es correcto: La solución correcta es a nivel de orquestación del pipeline: rastrear qué commits y archivos fueron producidos por Claude (por autor git, tag en el mensaje de commit, o metadata) y excluirlos del conjunto de archivos que se envían a la revisión. Es una separación de responsabilidades implementada en la infraestructura, no en el prompt.

Por qué las otras opciones son incorrectas:

• A) Las instrucciones en el prompt no son confiables para restricciones de seguridad o integridad del proceso — el modelo no tiene acceso confiable a saber qué líneas escribió él.
• C) Dos modelos diferentes no resuelven el problema si ambos reciben el mismo diff — el segundo modelo tampoco sabe qué generó el primero.
• D) El problema ocurre en feature branches específicamente cuando se usa Claude para generar código. Excluir feature branches elimina el caso de uso completo.

Respuesta correcta: C)

Por qué es correcto: El flag --print (forma corta -p) hace que Claude Code imprima la respuesta y salga inmediatamente, sin modo interactivo. Es el flag estándar para uso headless en pipelines de CI/CD.

Por qué las otras opciones son incorrectas:

• A) --silent no es un flag de Claude Code para modo no-interactivo.
• B) --no-interactive no existe como flag en Claude Code (aunque el concepto suena intuitivo).
• D) --batch no es un flag de Claude Code.

Respuesta correcta: B)

Por qué es correcto: CLAUDE.md es el mecanismo principal para dar contexto persistente a Claude. En CI/CD, Claude necesita conocer las convenciones del proyecto para que sus revisiones y generaciones sean consistentes con el estilo del equipo. Incluir reglas de style, convenciones, patrones prohibidos y contexto de dominio permite que Claude genere feedback relevante y no genérico.

Por qué las otras opciones son incorrectas:

• A) Claude sí usa CLAUDE.md en CI — es cargado automáticamente desde el directorio raíz del proyecto.
• C) Claude puede inferir algunos patrones del código, pero las convenciones explícitas son más confiables que la inferencia, especialmente para reglas de negocio.
• D) Nunca incluir credenciales en CLAUDE.md — es un archivo de texto versionado en git. Usar variables de entorno o sistemas de secretos.

Respuesta correcta: A)

Por qué es correcto: Los slash commands son accesibles desde el modo --print / -p. El mensaje enviado a Claude puede contener el slash command exactamente como se usaría en modo interactivo. Claude procesa el /security-review como la invocación del command definido en .claude/commands/.

Por qué las otras opciones son incorrectas:

• B) Esta afirmación es incorrecta — los slash commands sí funcionan en modo --print.
• C) --command no es un flag de Claude Code.
• D) --skill no es un flag de Claude Code.

Respuesta correcta: B)

Por qué es correcto: El principio de least-privilege en sistemas multi-agente dicta que cada agente solo debe tener las herramientas necesarias para su función. Si synthesis-agent tiene WebSearch, puede agregar información que no pasó por el proceso de validación y deduplicación de web-search-agent, comprometiendo la calidad y trazabilidad de los datos.

Por qué las otras opciones son incorrectas:

• A) El costo es una consideración secundaria, no la razón arquitectural principal.
• C) No hay incompatibilidad técnica — es una decisión de diseño deliberada.
• D) La latencia podría reducirse, pero no es la justificación correcta para esta restricción arquitectural.

Respuesta correcta: B)

Por qué es correcto: El patrón correcto en sistemas multi-agente es pasar los datos estructurados directamente en el contexto del mensaje, incluyendo metadata de provenance. Esto mantiene el sistema stateless (cada agente tiene todo lo que necesita en su contexto), y el provenance metadata permite que synthesis-agent atribuya correctamente las fuentes en el reporte final.

Por qué las otras opciones son incorrectas:

• A) Que synthesis-agent descargue las URLs viola la separación de responsabilidades — web-search ya validó y procesó el contenido.
• C) Una base de datos compartida introduce estado mutable compartido, que crea acoplamiento y problemas de concurrencia en sistemas de agentes paralelos.
• D) Serializar objetos en base64 no es un patrón de inter-agente — es opaco, difícil de depurar y no portable.

Respuesta correcta: C)

Por qué es correcto: La integridad de los datos es más importante que la comodidad de tener un solo número. El coordinador debe preservar ambas versiones con su provenance, marcar el conflicto explícitamente, y dejar que el reporte final refleje la incertidumbre. Inventar un consenso (promedio) o elegir arbitrariamente uno sería desinformación.

Por qué las otras opciones son incorrectas:

• A) “Más reciente” puede ser el incorrecto — un artículo web podría estar desactualizado respecto a un informe oficial anterior.
• B) El promedio de cifras estadísticas es estadísticamente inválido y opaco — pierde el contexto de las fuentes originales.
• D) synthesis-agent no tiene herramientas para determinar cuál fuente es más confiable — eso requiere contexto que el coordinador tiene.

Respuesta correcta: B)

Por qué es correcto: Un ciclo de espera circular entre agentes es un deadlock clásico. La detección requiere dos elementos: (1) timeouts para identificar que un agente no responde en el tiempo esperado, y (2) un grafo de dependencias que permita al coordinador detectar el ciclo (A espera B, B espera C, C espera A).

Por qué las otras opciones son incorrectas:

• A) Un race condition ocurre cuando múltiples agentes acceden a un recurso compartido simultáneamente — aquí el problema es la espera circular, no el acceso concurrente.
• C) Un memory leak es un problema de recursos de memoria, completamente diferente.
• D) Starvation ocurre cuando un agente nunca obtiene acceso a un recurso porque otros siempre tienen prioridad — no hay ciclo de espera.

Respuesta correcta: B)

Por qué es correcto: El provenance metadata completo permite reproducibilidad, auditoría y detección de contradicciones. La URL identifica la fuente, la fecha de acceso permite detectar datos desactualizados, el autor del agente permite trazar errores, el relevance score permite priorizar en síntesis, y el extracto exacto evita distorsiones por parafraseo.

Por qué las otras opciones son incorrectas:

• A) Solo la URL no permite saber cuándo se accedió (el contenido puede haber cambiado), quién lo procesó, ni qué parte específica del documento es relevante.
• C) Nombre del agente y timestamp son necesarios pero insuficientes — sin la fuente original no hay forma de verificar el dato.
• D) El hash SHA256 verifica integridad del contenido descargado pero no aporta contexto semántico sobre la relevancia ni el origen del dato en el documento.

Respuesta correcta: B)

Por qué es correcto: El patrón eficiente es: Grep para búsqueda amplia de patrones en texto (encontrar archivos que mencionan “payment”, “/payments”, “PaymentController”, etc.) y luego Read para leer en detalle los archivos específicos identificados. Esto minimiza tokens consumidos y tiempo de ejecución.

Por qué las otras opciones son incorrectas:

• A) Read requiere saber qué archivo leer — no sirve para descubrimiento inicial en un codebase desconocido.
• C) Bash con find es válido pero Grep es la herramienta correcta para búsqueda de contenido — evita la invocación de shell innecesaria.
• D) Leer todos los archivos TypeScript en un codebase grande es extremadamente ineficiente en tokens y tiempo.

Respuesta correcta: B)

Por qué es correcto: El conjunto de herramientas disponibles ocupa espacio en el context window (cada definición con su descripción y schema). Más herramientas = más tokens de contexto = mayor costo y menor espacio para el contenido real. Además, con muchas herramientas similares el modelo tiene dificultad para distinguir cuál es la más apropiada, reduciendo la precisión de selección.

Por qué las otras opciones son incorrectas:

• A) Parcialmente verdadero (el modelo evalúa más opciones) pero incompleto — no menciona el impacto en context window ni en precisión.
• C) Las herramientas no se ignoran automáticamente — todas están disponibles y consumen tokens de contexto.
• D) No existe un límite fijo de 20 herramientas en la API de Claude.

Respuesta correcta: B)

Por qué es correcto: Esta es la distinción arquitectural fundamental. Las built-in tools de Claude Code son capacidades integradas en el CLI con gestión de permisos nativa (sandbox, allowlists, hooks). Las custom tools en la API son definidas por el desarrollador en el campo tools de la request y la aplicación cliente es responsable de ejecutarlas cuando el modelo las llama.

Por qué las otras opciones son incorrectas:

• A) La diferencia no es de hardware sino de quién implementa y ejecuta la herramienta.
• C) La diferencia es fundamental: quién ejecuta, quién gestiona permisos, y dónde vive la implementación.
• D) MCP es un protocolo adicional para exponer herramientas externas. Las custom tools en la API no requieren MCP.

Respuesta correcta: B)

Por qué es correcto: MCP (Model Context Protocol) es el estándar para conectar sistemas externos a Claude. Un MCP server expone herramientas con schemas definidos que Claude puede llamar. Para una intranet privada, un MCP server HTTP/SSE con autenticación interna es el patrón correcto.

Por qué las otras opciones son incorrectas:

• A) Incluir toda la documentación en el system prompt no escala (límite de context window) y es estático.
• C) WebSearch es para internet público — no tiene acceso a intranets privadas.
• D) Copiar manualmente es inviable para uso sistemático y rompe el propósito de la automatización.

Respuesta correcta: B)

Por qué es correcto: El Ralph Loop requiere mecanismos de observabilidad y recuperación: checkpoints en git para poder reanudar desde el último estado conocido si el agente falla, y heartbeat signals para que el coordinador sepa que el agente está vivo y progresando. Un watchdog que detecte silencio puede decidir si relanzar o escalar al usuario.

Por qué las otras opciones son incorrectas:

• A) Reiniciar cada 30 minutos sin checkpoints pierde todo el progreso acumulado.
• C) Un timeout global sin checkpoints es un kill ciego — pierde trabajo y no proporciona información sobre dónde falló.
• D) Los logs son para observabilidad humana, no para orquestación automatizada. No permiten recuperación ni detección programática de bloqueos.

Respuesta correcta: B)

Por qué es correcto: Para que una máquina procese el output (crear comentarios con línea de código, severidad, categoría), el formato estructurado JSON es obligatorio. --output-format json en Claude Code produce output parseble que el pipeline puede mapear a la API de comentarios de GitHub. El texto libre requiere parsing frágil con regex.

Por qué las otras opciones son incorrectas:

• A) El texto markdown libre es adecuado para consumo humano, no para parsing programático confiable.
• C) HTML no es válido como output de Claude Code y la API de GitHub no acepta HTML en comentarios programáticos.
• D) YAML es legible para humanos pero menos universal como formato de inter-operación de APIs que JSON.

Respuesta correcta: B)

Por qué es correcto: Los falsos positivos provienen de criterios ambiguos o subjetivos en el prompt. La solución es redefinir el prompt con criterios binarios y verificables: “reportar si: (1) hay SQL sin parámetros parametrizados, (2) hay credenciales hardcodeadas, (3) hay manejo de errores ausente en llamadas de red”. Criterios precisos = menos falsos positivos.

Por qué las otras opciones son incorrectas:

• A) Desactivar es la solución más costosa — pierde el valor del sistema en lugar de corregirlo.
• C) Aumentar temperatura aumenta la variabilidad, lo que generaría aún más falsos positivos inconsistentes.
• D) Reducir el volumen no resuelve la calidad — si el 30% son falsos positivos, el problema persiste independiente del volumen.

Respuesta correcta: B)

Por qué es correcto: Few-shot examples son más efectivos que instrucciones textuales para formatos exactos. Ver el output esperado directamente en el prompt permite al modelo replicar el formato con alta fidelidad, incluyendo detalles sutiles de estructura que son difíciles de describir en texto.

Por qué las otras opciones son incorrectas:

• A) Describir el formato en texto es menos confiable que mostrarlo — los modelos son mejores imitando que siguiendo descripciones abstractas.
• C) Pedirle al modelo que invente su propio formato requiere normalización frágil y no garantiza compatibilidad.
• D) Temperature: 0.8 aumenta la variabilidad — para formatos consistentes se quiere temperature baja (0 o 0.1).

Respuesta correcta: B)

Por qué es correcto: Session isolation garantiza que cada PR es evaluado con el mismo contexto limpio (solo el system prompt + el código del PR), sin contaminación de evaluaciones anteriores. Esto hace los resultados reproducibles (el mismo PR siempre produce el mismo review) y justos (un PR buggy anterior no afecta la evaluación del siguiente).

Por qué las otras opciones son incorrectas:

• A) La API de Claude es stateless por defecto — no hay estado que se acumule entre llamadas separadas. El costo se determina por tokens, no por sesiones.
• C) La API sí permite múltiples sesiones simultáneas.
• D) Privacidad es una consideración válida pero no es la razón primaria para session isolation en CI.

Respuesta correcta: B)

Por qué es correcto: Los criterios vagos producen resultados que varían según el contexto, el tono del código y el estado interno del modelo. Los criterios categóricos (listas explícitas de condiciones binarias) son verificables: el modelo puede responder “sí/no” para cada criterio de forma consistente. En un sistema de CI con 50+ PRs semanales, la inconsistencia destruye la confianza del equipo.

Por qué las otras opciones son incorrectas:

• A) La longitud no determina la calidad del criterio — un criterio largo puede seguir siendo vago.
• C) Los modelos más inteligentes se benefician igualmente de criterios explícitos — la ambigüedad introduce variabilidad independiente de la inteligencia del modelo.
• D) Temperature: 0 reduce variabilidad pero criterios vagos con temperature: 0 siguen produciendo interpretaciones inconsistentes entre diferentes versiones del modelo.

Respuesta correcta: B)

Por qué es correcto: La diferencia fundamental es estructural: tool_use vincula el output del modelo a un JSON schema con validación en runtime. Si el schema define que amount es number, el modelo no puede retornar una string. Con instrucciones en el prompt, el modelo tiene discreción de generar cualquier texto — puede generar JSON válido o no, con o sin los campos correctos.

Por qué las otras opciones son incorrectas:

• A) tool_use no bypassa el context window — el schema de la herramienta ocupa tokens de contexto.
• C) El mismo modelo maneja tool_use — no hay un modelo especializado separado.
• D) Las definiciones de herramientas sí consumen tokens del context window.

Respuesta correcta: A)

Por qué es correcto: Error 429 es un problema transitorio de rate limiting — el dato existe, el modelo puede extraerlo, solo hay que esperar y reintentar. Un error de validación donde fecha_contrato contiene “no especificado” indica que el documento genuinamente no contiene esa fecha — reintentar con el mismo prompt produce el mismo resultado. La acción correcta es registrar el campo como null o manejar la ausencia.

Por qué las otras opciones son incorrectas:

• B) Reintentar errores non-retryable es costoso e inútil — consume API budget y produce el mismo resultado.
• C) Los errores de schema pueden ser retryables si hay ambigüedad en el documento o si el prompt se mejora — no son categoricamente non-retryable.
• D) Backoff exponencial es la estrategia correcta para 429, no para errores de validación semántica.

Respuesta correcta: B)

Por qué es correcto: El enfoque más práctico es incluir _confidence como campo del schema y pedir al modelo que lo complete basado en evidencia textual: "high" si el valor está explícitamente en el texto, "medium" si se infiere, "low" si se asume. Esto aprovecha la capacidad del modelo de razonar sobre su propia incertidumbre.

Por qué las otras opciones son incorrectas:

• A) Contar campos extraídos mide completitud, no confianza en la exactitud de cada valor.
• C) La frecuencia de aparición puede indicar relevancia pero no confianza en la extracción — un término que aparece 5 veces puede seguir siendo ambiguo.
• D) Logprobs son una señal de confianza a nivel token, no a nivel semántico de campo. Requieren acceso a logprobs (que no siempre está disponible) y su interpretación es compleja.

Respuesta correcta: B)

Por qué es correcto: “Lost in the middle” es un fenómeno documentado en LLMs donde la atención es mayor al inicio y final del contexto. Para documentos largos, datos importantes en las páginas intermedias tienen mayor probabilidad de ser ignorados o mal extraídos. La solución es dividir documentos en chunks más pequeños, poner la información más crítica al inicio, o usar estructuras de extracción iterativa.

Por qué las otras opciones son incorrectas:

• A) El system prompt está al inicio del contexto — es la parte menos afectada por “lost in the middle”.
• C) La API no “pierde” tokens — si el documento supera el context window, la llamada falla con un error o requiere truncación explícita.
• D) El número de campos en el schema afecta el espacio en el context window pero no produce “lost in the middle”.

Respuesta correcta: B)

Por qué es correcto: El validation loop efectivo cierra el ciclo de feedback: el error específico (no solo “falló”) se envía al modelo para que corrija su output. “El campo monto contiene ‘$1.200’ pero debe ser un número: 1200” permite al modelo corregir exactamente ese problema. El límite de iteraciones previene loops infinitos, y la condición de salida puede ser éxito o agotar intentos.

Por qué las otras opciones son incorrectas:

• A) Reintentar con el mismo prompt sin feedback produce el mismo error — el modelo no sabe qué corregir.
• C) Escalar inmediatamente ante cualquier error elimina el valor del sistema automatizado — muchos errores son corregibles.
• D) Cambiar el documento de entrada es incorrecto — el documento es el input fijo, no el que debe cambiar.

Respuesta correcta: B)

Por qué es correcto: Extended Thinking activa razonamiento explícito antes de la respuesta final. Agrega valor en problemas donde el razonamiento en pasos intermedios es crucial para la calidad del resultado. Para tareas simples (clasificar un email, extraer un número), agrega latencia y costo sin beneficio de calidad.

Por qué las otras opciones son incorrectas:

• A) Usar Extended Thinking siempre aumenta el costo y latencia sin necesidad para tareas simples.
• C) Extended Thinking está disponible en modelos Claude 3.5 y Claude 3.7 — no es exclusivo de Opus.
• D) Extended Thinking es más lento (genera tokens de razonamiento adicionales), no más rápido.

Respuesta correcta: A)

Por qué es correcto: Prompt caching en la API de Claude se activa agregando cache_control: { type: "ephemeral" } al bloque de contenido que quieres cachear. La primera llamada procesa y almacena el contenido en cache; las llamadas siguientes con el mismo contenido y cache_control pagan un costo reducido (cache read). Ideal para system prompts largos y estáticos.

Por qué las otras opciones son incorrectas:

• B) Guardar localmente no activa el cache de la API — el contenido se envía completo en cada llamada.
• C) La API no acepta contenido comprimido con gzip — requiere texto plano.
• D) Dividir en múltiples mensajes user no activa el cache y rompe la semántica del system prompt.

Respuesta correcta: B)

Por qué es correcto: Temperature controla la aleatoriedad del sampling. Con temperature: 0, el modelo siempre elige el token de mayor probabilidad, produciendo outputs casi deterministas para el mismo input. Es la configuración correcta para tareas donde la consistencia es crítica: si el mismo código se envía dos veces, debe producir el mismo review.

Por qué las otras opciones son incorrectas:

• A) temperature: 0 no desactiva el modelo — lo hace más determinista.
• C) Es lo opuesto — temperatura alta (0.8-1.0) produce mayor variedad y creatividad. Temperature baja produce consistencia.
• D) Temperature no afecta el costo de la API — el costo se determina por tokens de input y output.

Respuesta correcta: B)

Por qué es correcto: Los tres modos tienen semántica diferente y casos de uso claros. "auto" es el default conversacional. "any" garantiza uso de herramienta (útil en pasos del agentic loop donde el agente debe actuar). El modo name específico garantiza un step determinado del flujo (ej: al inicio de una sesión siempre llamar a get_customer primero).

Por qué las otras opciones son incorrectas:

• A) Hay tres modos, no dos — falta el modo de herramienta específica.
• C) "auto" no es siempre el mejor — en agentic loops, "any" o el modo específico dan control más preciso sobre el flujo de ejecución.
• D) "any" obliga a usar alguna herramienta; "auto" permite responder sin herramienta — no son equivalentes.