Mirá: cada pregunta tiene una sola jugada correcta y tres trampas.

Un agente de análisis de documentos descubre que dos fuentes creíbles contienen estadísticas directamente contradictorias para una métrica clave: un informe gubernamental indica un crecimiento del 40%, mientras que un análisis de la industria indica un 12%. Ambas fuentes parecen creíbles, y la discrepancia podría afectar materialmente las conclusiones de la investigación. ¿Cómo debería el agente de análisis de documentos manejar esta situación de la forma más efectiva?

¿Cuál es el enfoque más efectivo?

CorrectaD) Completar el análisis con ambos números, anotar explícitamente el conflicto con atribución de fuente y dejar que el coordinador decida cómo reconciliar los datos antes de pasarlos a síntesis.

Este enfoque preserva la separación de responsabilidades: el agente de análisis completa su trabajo principal sin bloquearse, conserva ambos valores conflictivos con atribución clara y traslada correctamente la reconciliación al coordinador, que tiene un contexto más amplio.

El subagente de búsqueda web devuelve resultados solo para 3 de 5 categorías de fuentes solicitadas (sitios de competencia e informes de la industria tienen éxito, pero archivos de noticias y feeds sociales agotan el tiempo). El subagente de análisis de documentos procesa con éxito todos los documentos provistos. El subagente de síntesis debe producir un resumen a partir de entradas previas de calidad mixta. ¿Qué estrategia de propagación de errores es más efectiva?

¿Qué estrategia de propagación de errores es más efectiva?

CorrectaD) Estructurar la salida de síntesis con anotaciones de cobertura que indiquen qué conclusiones están bien respaldadas y dónde hay vacíos por fuentes no disponibles.

Las anotaciones de cobertura implementan una degradación elegante con transparencia, preservando el valor del trabajo completado mientras propagan la incertidumbre para permitir decisiones informadas sobre la confianza.

Al investigar "adopción de energías renovables", el agente de búsqueda web devuelve estadísticas recientes (2024: 35% de adopción), mientras que el agente de análisis de documentos extrae datos de reportes internos (2022: 18% de adopción). El agente de síntesis marca incorrectamente estas fuentes como contradictorias en lugar de reconocer que los datos muestran crecimiento a lo largo del tiempo.

¿Qué cambio permitiría mejor que el agente de síntesis interprete correctamente esas diferencias temporales?

CorrectaA) Exigir que los subagentes incluyan las fechas de publicación o de recolección de datos en sus salidas estructuradas.

Correcto. El agente de síntesis malinterpreta los datos porque nunca ve las fechas. Hacer que cada dato lleve su propia marca de tiempo en la salida estructurada le permite a la síntesis razonar sobre tendencias en lugar de contradicciones.

Tu herramienta `get_customer` devuelve todas las coincidencias al buscar por nombre. Actualmente, cuando hay múltiples resultados, Claude elige al cliente con el pedido más reciente, pero los datos de producción muestran que esto selecciona la cuenta equivocada el 15% del tiempo para coincidencias ambiguas. ¿Cómo deberías abordar esto?

¿Cómo deberías abordar esto?

CorrectaB) Instruir a Claude para solicitar un identificador adicional (email, teléfono o número de pedido) cuando `get_customer` devuelva múltiples coincidencias antes de tomar cualquier acción específica del cliente.

Pedir al usuario un identificador adicional es la forma más confiable de resolver ambigüedad porque el usuario tiene conocimiento definitivo de su identidad. Un turno conversacional extra es un precio pequeño a pagar para eliminar una tasa de error del 15% causada por elegir la cuenta equivocada.

Las revisiones en producción revelan un manejo inconsistente de la incertidumbre en los reportes finales. A veces los hallazgos contradictorios de los subagentes se sintetizan en una única afirmación contundente (perdiendo matices), mientras que otras veces los reportes se exceden en salvedades con calificativos excesivos (volviéndose poco útiles). Cuando el agente de búsqueda web devuelve "los analistas de la industria estiman un tamaño de mercado de $50B (la metodología varía)" y el agente de análisis de documentos devuelve "un estudio revisado por pares estima 35B (±7B, IC del 95%)", el coordinador o elige uno arbitrariamente o produce afirmaciones vagas como "el mercado podría ser de 35B−50B según diversos factores".

¿Qué enfoque sistemático aborda mejor esto?

CorrectaC) Instruir al agente de síntesis para que estructure los reportes con secciones explícitas que distingan los hallazgos bien establecidos de los controvertidos, preservando las caracterizaciones originales de las fuentes y el contexto metodológico.

Correcto. Una estructura de reporte que conserva el contexto metodológico y separa las afirmaciones consolidadas de las controvertidas es la forma de lograr matices sin excederse en salvedades.

Tu pipeline de extracción procesa contratos que con frecuencia incluyen enmiendas. Cuando un contrato contiene tanto los términos originales como enmiendas posteriores (por ejemplo, la cláusula original especifica "30-day payment terms" mientras que la Enmienda 1 lo cambia a "45 days"), el modelo extrae de forma inconsistente uno u otro valor sin indicar cuál aplica.

¿Cuál es el enfoque más efectivo para mejorar la precisión de extracción en documentos con enmiendas?

CorrectaA) Rediseñar el esquema para que los campos enmendados capturen múltiples valores, cada uno con su ubicación de origen y fecha de entrada en vigor.

Correcto. Las enmiendas son estructuralmente valores versionados. Un esquema con valor + ubicación de origen + fecha de entrada en vigor modela el dominio correctamente y deja de forzar al modelo a elegir uno.

En varios turnos discutiendo estrategia de inversión, un usuario declaró "Tengo una tolerancia al riesgo muy baja" y luego "Quiero maximizar mis retornos." Ahora pregunta: "¿En qué debería invertir?"

¿Qué enfoque garantiza mejor que la recomendación se alinee con la prioridad real del usuario?

CorrectaA) Sacar a la luz la contradicción y pedir al usuario que aclare qué importa más.

Cuando las preferencias del usuario se contradicen directamente, sacar a la luz el conflicto y pedir aclaración es la única forma de garantizar que la recomendación se alinee con la verdadera intención del usuario. Maximizar retornos y tolerancia al riesgo baja son objetivos fundamentalmente incompatibles que requieren una decisión humana.

Un subagente de análisis de documentos falla con frecuencia al procesar archivos PDF: algunos tienen secciones corruptas que disparan excepciones de parseo, otros están protegidos con contraseña, y a veces la biblioteca de parseo se cuelga con archivos grandes. Actualmente, cualquier excepción termina inmediatamente el subagente y devuelve un error al coordinador, que debe decidir si reintentar, omitir o fallar toda la tarea. Esto causa una participación excesiva del coordinador en el manejo rutinario de errores. ¿Qué mejora arquitectónica es más efectiva?

¿Qué mejora es más efectiva?

CorrectaD) Implementar recuperación local en el subagente para fallos transitorios y escalar al coordinador solo los errores que no puede resolver, incluyendo pasos intentados y resultados parciales.

Maneja los errores en el nivel más bajo capaz de resolverlos. La recuperación local reduce la carga del coordinador mientras escala los problemas verdaderamente irrecuperables con contexto completo y progreso parcial.

El subagente de análisis de documentos encuentra un archivo PDF corrupto que no puede parsear. Al diseñar el manejo de errores del sistema, ¿cuál es la forma más efectiva de manejar este fallo?

¿Cuál es el enfoque más efectivo?

CorrectaA) Devolver un error con contexto al agente coordinador, permitiéndole decidir cómo proceder.

Devolver un error con contexto al coordinador es lo más efectivo porque le permite tomar una decisión informada—omitir el archivo, intentar un método de parseo alternativo o notificar al usuario—mientras se mantiene visibilidad sobre el fallo.

El subagente de búsqueda web agota el tiempo de espera mientras investiga un tema complejo. Necesitas diseñar cómo se devuelve la información sobre este fallo al coordinador. ¿Qué enfoque de propagación de errores permite mejor una recuperación inteligente?

¿Qué enfoque de propagación de errores permite mejor una recuperación inteligente?

CorrectaA) Devolver contexto de error estructurado al coordinador, incluyendo el tipo de fallo, la consulta ejecutada, cualquier resultado parcial y posibles enfoques alternativos.

Devolver contexto de error estructurado—incluyendo tipo de fallo, consulta ejecutada, resultados parciales y enfoques alternativos—da al coordinador todo lo necesario para tomar decisiones inteligentes de recuperación (por ejemplo, reintentar con una consulta modificada o continuar con resultados parciales). Preserva el máximo contexto para una toma de decisiones informada a nivel de coordinación.

Durante la investigación, el subagente de búsqueda web consulta tres categorías de fuentes con resultados diferentes: las bases de datos académicas devuelven 15 artículos relevantes, los informes de la industria devuelven "0 resultados" y las bases de datos de patentes devuelven "Tiempo de conexión agotado". Al diseñar la propagación de errores al coordinador, ¿qué enfoque permite las mejores decisiones de recuperación?

¿Qué enfoque permite las mejores decisiones de recuperación?

CorrectaD) Distinguir fallos de acceso (timeout) que requieren una decisión de reintento de resultados vacíos válidos ("0 resultados") que representan consultas exitosas.

Un timeout (fallo de acceso) y "0 resultados" (resultado vacío válido) son resultados semánticamente diferentes que requieren respuestas diferentes. Distinguirlos permite al coordinador reintentar la base de datos de patentes mientras acepta los "0 resultados" de informes de la industria como un hallazgo válido e informativo.

Después de llamar a `get_customer` y `lookup_order`, el agente tiene todos los datos disponibles del sistema pero aún enfrenta incertidumbre. ¿Qué situación es el disparador más justificado para llamar a `escalate_to_human`?

¿Qué situación es la más justificada para escalación?

CorrectaC) Un cliente solicita igualar el precio de un competidor. Tus políticas permiten ajustes de precio para bajadas de precio en tu propio sitio dentro de 14 días, pero no dicen nada sobre precios de competidores. El agente debería escalar para interpretación de política.

Esta es una verdadera laguna de política: las reglas de la empresa cubren bajadas de precio en tu propio sitio pero no abordan la igualación de precios de competidores. El agente no debe inventar política y debería escalar para juicio humano sobre cómo interpretar o extender las reglas existentes.

Estás implementando el bucle del agente para tu agente de soporte. Después de cada llamada a la API de Claude, debes decidir si continuar el bucle (ejecutar las herramientas solicitadas y llamar a Claude de nuevo) o detenerte (presentar la respuesta final al cliente). ¿Qué determina esta decisión?

¿Qué determina esta decisión?

CorrectaA) Verificar el campo `stop_reason` en la respuesta de Claude—continuar si es `tool_use` y detenerse si es `end_turn`.

`stop_reason` es la señal estructurada explícita de Claude para el control del bucle: `tool_use` indica que Claude quiere ejecutar una herramienta y recibir resultados de vuelta, mientras que `end_turn` indica que Claude ha completado su respuesta y el bucle debería terminar.

Tu herramienta de exploración de código base almacena IDs de sesión para permitir que los ingenieros continúen sus investigaciones entre sesiones de trabajo. Un ingeniero dedicó una hora ayer a analizar un módulo de autenticación heredado, acumulando contexto sobre su arquitectura y dependencias. Quiere continuar hoy. El ID de sesión es válido, pero el control de versiones muestra que 3 de los 12 archivos que el agente había leído fueron modificados durante la noche por el merge de un compañero.

¿Qué enfoque equilibra mejor la eficiencia y la precisión?

CorrectaC) Reanudar la sesión e informar al agente qué archivos específicos cambiaron, para un reanálisis dirigido

Correcto. Conserva el costoso contexto que ya construiste, a la vez que le dices al agente exactamente cuáles 3 archivos releer: mínimo desperdicio, máxima precisión.

El subagente de exploración de un ingeniero dedicó 30 minutos a analizar un sistema de pagos heredado, leyendo 47 archivos y documentando flujos de datos. La sesión se interrumpió cuando se cayó la conexión del ingeniero. Mientras tanto, un compañero hizo merge de un PR que renombró dos funciones de utilidad. El ingeniero quiere continuar la misma exploración.

¿Cuál es el enfoque más efectivo?

CorrectaD) Reanudar el subagente desde su transcripción anterior e informarle sobre las funciones renombradas.

Correcto. Conserva la comprensión acumulada y dale un delta dirigido sobre los renombramientos para que pueda actualizar su modelo mental: mínimo desperdicio, máxima precisión.

Estás implementando la lógica de escalamiento para cuando el agente deba llamar a `escalate_to_human`. Tu equipo propone cuatro enfoques distintos para disparar el escalamiento.

¿Qué enfoque identificará de forma más confiable los casos que realmente requieren intervención humana?

CorrectaA) Indicarle al agente que escale cuando el cliente solicite un humano, cuando el problema requiera excepciones de política o cuando el agente no pueda avanzar de forma significativa.

Correcto. Las decisiones de escalamiento son juicios sobre la intención y el progreso, exactamente en lo que los LLM son buenos. Criterios claros en lenguaje natural superan a las reglas rígidas para la cola larga de casos.

Tras investigar una disputa de facturación durante más de 25 turnos, identificaste que los cargos duplicados ocurrieron porque un timeout de la pasarela de pago disparó la lógica de reintento. El reembolso requerido ($847) excede tu límite de autorización de $500. Necesitas llamar a `escalate_to_human`, y el agente humano no tendrá acceso a la transcripción de tu conversación.

¿Qué contexto deberías pasar para permitir una resolución efectiva?

CorrectaB) Un resumen estructurado: ID del cliente, causa raíz, monto del reembolso y acción recomendada.

Correcto. Un traspaso estructurado con identificadores, causa, monto y acción recomendada es lo que un agente humano necesita para retomar el caso al instante sin volver a investigar.

Durante la resolución de una disputa de facturación, tu agente obtiene con éxito la información del cliente vía `get_customer` y los detalles del pedido vía `lookup_order`, pero al intentar llamar a `process_refund`, la herramienta devuelve un error de timeout. El agente tiene suficiente información para explicar los cargos y verificar la elegibilidad del reembolso, pero no puede procesar realmente el reembolso debido a la falla del backend.

¿Qué enfoque equilibra mejor la resolución en el primer contacto con un manejo de errores adecuado?

CorrectaC) Explicar la facturación, confirmar la elegibilidad del reembolso, reconocer el problema del sistema que impide el procesamiento inmediato y ofrecer escalamiento o reintentar más tarde.

Correcto. Entrega el valor parcial que puedas (explicación + elegibilidad), sé honesto sobre la falla y deja que el cliente elija entre el escalamiento humano o un reintento. Degradación elegante clásica.

Un cliente escribe: "Llevo días yendo y viniendo con esta devolución. Solo quiero hablar con alguien que realmente pueda ayudarme." El agente ha confirmado vía `lookup_order` que la devolución es sencilla: dentro de la política y elegible para procesamiento inmediato.

¿Qué debería hacer el agente?

CorrectaA) Reconocer la frustración, informarle que esto se puede resolver ahora y ofrecer completarlo o escalar.

Correcto. Honra el sentimiento, dale la vía de resolución rápida por escrito y preserva su elección. Esa es la jugada de respeto al cliente que a la vez aprovecha la capacidad del agente.

Cuando el agente llama a `lookup_order` y recibe detalles del pedido que muestran que el artículo se compró hace 45 días, ¿cómo determina el bucle agéntico si debe llamar a `process_refund` o a `escalate_to_human` a continuación?

CorrectaC) Los detalles del pedido se agregan a la conversación y el modelo razona sobre qué acción tomar.

Correcto. El bucle agéntico funciona agregando mensajes de `tool_result` a la conversación y dejando que el modelo decida el siguiente paso en cada turno. Así es como se resuelve 45 días → reembolso vs. escalar.

Un cliente envía: "Esto es frustrante. Ya expliqué mi problema dos veces y no se está resolviendo nada. Quiero hablar con una persona real AHORA." El agente aún no ha llamado a ninguna herramienta para investigar su cuenta.

¿Qué debería hacer el agente?

CorrectaA) Reconocer la frustración y hacer una pregunta dirigida para entender el problema específico antes de escalar.

Correcto. El cliente dijo "dos veces", pero aún no tienes contexto. Una pregunta enfocada que reconozca la situación te da una oportunidad de resolución en el primer contacto sin desestimar la frustración ni retrasar un posible traspaso.

Tu agente está manejando una disputa de facturación. Tras llamar a `get_customer` y `lookup_order`, identifica que la disputa involucra un error de precios promocionales que requiere aprobación de un gerente, más allá del nivel de autorización del agente.

¿Cómo debería el flujo de trabajo manejar este escalamiento a mitad del proceso?

CorrectaB) Compilar un traspaso estructurado con los detalles del cliente, la información del pedido y el problema identificado antes de llamar a `escalate_to_human`.

Correcto. Un resumen estructurado (quién, qué pedido, qué problema, por qué excede la autorización) le permite al agente humano retomar al instante. Ese es el patrón de escalamiento a mitad del proceso.

El monitoreo de producción muestra que tu herramienta `search_catalog` falla el 12% del tiempo: el 8% son tiempos de espera de red que tienen éxito al reintentarse, y el 4% son errores de sintaxis de consulta que nunca tienen éxito. Actualmente ambos tipos de error se devuelven de forma idéntica, causando reintentos desperdiciados.

¿Cómo deberías modificar el manejo de errores de la herramienta?

CorrectaC) Implementar reintento automático con retroceso para tiempos de espera de red dentro de la herramienta; devolver errores de sintaxis inmediatamente con detalles de validación de parámetros.

Manejar reintentos a nivel de la herramienta para errores transitorios es la abstracción correcta—la herramienta tiene conocimiento definitivo del tipo de error y puede implementar lógica de reintento determinista sin depender del agente para interpretar un indicador (D) o seguir instrucciones del prompt (A). El retroceso uniforme (B) desperdicia tiempo en errores de sintaxis que nunca tendrán éxito.

Los registros de producción revelan un manejo de errores inconsistente: cuando `lookup_order` falla, el agente a veces reintenta más de 5 veces (un desperdicio cuando el ID del pedido no existe), a veces escala de inmediato (prematuro ante problemas temporales de red) y a veces pide aclaraciones a los usuarios (inapropiado cuando el problema es un error de permisos del backend). La investigación muestra que tu herramienta MCP devuelve respuestas de error uniformes: {"isError": true, "content": [{"type": "text", "text": "Operation failed"}]}. El agente no puede distinguir entre los tipos de error.

¿Cuál es la mejora más efectiva?

CorrectaA) Enriquecer las respuestas de error con metadatos estructurados: incluir errorCategory (transient/validation/permission), un booleano isRetryable y una descripción de qué causó la falla.

Correcto. Dale al agente la información que necesita para tomar la decisión correcta: categoría, capacidad de reintento y una causa legible. Eso reemplaza la adivinanza por una política determinista.

Al implementar tu herramienta MCP `lookup_order`, el backend a veces devuelve errores (por ejemplo, "Order not found" o fallas temporales de la base de datos).

¿Cuál es el patrón correcto para comunicar estos errores de vuelta al agente?

CorrectaB) Devolver el mensaje de error en el contenido del resultado de la herramienta con la bandera isError establecida en true.

Correcto. El patrón diseñado de MCP: pon el texto del error en el campo de contenido y marca isError=true. Claude ve tanto la bandera de falla como un mensaje legible sobre el cual razonar.

Tu herramienta `process_refund` devuelve dos tipos de errores: errores técnicos ("503 Service Unavailable", "Connection timeout") que son transitorios (5% de las llamadas), y errores de negocio ("Order exceeds 30-day return window", "Item already refunded") que son permanentes (12% de las llamadas). El monitoreo muestra que el agente desperdicia entre 3 y 4 turnos reintentando errores de negocio que nunca pueden tener éxito. Actualmente, ambos tipos de error solo devuelven un mensaje de texto plano a Claude.

¿Cuál es la forma más efectiva de reducir los reintentos desperdiciados y a la vez mejorar la calidad de la respuesta hacia el cliente?

CorrectaA) Devolver respuestas de error estructuradas con retryable: false para los errores de negocio y una explicación amigable para el cliente que Claude pueda usar.

Correcto. Una bandera retryable le dice a Claude de forma determinista "no reintentar", y un mensaje listo y amigable para el cliente mejora la respuesta saliente. Resuelve ambos problemas a la vez.

Tu sistema de extracción implementa reintentos automáticos cuando falla la validación. En cada reintento, el error de validación específico se anexa al prompt. Este enfoque de reintento con retroalimentación de error resuelve la mayoría de los fallos en 2-3 intentos.

¿Para qué patrón de fallo serían MENOS efectivos los reintentos adicionales?

CorrectaD) El modelo extrae "et al." para los coautores cuando la lista completa solo existe en un documento externo que no está en la entrada

Correcto. Ninguna cantidad de reintentos le enseña al modelo información que no está en la entrada. El reintento con retroalimentación de error solo corrige errores que el modelo podría haber resuelto a partir de la fuente.

Los usuarios refinan preferencias de playlist a lo largo de múltiples turnos. Dos mensajes después de que un usuario dijo "Me encanta el jazz," Claude pregunta "¿Qué géneros disfrutas?"

¿Cuál es la causa más probable?

CorrectaD) Tu aplicación no está incluyendo mensajes anteriores en el array `messages`.

Claude no tiene memoria del lado del servidor—cada llamada a la API es sin estado. Sin incluir el historial completo de conversación en el array `messages` de cada solicitud, Claude no tiene conocimiento de turnos anteriores. Las bases de datos vectoriales (A) y `session_id` (C) no son parte de la arquitectura de Claude; el desbordamiento de ventana de contexto (B) es imposible para intercambios de dos mensajes.

El agente verifica la identidad del cliente mediante un proceso de varios pasos antes de restablecer contraseñas. Durante las pruebas, notas que después de que el cliente responde la tercera pregunta de verificación, el agente le vuelve a pedir su nombre, como si el intercambio anterior nunca hubiera ocurrido.

¿Cuál es la causa más probable de este comportamiento?

CorrectaC) El historial de la conversación no se está pasando en las solicitudes subsecuentes a la API.

Correcto. La API es sin estado. Cada solicitud debe incluir el arreglo completo de mensajes. Si solo envías el último turno, el modelo no tiene memoria de los anteriores: exactamente el síntoma de "volver a pedir el nombre".

Tras completarse tu lote diario de 10,000 documentos, 300 documentos (3%) fallaron con errores "`context_length_exceeded`". El archivo de resultados identifica cada fallo por `custom_id`.

¿Cuál es el enfoque más rentable para procesar estos fallos?

CorrectaB) Reenviar solo los 300 documentos fallidos tras dividirlos en piezas más pequeñas, y luego combinar las extracciones parciales

Correcto. Es focalizado, y aborda la causa real (entrada demasiado larga). Divide los documentos sobredimensionados, extrae por fragmento y luego fusiona: mínimo de tokens, arregla el modo de fallo específico.

En tu diseño del sistema, le diste al agente de análisis de documentos acceso a una herramienta de propósito general `fetch_url` para que pudiera descargar documentos por URL. Los registros de producción muestran que este agente ahora descarga frecuentemente páginas de resultados de motores de búsqueda para realizar búsquedas web ad hoc—comportamiento que debería enrutarse a través del agente de búsqueda web—causando resultados inconsistentes. ¿Qué corrección es más efectiva?

¿Qué corrección es más efectiva?

CorrectaA) Reemplazar `fetch_url` con una herramienta `load_document` que valide que las URLs apunten a formatos de documento.

Reemplazar una herramienta de propósito general con una herramienta específica para documentos que valida URLs contra formatos de documento corrige la causa raíz limitando la capacidad a nivel de la interfaz. Esto sigue el principio de menor privilegio, haciendo imposible el comportamiento de búsqueda no deseado en lugar de meramente desincentivarlo.

En pruebas, observas que el agente de síntesis a menudo necesita verificar afirmaciones específicas mientras fusiona resultados. Actualmente, cuando se necesita verificación, el agente de síntesis devuelve el control al coordinador, que llama al agente de búsqueda web y luego reinvoca la síntesis con los resultados. Esto añade 2–3 bucles extra por tarea y aumenta la latencia un 40%. Tu evaluación muestra que el 85% de estas verificaciones son comprobaciones simples de hechos (fechas, nombres, estadísticas) y el 15% requiere investigación más profunda. ¿Qué enfoque reduce más efectivamente la sobrecarga preservando la confiabilidad del sistema?

¿Cuál es el enfoque más efectivo?

CorrectaD) Dar al agente de síntesis una herramienta `verify_fact` de alcance limitado para comprobaciones simples, mientras se enrutan las verificaciones complejas a través del coordinador al agente de búsqueda web.

Una herramienta de verificación de hechos de alcance limitado permite al agente de síntesis manejar el 85% de las comprobaciones simples directamente, eliminando la mayoría de los bucles, mientras se preserva la ruta de delegación del coordinador para el 15% de verificaciones complejas. Esto aplica el menor privilegio mientras reduce significativamente la latencia.

Los registros de producción muestran que el agente malinterpreta salidas de tus herramientas MCP: marcas de tiempo Unix de `get_customer`, fechas ISO 8601 de `lookup_order` y códigos de estado numéricos (1=pendiente, 2=enviado). Algunas herramientas son servidores MCP de terceros que no puedes modificar. ¿Qué enfoque para normalización de formato de datos es más mantenible?

¿Qué enfoque es más mantenible?

CorrectaA) Usar un hook PostToolUse para interceptar las salidas de herramientas y aplicar transformaciones de formato antes de que el agente las procese.

Un hook PostToolUse proporciona un punto centralizado y determinista para interceptar y normalizar todas las salidas de herramientas—incluyendo datos de servidores MCP de terceros—antes de que el agente las procese. Es más mantenible porque las transformaciones viven en el código y aplican uniformemente, en lugar de depender de la interpretación del LLM.

El agente de análisis de documentos tiene una única herramienta `analyze_document` que recibe un documento y un parámetro de instrucción en texto libre. Durante la evaluación, solicitudes como "extrae las métricas financieras clave" suelen devolver resúmenes narrativos, mientras que "resume la metodología" a veces devuelve tablas de datos en bruto. El agente de síntesis reporta que el 35% de los resultados de análisis requieren nuevas solicitudes con instrucciones aclaradas.

¿Cuál es la forma más eficaz de mejorar la fiabilidad?

CorrectaA) Dividir la herramienta genérica en herramientas con propósito específico —`extract_data_points`, `summarize_content`, `verify_claim_against_source`— cada una con contratos de entrada/salida definidos.

Correcto. Las instrucciones en texto libre dejan la semántica en la prosa, que el modelo interpreta de forma inconsistente. Las herramientas con propósito específico le dan al modelo un contrato explícito y bien tipado entre el cual elegir.

Tu agente necesita insertar una nueva función auxiliar en medio de un módulo de utilidades de 150 líneas, entre dos funciones existentes. La herramienta Edit falla porque su parámetro `old_string` no puede encontrar texto único con el cual coincidir: el archivo tiene docstrings, nombres de variables y patrones estructurales repetitivos.

¿Cuál es la forma más confiable de completar esta inserción?

CorrectaD) Usar Read para cargar el archivo, agregar la función en la ubicación apropiada y luego usar Write para escribir el archivo actualizado

Correcto. Cuando el contrato de coincidencia única de Edit no puede satisfacerse en un archivo repetitivo, recurre a Read → modificar en memoria en la línea prevista → escribir el archivo completo de vuelta con Write.

El coordinador tiene `AgentDefinitions` configuradas para los cuatro subagentes especializados, cada una con descripciones, prompts y restricciones de herramientas adecuadas. Durante las pruebas, notas que el coordinador razona correctamente sobre cuándo delegar —genera mensajes como "le pediré al agente de búsqueda web que encuentre fuentes sobre este tema"— pero nunca ocurre ninguna ejecución de subagente. El coordinador luego continúa como si la delegación hubiera ocurrido y prosigue con información incompleta. Los registros no muestran errores.

¿Cuál es la causa más probable?

CorrectaC) La configuración de allowedTools del coordinador no incluye "Task", así que, aunque puede razonar sobre la delegación, no puede invocar la herramienta necesaria para generar subagentes.

Correcto. Sin la herramienta Task en allowedTools, el coordinador puede hablar de delegar pero no tiene forma de llamar realmente a un subagente, lo que coincide con el síntoma de 'razona sobre ello, sin ejecución, sin errores'.

Los registros de producción muestran un patrón persistente: solicitudes como "analiza el informe trimestral subido" se enrutan al agente de búsqueda web el 45% del tiempo en lugar de al agente de análisis de documentos. Revisando las definiciones de herramientas, encuentras que el agente de búsqueda web tiene una herramienta `analyze_content` descrita como "analiza contenido y extrae información clave", mientras que el agente de análisis de documentos tiene una herramienta `analyze_document` descrita como "analiza documentos y extrae información clave". ¿Cómo deberías corregir el problema de enrutamiento?

¿Cómo deberías corregir el problema de enrutamiento?

CorrectaB) Renombrar la herramienta de búsqueda web a `extract_web_results` y actualizar su descripción a "procesa y devuelve información obtenida de búsqueda web y URLs".

Renombrar la herramienta de búsqueda web a `extract_web_results` y actualizar su descripción para referenciar explícitamente la búsqueda web y las URLs elimina directamente la causa raíz al eliminar el solapamiento semántico entre los nombres y descripciones de las dos herramientas. Esto hace inequívoco el propósito de cada herramienta, permitiendo al coordinador distinguir confiablemente análisis de documentos de búsqueda web.

Mientras pruebas, notas que el agente a menudo llama a `get_customer` cuando los usuarios preguntan sobre el estado del pedido, aunque `lookup_order` sería más apropiado. ¿Qué deberías verificar primero para abordar este problema?

¿Qué deberías verificar primero?

CorrectaD) Verificar las descripciones de las herramientas para asegurar que diferencien claramente el propósito de cada una.

Las descripciones de herramientas son la entrada principal que el modelo usa para decidir qué herramienta llamar. Cuando un agente elige consistentemente la herramienta equivocada, el primer paso de diagnóstico es verificar que las descripciones de herramientas separen claramente el propósito y los límites de uso de cada una.

Los registros de producción muestran que el agente a menudo llama a `get_customer` cuando los usuarios preguntan sobre pedidos (por ejemplo, "verifica mi pedido #12345") en lugar de llamar a `lookup_order`. Ambas herramientas tienen descripciones mínimas ("Obtiene información del cliente" / "Obtiene detalles del pedido") y aceptan formatos de identificadores de aspecto similar. ¿Cuál es el primer paso más efectivo para mejorar la confiabilidad de selección de herramientas?

¿Cuál es el primer paso más efectivo?

CorrectaD) Expandir la descripción de cada herramienta para incluir formatos de entrada, consultas de ejemplo, casos límite y límites explicando cuándo usarla versus herramientas similares.

Expandir las descripciones de herramientas con formatos de entrada, consultas de ejemplo, casos límite y límites claros corrige directamente la causa raíz—descripciones mínimas que no dan al LLM suficiente información para distinguir herramientas similares. Es un primer paso de bajo esfuerzo y alto impacto que mejora el mecanismo principal que el LLM usa para selección de herramientas.

Después de integrar un servidor MCP local que provee herramientas de análisis de código (`analyze_dependencies`, `find_dead_code`, `calculate_complexity`), verificas que el servidor está saludable y que las herramientas aparecen en la respuesta de tools/list. Sin embargo, observas que el agente usa consistentemente Grep para buscar sentencias de importación en lugar de llamar a `analyze_dependencies`, incluso cuando los usuarios preguntan explícitamente por "dependencias de código". Al examinar las definiciones de las herramientas se observa: MCP: `analyze_dependencies` - "Analiza el grafo de dependencias" Integrada: Grep - "Busca contenido de archivos según un patrón usando expresiones regulares. Devuelve las líneas coincidentes con números de línea y contexto circundante."

¿Cuál es el enfoque más efectivo para mejorar la selección de herramientas MCP por parte del agente?

CorrectaD) Ampliar las descripciones de las herramientas MCP para detallar sus capacidades y resultados; por ejemplo, "Construye un grafo de dependencias que muestra importaciones directas, dependencias transitivas y ciclos."

Correcto. La selección de herramientas se guía por las descripciones que ve el modelo. Una descripción de una línea como 'Analiza el grafo de dependencias' pierde frente a la descripción rica de Grep. Refuerza la descripción de la herramienta MCP.

Después de agregar un servidor MCP con herramientas especializadas de refactorización de código (`extract_function`, `rename_variable`, `inline_function`), notas que el agente sigue usando manipulación básica de texto mediante comandos Write y sed de Bash para las tareas de refactorización. El servidor MCP está conectado y saludable. Al examinar la configuración, encuentras que cada herramienta MCP tiene una descripción mínima como "`extract_function`: extrae una función del código."

¿Cuál es la forma más efectiva de mejorar la adopción de las herramientas de refactorización MCP?

CorrectaD) Mejorar las descripciones de las herramientas MCP para explicar cuándo es preferible cada herramienta frente a la manipulación de texto y aclarar las entradas y salidas esperadas.

Correcto. La selección de herramientas se guía por las descripciones que ve Claude. Cuando las herramientas MCP dicen 'extrae una función del código' y Write/sed vienen con documentación rica, Claude elige Write/sed. Refuerza las descripciones.

Tu pipeline usa una herramienta llamada `extract_metadata` con un esquema JSON para los detalles de los artículos. También has definido herramientas `lookup_citations` y `verify_doi` para enriquecimiento. Durante las pruebas, notas que cuando los usuarios incluyen solicitudes como "extract the metadata and tell me how cited it is", Claude a veces llama primero a `lookup_citations`, que falla porque necesita el DOI que `extract_metadata` proporcionaría.

¿Cuál es la forma más efectiva de asegurar que la extracción de metadatos estructurados ocurra primero?

CorrectaC) Configurar `tool_choice` en {"type": "tool", "name": "`extract_metadata`"} y procesar las solicitudes de enriquecimiento en turnos posteriores tras recibir los metadatos extraídos.

Correcto. `tool_choice`=herramienta-específica fuerza de forma determinista a `extract_metadata` en el primer turno. Luego devuelves el control a 'auto' para que el modelo use el enriquecimiento de citas/DOI con los metadatos en contexto.

Los registros de producción muestran un patrón consistente: cuando los clientes incluyen la palabra "cuenta" en su mensaje (por ejemplo, "Quiero verificar mi cuenta por un pedido que hice ayer"), el agente llama a `get_customer` primero el 78% del tiempo. Cuando los clientes formulan solicitudes similares sin "cuenta" (por ejemplo, "Quiero verificar un pedido que hice ayer"), llama a `lookup_order` primero el 93% del tiempo. Las descripciones de herramientas son claras e inequívocas. ¿Cuál es la causa raíz más probable de esta discrepancia?

¿Cuál es la causa raíz más probable?

CorrectaA) El prompt del sistema contiene instrucciones sensibles a palabras clave que dirigen el comportamiento basadas en términos como "cuenta", creando patrones no intencionados de selección de herramientas.

El patrón sistemático impulsado por palabras clave (78% vs 93%) indica fuertemente lógica de enrutamiento explícita en el prompt del sistema reaccionando a la palabra "cuenta" y dirigiendo al agente hacia herramientas relacionadas con clientes. Como las descripciones de herramientas ya son claras, la discrepancia apunta a instrucciones a nivel de prompt creando dirección de comportamiento no intencionada.

Tu agente maneja solicitudes de un solo problema con 94% de precisión (por ejemplo, "Necesito un reembolso para el pedido #1234"). Pero cuando los clientes incluyen múltiples problemas en un solo mensaje (por ejemplo, "Necesito un reembolso para el pedido #1234 y también quiero actualizar la dirección de envío del pedido #5678"), la precisión de selección de herramientas baja al 58%. El agente generalmente resuelve solo un problema o mezcla parámetros entre solicitudes. ¿Qué enfoque mejora más efectivamente la confiabilidad para solicitudes de múltiples problemas?

¿Qué enfoque es más efectivo?

CorrectaC) Agregar ejemplos few-shot al prompt demostrando razonamiento correcto y secuenciación de herramientas para solicitudes de múltiples problemas.

Los ejemplos few-shot que demuestran razonamiento correcto y secuenciación de herramientas para solicitudes de múltiples problemas son los más efectivos porque el agente ya funciona bien en problemas únicos—lo que necesita es guía sobre el patrón para descomponer y enrutar múltiples problemas y mantener los parámetros separados.

Tus revisiones automatizadas encuentran problemas reales, pero los desarrolladores reportan que la retroalimentación no es accionable. Los hallazgos incluyen frases como "lógica de enrutamiento de tickets compleja" o "potencial puntero nulo" sin especificar qué cambiar exactamente. Cuando agregas instrucciones detalladas como "siempre incluir sugerencias de corrección concretas", el modelo aún produce salida inconsistente—a veces detallada, a veces vaga. ¿Qué técnica de prompting produce más confiablemente retroalimentación consistentemente accionable?

¿Qué técnica de prompting es más confiable?

CorrectaD) Agregar 3–4 ejemplos few-shot que muestren el formato exacto requerido: problema identificado, ubicación en el código, sugerencia de corrección concreta.

Los ejemplos few-shot son la técnica más efectiva para lograr formato de salida consistente cuando las instrucciones por sí solas producen resultados variables. Proporcionar 3–4 ejemplos que muestran la estructura exacta deseada (problema, ubicación, corrección concreta) le da al modelo un patrón concreto a seguir, lo cual es más confiable que instrucciones abstractas.

Le pediste a Claude Code que implementara una función que transforme respuestas de API a un formato interno normalizado. Después de dos iteraciones, la estructura de salida aún no coincide con las expectativas—algunos campos están anidados de forma diferente y las marcas de tiempo están formateadas incorrectamente. Describiste los requisitos en prosa, pero Claude los interpreta de forma diferente cada vez.

¿Qué enfoque es más efectivo para la siguiente iteración?

CorrectaB) Proporcionar 2–3 ejemplos concretos de entrada-salida que muestren la transformación esperada para respuestas de API representativas.

Los ejemplos concretos de entrada-salida eliminan la ambigüedad inherente a las descripciones en prosa al mostrar a Claude los resultados exactos de transformación esperados. Esto aborda directamente la causa raíz—mala interpretación de requisitos textuales—proporcionando patrones inequívocos para anidamiento de campos y formato de marcas de tiempo.

Tu agente logra 55% de resolución en primer contacto, muy por debajo del objetivo del 80%. Los registros muestran que escala casos simples (reemplazos estándar para mercancía dañada con prueba fotográfica) mientras intenta manejar autónomamente situaciones complejas que requieren excepciones de política. ¿Cuál es la forma más efectiva de mejorar la calibración de escalación?

¿Cuál es la forma más efectiva de mejorar la calibración de escalación?

CorrectaC) Agregar criterios de escalación explícitos al prompt del sistema con ejemplos few-shot que muestren cuándo escalar versus resolver autónomamente.

Los criterios de escalación explícitos con ejemplos few-shot abordan directamente la causa raíz—límites de decisión poco claros entre casos simples y complejos. Es la primera intervención más proporcional y efectiva que enseña al agente cuándo escalar y cuándo resolver autónomamente sin infraestructura adicional.

Los registros de producción muestran que el agente a veces elige `get_customer` cuando `lookup_order` sería más apropiado, especialmente para consultas ambiguas como "Necesito ayuda con mi compra reciente". Decides agregar ejemplos few-shot al prompt del sistema para mejorar la selección de herramientas. ¿Qué enfoque aborda más efectivamente el problema?

¿Qué enfoque es más efectivo?

CorrectaC) Agregar 4–6 ejemplos dirigidos a escenarios ambiguos, cada uno con justificación de por qué se eligió una herramienta sobre alternativas plausibles.

Dirigir los ejemplos few-shot a los escenarios ambiguos específicos donde ocurren los errores, con justificación explícita de por qué una herramienta es preferible a las alternativas, enseña al modelo el proceso comparativo de decisión necesario para casos límite. Esto es más efectivo que ejemplos genéricos o reglas declarativas.

Durante las pruebas de QA, Claude sigue las pautas del prompt del sistema durante los primeros 10–15 turnos, pero las respuestas posteriores se desvían. La conversación sigue dentro de los límites de tokens.

¿Cuál es la mejor solución?

CorrectaC) Insertar mensajes de rol de usuario reforzando las pautas en puntos de interrupción de la conversación.

La inyección periódica de recordatorios de comportamiento combate directamente la deriva de instrucciones reestableciendo restricciones a intervalos regulares a medida que se acumula el historial. Mover las pautas al primer mensaje del usuario (A) reduce su autoridad. La validación post-respuesta (D) es correctiva en lugar de preventiva y añade latencia significativa.

Los usuarios reportan aperturas de respuesta repetitivas como "¡Claro!" y "¡Con gusto te ayudo!"

¿Cuál es el enfoque más efectivo?

CorrectaA) Anteponer un mensaje de asistente parcial con una apertura de respuesta directa.

Prellenar la respuesta del asistente con el inicio de una respuesta directa previene los patrones de saludo a nivel de generación—el modelo continúa desde el prellenado en lugar de generar nuevas frases de apertura. Las instrucciones del prompt del sistema (D) pueden ayudar pero son menos confiables. El post-procesamiento (C) es una solución frágil. La temperatura (B) controla la aleatoriedad, no patrones de frases específicos.

Tu esquema incluye un campo skills: string[]. El monitoreo en producción revela tres problemas de consistencia: (1) frases compuestas como "Python and SQL" a veces se mantienen como una sola entrada y a veces se dividen; (2) ocasionalmente aparecen en las extracciones habilidades implícitas pero no declaradas; (3) documentos similares producen longitudes de array muy dispares (5-10 vs 40+ entradas). Tu prompt actualmente dice "Extract all skills mentioned."

¿Cuál es la mejora más efectiva?

CorrectaA) Agregar ejemplos few-shot que demuestren el manejo de frases compuestas, criterios explícitos de mención y la granularidad apropiada de las entradas.

Correcto. Los tres problemas tienen que ver con cómo interpreta el modelo qué cuenta como 'una habilidad'. Los ejemplos few-shot enseñan el patrón de forma concreta: dividir o no, mencionado o inferido, granularidad apropiada.

Tras implementar el uso de herramientas con definiciones de esquema estrictas, se eliminan los errores de sintaxis JSON, pero el 5% de las extracciones aún tienen JSON válido con arrays vacíos o valores null en campos obligatorios como citations y methodology. Una revisión puntual revela que los documentos fuente contienen esta información, pero en formatos variados: citas en línea vs. bibliografías, secciones de metodología vs. detalles incrustados en las introducciones.

¿Cuál es la forma más efectiva de abordar estos fallos?

CorrectaD) Agregar ejemplos few-shot que demuestren extracciones de documentos con estructuras variadas, mostrando cómo identificar citas en distintos formatos y localizar detalles de metodología a través de distintos tipos de secciones.

Correcto. El modo de fallo es que el modelo no reconoce los formatos variados. Ejemplos concretos a lo largo de la distribución de formatos elevan directamente el recall sobre ese 5%.

Tu sistema de extracción analiza descripciones de productos de e-commerce para extraer especificaciones como dimensiones, peso y materiales en JSON. A pesar de tener un esquema bien definido, el modelo extrae de forma inconsistente el campo "materials": a veces devuelve "cotton blend", otras veces "Cotton/Polyester mix", y ocasionalmente omite el campo cuando la información del material está claramente presente en la fuente.

¿Cuál es la forma más efectiva de mejorar la consistencia de la extracción?

CorrectaD) Agregar ejemplos few-shot que muestren 2-3 pares completos de entrada-salida con formatos estandarizados de descripción de materiales

Correcto. Los ejemplos few-shot demuestran el formato canónico exacto que quieres ('cotton/polyester' como lista normalizada), y también elevan el recall sobre la información de material que se estaba omitiendo.

Tu tutor de IA tiene un prompt del sistema de 2,800 tokens que define metodología de enseñanza y reglas de adaptación. Después de 12 turnos, el asistente comienza a ignorar los niveles de competencia.

¿Cuál es la corrección más efectiva?

CorrectaB) Reemplazar reglas verbosas con ejemplos few-shot que demuestren adaptación por nivel de competencia.

Un prompt del sistema de 2,800 tokens con reglas declarativas es vulnerable a la deriva porque las reglas abstractas requieren que el modelo razone sobre ellas en cada turno. Reemplazar reglas verbosas con ejemplos few-shot concretos que demuestran la adaptación correcta por nivel de competencia da al modelo patrones de comportamiento claros para seguir—esto se cumple más confiablemente a lo largo de muchos turnos que las instrucciones abstractas.

Tu revisión automatizada analiza comentarios y docstrings. El prompt actual instruye a Claude a "verificar que los comentarios sean precisos y estén actualizados". Los hallazgos a menudo señalan patrones aceptables (marcadores TODO, descripciones simples) mientras se pierden comentarios que describen comportamiento que el código ya no implementa. ¿Qué cambio aborda la causa raíz de este análisis inconsistente?

¿Qué cambio aborda la causa raíz?

CorrectaD) Especificar criterios explícitos: marcar comentarios solo cuando el comportamiento que afirman contradice el comportamiento real del código.

Los criterios explícitos—marcar comentarios solo cuando el comportamiento afirmado contradice el comportamiento real del código—abordan directamente la causa raíz reemplazando una instrucción vaga con una definición precisa de qué constituye un problema. Esto reduce los falsos positivos sobre patrones aceptables y los descuidos de comentarios verdaderamente engañosos.

Tu sistema automatizado de revisión de código muestra calificaciones de severidad inconsistentes—problemas similares como riesgos de puntero nulo se califican como "críticos" en algunos PRs pero solo "medio" en otros. Las encuestas a desarrolladores muestran creciente desconfianza—muchos comienzan a descartar hallazgos sin leer porque "la mitad están mal". Las categorías con altos falsos positivos erosionan la confianza en categorías precisas. ¿Qué enfoque restaura mejor la confianza del desarrollador mientras mejora el sistema?

¿Qué enfoque restaura mejor la confianza del desarrollador?

CorrectaA) Deshabilitar temporalmente categorías con altos falsos positivos (estilo, nomenclatura, documentación) y mantener solo categorías de alta precisión mientras se mejoran los prompts.

Deshabilitar temporalmente las categorías con altos falsos positivos detiene inmediatamente la erosión de confianza al eliminar hallazgos ruidosos que hacen que los desarrolladores descarten todo, mientras se preserva el valor de las categorías de alta precisión como seguridad y corrección. También crea espacio para mejorar los prompts de las categorías problemáticas antes de rehabilitarlas.

Tu revisión automatizada de código promedia 15 hallazgos por pull request, y los desarrolladores reportan una tasa de falsos positivos del 40%. El cuello de botella es el tiempo de investigación: los desarrolladores deben hacer clic en cada hallazgo para leer la justificación de Claude antes de decidir si corregir o descartar. Tu CLAUDE.md ya contiene reglas exhaustivas para patrones aceptables, y los stakeholders rechazaron cualquier enfoque que filtre hallazgos antes de que los vean los desarrolladores. ¿Qué cambio aborda mejor el tiempo de investigación?

¿Qué cambio aborda mejor el tiempo de investigación?

CorrectaA) Requerir que Claude incluya su justificación y estimación de confianza directamente en cada hallazgo.

Incluir la justificación y la confianza directamente en cada hallazgo reduce el tiempo de investigación al permitir que los desarrolladores triien rápidamente sin abrir cada hallazgo. Satisface la restricción de "no filtrar" porque todos los hallazgos permanecen visibles mientras se acelera la toma de decisiones del desarrollador.

El análisis de tu revisión automatizada de código muestra grandes diferencias en las tasas de falsos positivos por categoría de hallazgo: hallazgos de seguridad/corrección tienen 8% de falsos positivos, hallazgos de rendimiento 18%, hallazgos de estilo/nomenclatura 52% y hallazgos de documentación 48%. Las encuestas a desarrolladores muestran creciente desconfianza—muchos comienzan a descartar hallazgos sin leer porque "la mitad están mal". Las categorías con altos falsos positivos erosionan la confianza en categorías precisas. ¿Qué enfoque restaura mejor la confianza del desarrollador mientras mejora el sistema?

¿Qué enfoque restaura mejor la confianza del desarrollador?

CorrectaA) Deshabilitar temporalmente categorías con altos falsos positivos (estilo, nomenclatura, documentación) y mantener solo categorías de alta precisión mientras se mejoran los prompts.

Deshabilitar temporalmente las categorías con altos falsos positivos detiene inmediatamente la erosión de confianza al eliminar hallazgos ruidosos que hacen que los desarrolladores descarten todo, mientras se preserva el valor de las categorías de alta precisión como seguridad y corrección. También crea espacio para mejorar los prompts de las categorías problemáticas antes de rehabilitarlas.

Las métricas de producción muestran que al resolver disputas complejas de facturación o devoluciones de múltiples pedidos, los puntajes de satisfacción del cliente son 15% más bajos que para casos simples—incluso cuando la resolución es técnicamente correcta. El análisis de causa raíz muestra que el agente proporciona soluciones precisas pero explica la justificación de forma inconsistente: a veces omitiendo detalles de política relevantes, a veces perdiendo información de cronograma o próximos pasos. Las brechas de contexto específicas varían caso por caso. Quieres mejorar la calidad de las soluciones sin agregar supervisión humana. ¿Qué enfoque es más efectivo?

¿Qué enfoque es más efectivo?

CorrectaA) Agregar una etapa de autocrítica donde el agente evalúe un borrador de respuesta para completitud—asegurando que resuelva el problema del cliente, incluya contexto relevante y anticipe preguntas de seguimiento.

Una etapa de autocrítica (el patrón evaluador-optimizador) aborda directamente la inconsistencia en completitud de explicación al forzar al agente a evaluar su propio borrador contra criterios concretos—como contexto de política, cronogramas y próximos pasos—antes de presentarlo. Esto detecta brechas específicas de caso sin supervisión humana.

Un usuario está ampliando el sistema de investigación más allá de su único agente de búsqueda web añadiendo fuentes de datos especializadas. Agrega un agente de API financiera que devuelve JSON estructurado con ingresos, márgenes y tasas de crecimiento; un agente de monitoreo de noticias que devuelve resúmenes en prosa de desarrollos recientes; y un agente de análisis de patentes que devuelve listas estructuradas de áreas tecnológicas. El agente de síntesis combina todo esto en informes ejecutivos. Actualmente, convierte todo en viñetas, lo que hace que las comparaciones financieras pierdan claridad tabular y que los resúmenes de noticias pierdan su fluidez narrativa.

¿Qué cambio mejoraría más la calidad de los informes?

CorrectaC) Actualizar el agente de síntesis para que renderice cada tipo de contenido de forma apropiada: los datos financieros como tablas, las noticias como prosa.

Correcto. Los informes ejecutivos necesitan un renderizado mixto: tablas para los números, prosa para la narrativa. Pedirle a la síntesis que preserve el formato nativo de cada entrada es la abstracción correcta.

Tu sistema ha operado con revisión humana del 100% durante 3 meses. El análisis muestra que las extracciones con confianza del modelo >90% tienen un 97% de precisión en general. Para reducir la carga de trabajo de los revisores, planeas automatizar las extracciones de alta confianza. Antes de desplegar, ¿qué paso de validación es el más crítico?

CorrectaA) Analizar la precisión por tipo de documento y por campo para verificar que las extracciones de alta confianza se desempeñan de forma consistente en todos los segmentos, no solo en el agregado.

Correcto. La precisión agregada oculta fallos por segmento: un tipo de documento podría estar en 70% mientras otros están en 99%. Enrutar automáticamente solo por el número global arriesga errores sistémicos en los segmentos débiles.

Tu pipeline de extracción procesa menús de restaurantes y debe producir un JSON estructurado con campos para nombres de platos, descripciones, precios y etiquetas dietéticas. Algunos menús usan formatos inconsistentes: precios como "$12" vs "12.00", información dietética como íconos vs texto.

¿Cuál es el enfoque más confiable?

CorrectaD) Definir un esquema de salida estricto e incluir reglas de normalización de formato en tu prompt.

Correcto. Un esquema estricto + reglas de normalización explícitas ('precios como decimal con dos posiciones', 'dietético como etiquetas enumeradas') permite al modelo extraer y normalizar en una sola pasada.

Tu sistema extrae metadatos de eventos (fecha, ubicación, organizador, `attendee_count`) de artículos de noticias usando un esquema JSON con todos los campos anulables. Durante la evaluación, observas que el modelo genera con frecuencia valores plausibles pero incorrectos para campos no mencionados en el artículo; por ejemplo, produciendo "500" para `attendee_count` cuando la fuente no contiene información de asistencia.

¿Cuál es la forma más efectiva de reducir estas extracciones falsas?

CorrectaB) Agregar instrucciones al prompt para devolver null en cualquier campo cuya información no esté directamente declarada en la fuente.

Correcto. Los campos ya son anulables; el modelo solo necesita una instrucción explícita de preferir null sobre una conjetura plausible. Este es el arreglo estándar para la alucinación consciente del esquema.

Tu extracción usa el uso de herramientas con un esquema JSON donde `property_type` se define como un enum: ['house', 'apartment', 'condo', 'townhouse']. Tras el despliegue, el 8% de las extracciones falla la validación del esquema. La investigación revela que los listados mencionan muchos tipos de propiedad poco comunes —"studio", "loft", "duplex", "mobile home", "tiny house", "converted warehouse"— y siguen apareciendo nuevos tipos con regularidad.

¿Cuál es la solución más efectiva a largo plazo?

CorrectaB) Agregar un valor "other" a tu enum con un campo string `property_type_detail` separado para las especificaciones cuando se selecciona "other".

Correcto. Mantiene el enum sólido para los casos comunes (joins posteriores limpios) a la vez que ofrece una válvula de escape bien tipada que preserva el detalle. Estable a largo plazo.

Tu componente de revisión de código es iterativo: Claude analiza el archivo modificado, luego puede solicitar archivos relacionados (imports, clases base, pruebas) mediante llamadas a herramientas para entender el contexto antes de proporcionar la retroalimentación final. Tu aplicación define una herramienta que permite a Claude solicitar contenido de archivos; Claude llama la herramienta, obtiene resultados y continúa el análisis. Estás evaluando procesamiento en lote para reducir el costo de la API. ¿Cuál es la principal limitación técnica al considerar procesamiento en lote para este flujo?

¿Cuál es la principal limitación técnica?

CorrectaB) El modelo asíncrono no puede ejecutar herramientas a mitad de solicitud y devolver resultados para que Claude continúe el análisis.

Un modelo asíncrono "fire-and-forget" de Batch API no tiene mecanismo para interceptar una llamada a herramienta durante una solicitud, ejecutar la herramienta y devolver resultados para que Claude continúe el análisis. Esto es fundamentalmente incompatible con flujos iterativos de llamadas a herramientas que requieren múltiples rondas de solicitud/respuesta de herramientas dentro de una sola interacción lógica.

Tu sistema CI/CD ejecuta tres análisis basados en Claude: (1) verificaciones rápidas de estilo en cada PR que bloquean el merge hasta completarse, (2) auditorías exhaustivas de seguridad semanales de toda la base de código, y (3) generación nocturna de casos de prueba para módulos cambiados recientemente. La Message Batches API ofrece 50% de ahorro pero el procesamiento puede tardar hasta 24 horas. Quieres optimizar el costo de la API manteniendo una experiencia de desarrollador aceptable. ¿Qué combinación empareja correctamente cada tarea con un enfoque de API?

¿Qué combinación es correcta?

CorrectaB) Usar llamadas síncronas para verificaciones de estilo del PR; usar la Message Batches API para auditorías de seguridad semanales y generación nocturna de pruebas.

Las verificaciones de estilo del PR bloquean a los desarrolladores y requieren respuestas inmediatas vía llamadas síncronas, mientras que las auditorías de seguridad semanales y la generación nocturna de pruebas son tareas programadas con plazos flexibles que pueden tolerar hasta una ventana de lote de 24 horas—capturando 50% de ahorro para ambas.

Tu pipeline de CI incluye dos modos de revisión de código basados en Claude: un hook de pre-merge-commit que bloquea el merge del PR hasta completarse, y un "análisis profundo" que se ejecuta de noche, sondea la finalización del lote y publica sugerencias detalladas en el PR. Quieres reducir el costo de la API usando la Message Batches API, que ofrece 50% de ahorro pero requiere sondeo y puede tardar hasta 24 horas. ¿Qué modo debería usar procesamiento en lote?

¿Qué modo debería usar procesamiento en lote?

CorrectaB) Solo el análisis profundo.

El análisis profundo es un candidato ideal para procesamiento en lote porque ya se ejecuta de noche, tolera retraso y usa un modelo de sondeo antes de publicar resultados—coincidiendo con la arquitectura asíncrona basada en sondeo de la Message Batches API mientras captura 50% de ahorro.

Tu equipo quiere reducir los costos de API para análisis automatizado. Actualmente, las llamadas síncronas a Claude soportan dos flujos: (1) una verificación pre-merge bloqueante que debe completarse antes de que los desarrolladores puedan hacer merge, y (2) un informe de deuda técnica generado durante la noche para revisión a la mañana siguiente. Tu gerente propone mover ambos a la Message Batches API para ahorrar 50%. ¿Cómo deberías evaluar esta propuesta?

¿Cómo deberías evaluar esta propuesta?

CorrectaC) Usar procesamiento en lote solo para los informes de deuda técnica; mantener las llamadas síncronas para las verificaciones pre-merge.

El procesamiento de la Message Batches API puede tardar hasta 24 horas sin SLA de latencia, lo cual es aceptable para informes nocturnos de deuda técnica pero inaceptable para verificaciones pre-merge bloqueantes donde los desarrolladores esperan. Esto empareja cada flujo con la API correcta según los requisitos de latencia.

Tu sistema de extracción procesa dos tipos de documentos: reportes mensuales estándar (que se archivan tras procesarse) y reportes de excepciones urgentes (que deben disparar alertas de negocio dentro de los 30 minutos de su recepción). Ambos usan el mismo esquema JSON. Quieres minimizar los costos de API cumpliendo a la vez los requisitos de latencia.

¿Cómo deberías diseñar la arquitectura del pipeline de procesamiento?

CorrectaD) Enrutar los reportes estándar a la `Batch API` para ahorrar 50% en costos, y enrutar los reportes de excepciones urgentes a la Messages API en tiempo real.

Correcto. Ajusta el perfil de latencia a la urgencia del documento: batch para el grueso (barato), tiempo real para las excepciones sensibles a la latencia (rápido). Minimiza el costo cumpliendo el SLA.

Los documentos llegan de forma continua a lo largo del horario laboral y requieren que se extraigan datos estructurados. Para reducir costos, quieres usar la `Message Batches API` (50% de descuento, ventana de procesamiento de hasta 24 horas). Tu SLA especifica que los resultados de extracción deben estar disponibles dentro de las 30 horas de la llegada del documento con una confiabilidad del 99.9%.

¿Qué estrategia de lotes es la más apropiada?

CorrectaC) Enviar lotes cada 4 horas que contengan los documentos de esa ventana

Correcto. Espera máxima de 4 horas + SLO de batch de hasta 24 horas = 28 horas en el peor caso, dejando un colchón de 2 horas bajo el SLA de 30 horas para absorber la variabilidad del batch y alcanzar el 99.9%.

Tu pipeline de investigación multiagente se cayó después de procesar 12 de 28 documentos. El agente de búsqueda web había identificado fuentes relevantes, el agente de análisis de documentos había completado parcialmente la extracción, y el sintetizador había comenzado a identificar patrones. Necesitas reanudar el procesamiento sin repetir trabajo ni perder la fidelidad de los hallazgos previos.

¿Qué enfoque de gestión de estado equilibra mejor la fidelidad de la información con la eficiencia de contexto al restaurar el estado de los agentes?

CorrectaC) Que cada agente persista un reporte estructurado en una ubicación conocida. Al reanudar, el coordinador carga los reportes e inyecta el estado relevante en los prompts de los agentes.

Correcto. Los reportes estructurados por agente conservan la fidelidad (los hallazgos, con esquema), permiten que el coordinador mantenga el control de la orquestación y mantienen enfocado el contexto de cada subagente. Es el patrón de coordinador + artefacto compacto.

El monitoreo en producción muestra que las consultas de seguimiento como "resume lo que aprendimos sobre las tendencias del mercado" tardan sistemáticamente más de 40 segundos. La investigación revela que el coordinador genera el subagente de síntesis para cada solicitud de resumen, pasándole más de 80K tokens de hallazgos acumulados. El coordinador ya tiene esos hallazgos en su contexto por haber orquestado la investigación.

¿Cuál es la forma más eficaz de mejorar el tiempo de respuesta para estos resúmenes de seguimiento?

CorrectaB) Que el coordinador maneje las solicitudes de resumen sencillas directamente usando su contexto existente, reservando la generación de subagentes para los análisis complejos.

Correcto. Si el coordinador ya tiene los hallazgos, generar un subagente para reingerir 80K tokens es puro sobrecosto. Deja que el coordinador responda él mismo los seguimientos simples.

Un ingeniero usó el agente ayer para analizar un módulo de autenticación heredado e identificó dos enfoques de refactorización distintos: extraer un microservicio frente a refactorizar en el sitio. Hoy quiere explorar ambos enfoques en profundidad —haciendo que el agente proponga cambios de código específicos para cada uno— antes de decidir cuál implementar.

¿Cuál es la forma más efectiva de estructurar esta exploración?

CorrectaD) Usar `fork_session` para crear dos ramas a partir del análisis de ayer, explorando un enfoque en cada bifurcación.

Correcto. Bifurcar desde la sesión de ayer le da a cada enfoque su propio contexto independiente a partir de la misma base de análisis: limpio, paralelo y sin contaminación.

Un ingeniero le pide a tu agente que identifique las rutas de código sin pruebas en un módulo heredado de procesamiento de pagos que abarca 45 archivos. Tras leer los primeros 8 archivos fuente, las respuestas del agente se vuelven notablemente menos precisas: olvida patrones de código discutidos previamente y aún no ha localizado todos los archivos de prueba ni rastreado los flujos críticos de pago.

¿Cuál es el enfoque más efectivo para completar esta investigación?

CorrectaB) Generar subagentes para investigar preguntas específicas (por ejemplo, "encuentra todos los archivos de prueba para el procesamiento de pagos", "rastrea las dependencias del flujo de reembolso") mientras el agente principal coordina los hallazgos y preserva la comprensión de alto nivel.

Correcto. Delega investigaciones bien acotadas a subagentes con contexto fresco, mientras el agente principal conserva la visión arquitectónica general. Este es el patrón para escalar la exploración más allá de una sola ventana de contexto.

Tu agente ha analizado un módulo de servicio complejo: leyó 23 archivos fuente, rastreó flujos de solicitudes e identificó patrones de manejo de errores. Un desarrollador quiere comparar dos estrategias de pruebas antes de comprometerse con una: pruebas de extremo a extremo con servicios externos simulados frente a pruebas de snapshot que capturan las salidas esperadas. Necesita desarrollar ambos enfoques de forma independiente para evaluar las compensaciones.

¿Cómo deberías gestionar las sesiones?

CorrectaB) Reanudar la sesión de análisis con `fork_session` habilitado, creando una rama separada para cada estrategia de pruebas.

Correcto. Bifurcar le da a cada estrategia su propio contexto independiente a partir de la base de análisis exacta: sin contaminación cruzada, sin reanálisis.

Un cliente regresa 4 horas después de su sesión inicial sobre la misma disputa de facturación. La sesión anterior de 32 turnos contiene resultados de `lookup_order` que muestran "Status: PENDING, Expected resolution: 24-48 hours." En las pruebas, observas que al reanudar sesiones con resultados de herramienta obsoletos, el agente a menudo hace referencia a los datos desactualizados en sus respuestas (por ejemplo, "Veo que tu reembolso aún se está procesando") incluso después de que llamadas frescas a la herramienta devuelven información distinta.

¿Qué enfoque maneja de forma más confiable a los clientes que regresan?

CorrectaB) Iniciar una nueva sesión, inyectar un resumen estructurado de la interacción previa (tipo de problema, acciones tomadas, estado de resolución) y luego hacer llamadas frescas a las herramientas antes de interactuar.

Correcto. Una sesión limpia con un resumen mantiene la continuidad narrativa y a la vez garantiza que el agente no razone sobre resultados de herramienta obsoletos.

Tu equipo creó un skill `/analyze-codebase` que realiza análisis profundo de código—escaneo de dependencias, conteos de cobertura de pruebas y métricas de calidad de código. Después de ejecutar el comando, los miembros del equipo reportan que Claude se vuelve menos receptivo en la sesión y pierde el contexto de la tarea original.

¿Cómo lo corriges más efectivamente manteniendo capacidades completas de análisis?

CorrectaA) Agregar `context: fork` en el frontmatter del skill para ejecutar el análisis en un contexto de subagente aislado.

`context: fork` ejecuta el análisis en un contexto de subagente aislado para que la salida grande no contamine la ventana de contexto de la sesión principal y Claude no pierda el rastro de la tarea original. Preserva la capacidad completa de análisis manteniendo la sesión principal receptiva.

Creas un skill personalizado `/explore-alternatives` que tu equipo usa para hacer brainstorming y evaluar enfoques de implementación antes de elegir uno. Los desarrolladores reportan que después de ejecutar el skill, las respuestas posteriores de Claude son influenciadas por la discusión de alternativas—a veces referenciando enfoques rechazados o reteniendo contexto de exploración que interfiere con la implementación real.

¿Cómo deberías configurar este skill más efectivamente?

CorrectaB) Agregar `context: fork` en el frontmatter del skill.

`context: fork` ejecuta el skill en un contexto de subagente aislado para que las discusiones de exploración no contaminen el historial de conversación principal. Esto previene que enfoques rechazados y el contexto de brainstorming influyan en el trabajo de implementación posterior.

Tu equipo usa Claude Code para generar sugerencias de código, pero notas un patrón: problemas no obvios—optimizaciones de rendimiento que rompen casos límite, limpiezas que cambian inesperadamente el comportamiento—solo se detectan cuando otro miembro del equipo revisa el PR. El razonamiento de Claude durante la generación muestra que consideró estos casos pero concluyó que su enfoque era correcto. ¿Qué enfoque aborda directamente la causa raíz de esta limitación de auto-revisión?

¿Qué enfoque aborda directamente la causa raíz?

CorrectaA) Ejecutar una segunda instancia independiente de Claude Code para revisar los cambios sin acceso al razonamiento del generador.

Una segunda instancia independiente de Claude Code sin acceso al razonamiento del generador aborda directamente la causa raíz al evitar el sesgo de confirmación. Esta perspectiva de "ojos frescos" refleja la revisión por pares humana, donde otro revisor detecta problemas que el autor racionalizó.

Tu revisión automatizada genera sugerencias de casos de prueba para cada PR. Revisando un PR que agrega seguimiento de finalización de cursos, Claude sugiere 10 casos de prueba, pero la retroalimentación del desarrollador muestra que 6 duplican escenarios ya cubiertos por la suite de pruebas existente. ¿Qué cambio reduce más efectivamente las sugerencias duplicadas?

¿Qué cambio es más efectivo?

CorrectaA) Incluir el archivo de pruebas existente en el contexto para que Claude pueda determinar qué escenarios ya están cubiertos.

Incluir el archivo de pruebas existente corrige la causa raíz de la duplicación: Claude solo puede evitar sugerir escenarios ya cubiertos si sabe qué pruebas ya existen. Esto le da a Claude la información necesaria para proponer pruebas genuinamente nuevas y valiosas.

Después de que una revisión automatizada inicial identifica 12 hallazgos, un desarrollador hace commits nuevos para abordar problemas. Al volver a ejecutar la revisión se producen 8 hallazgos, pero los desarrolladores reportan que 5 duplican comentarios anteriores sobre código que ya fue corregido en los nuevos commits. ¿Cuál es la forma más efectiva de eliminar esta retroalimentación redundante manteniendo la exhaustividad?

¿Cuál es la forma más efectiva de eliminar la retroalimentación redundante?

CorrectaD) Incluir los hallazgos de revisión anteriores en el contexto e instruir a Claude para reportar solo problemas nuevos o aún sin resolver.

Incluir los hallazgos de revisión previos en el contexto permite a Claude distinguir problemas nuevos de los ya abordados en commits recientes. Esto preserva la exhaustividad de la revisión mientras usa el razonamiento de Claude para evitar retroalimentación redundante sobre código corregido.

El monitoreo de producción muestra calidad de síntesis inconsistente. Cuando los resultados agregados son ~75K tokens, el agente de síntesis cita confiablemente información de los primeros 15K tokens (titulares/fragmentos de búsqueda web) y los últimos 10K tokens (conclusiones del análisis de documentos), pero a menudo se pierde hallazgos críticos en los 50K tokens del medio—incluso cuando responden directamente a la pregunta de investigación. ¿Cómo deberías reestructurar la entrada agregada?

¿Cómo deberías reestructurar la entrada agregada?

CorrectaC) Colocar un resumen de hallazgos clave al inicio de la entrada agregada y organizar los resultados detallados con encabezados de sección explícitos para una navegación más fácil.

Poner un resumen de hallazgos clave al inicio aprovecha los efectos de primacía para que la información crítica esté en la posición procesada más confiablemente. Agregar encabezados de sección explícitos en todo el documento ayuda al modelo a navegar y atender el contenido del medio, mitigando directamente el fenómeno "perdido en el medio".

En pruebas, la salida combinada del agente de búsqueda web (85K tokens incluyendo contenido de página) y del agente de análisis de documentos (70K tokens incluyendo cadenas de pensamiento) totaliza 155K tokens, pero el agente de síntesis funciona mejor con entradas por debajo de 50K tokens. ¿Qué solución es más efectiva?

¿Qué solución es más efectiva?

CorrectaA) Modificar los agentes previos para que devuelvan datos estructurados (hechos clave, citas, puntuaciones de relevancia) en lugar de contenido y razonamiento verbosos.

Modificar los agentes previos para que devuelvan datos estructurados corrige la causa raíz reduciendo el volumen de tokens en la fuente mientras preserva la información esencial. Evita pasar contenido de página voluminoso y trazas de razonamiento que inflan tokens sin mejorar el paso de síntesis.

Estás agregando wrappers de manejo de errores alrededor de llamadas a APIs externas en una base de código de 120 archivos. El trabajo tiene tres fases: (1) descubrir todos los sitios de llamada y patrones, (2) diseñar colaborativamente el enfoque de manejo de errores, y (3) implementar wrappers de forma consistente. En la Fase 1, Claude genera salida grande listando cientos de sitios de llamada con contexto, llenando rápidamente la ventana de contexto antes de que termine el descubrimiento.

¿Qué enfoque es más efectivo para completar la tarea manteniendo la consistencia de implementación?

CorrectaA) Usar un subagente Explore para la Fase 1 para aislar la salida verbosa de descubrimiento y devolver un resumen, luego continuar las Fases 2–3 en la conversación principal.

Un subagente Explore aísla la salida verbosa de descubrimiento en un contexto separado y devuelve solo un resumen conciso a la conversación principal. Esto preserva la ventana de contexto principal para las fases de diseño colaborativo e implementación consistente donde el contexto retenido es más valioso.

Los registros de producción muestran un patrón: los clientes referencian montos específicos (por ejemplo, "el descuento del 15% que mencioné"), pero el agente responde con valores incorrectos. La investigación muestra que estos detalles fueron mencionados 20+ turnos atrás y condensados en resúmenes vagos como "se discutieron precios promocionales". ¿Qué corrección es más efectiva?

¿Qué corrección es más efectiva?

CorrectaC) Extraer hechos transaccionales (montos, fechas, números de pedido) en un bloque persistente de "hechos del caso" incluido en cada prompt fuera del historial resumido.

La resumición pierde inherentemente detalles precisos. Extraer hechos transaccionales en un bloque estructurado de "hechos del caso" fuera del historial resumido preserva información crítica para que esté disponible confiablemente en cada prompt independientemente de cuántos turnos hayan sido resumidos.

Después de una sesión de cocina de 40 minutos, la conversación alcanza 78,000 tokens. El historial incluye alergias, escalado de recetas, términos de cocina aclarados y discusión general. Debes reducir tokens preservando información importante.

¿Qué enfoque equilibra mejor la preservación con la reducción de tokens?

CorrectaC) Extraer datos estructurados críticos (alergias, cantidades, preferencias), resumir la discusión general y mantener los intercambios recientes literalmente.

El enfoque híbrido preserva la información de mayor valor al menor costo. Los hechos críticos como alergias y cantidades de recetas se extraen en un bloque estructurado compacto (previniendo la pérdida de precisión que ocurre durante la resumición), la discusión general se resume, y los intercambios recientes se mantienen literalmente para la coherencia conversacional. Las opciones A y B arriesgan perder información dietética crítica; D es excesiva para una sola sesión de cocina.

Los usuarios reportan que durante conversaciones extendidas el asistente pierde el rastro de temas y preferencias anteriores. Tu implementación actual conserva solo los últimos 25 pares de mensajes.

¿Cuál es la solución más efectiva?

CorrectaA) Enfoque híbrido: resumir mensajes más antiguos mientras se mantienen los recientes literalmente.

El enfoque híbrido aborda ambas dimensiones del problema: retener contexto reciente exacto (crítico para la coherencia conversacional) mientras se mantiene una representación comprimida de preferencias anteriores. Aumentar la ventana (C) simplemente retrasa el mismo problema. La búsqueda vectorial (B) puede perder contexto importante que no es semánticamente similar a la consulta actual.

Los usuarios reportan que la latencia aumenta y los costos suben cuando las conversaciones superan los 50 turnos.

¿Cuál es la causa principal?

CorrectaA) Todo el historial de conversación se incluye con cada solicitud a la API.

La API de Claude es completamente sin estado—cada solicitud debe incluir el historial completo de conversación en el array `messages`. A medida que las conversaciones crecen, cada solicitud lleva más tokens, lo que aumenta directamente tanto la latencia de procesamiento como el costo. El modelo no mantiene ningún estado interno entre llamadas (D es falso).

Después de tres meses de sesiones semanales, el historial de conversación crece a 85,000 tokens. Cuando un usuario pregunta "¿Qué concluimos sobre el tema del aislamiento?", el asistente da respuestas genéricas en lugar de referenciar discusiones anteriores.

¿Cuál es el enfoque más efectivo?

CorrectaC) Embeddings semánticos con recuperación de intercambios relevantes.

La búsqueda semántica sobre el historial de conversación es el único enfoque que escala a tres meses de discusión mientras puede sacar a la luz intercambios relevantes específicos a demanda. El truncamiento deslizante (A) descartaría la mayoría del historial. La resumición progresiva (B) comprime las discusiones en abstracciones que pierden las conclusiones específicas que los usuarios buscan.

Tu asistente usa un prompt del sistema con persona de contratista. Los turnos iniciales siguen las reglas, pero para el turno 7 el asistente da consejos genéricos. La longitud de conversación es solo 2,500 tokens.

¿Cuál es la causa más probable?

CorrectaC) Las respuestas acumuladas del asistente diluyen la influencia del prompt del sistema.

A medida que las respuestas del asistente se acumulan en el historial de conversación, la proporción de texto que refleja las restricciones de comportamiento del prompt del sistema disminuye en relación al cuerpo creciente de contenido generado por el asistente. El modelo cada vez más sigue el patrón de sus propias salidas anteriores en lugar de las instrucciones del prompt del sistema, compounding la deriva incluso en longitudes de token cortas.

Durante las pruebas, observas que en sesiones de exploración prolongadas (más de 30 minutos), el agente comienza a dar respuestas inconsistentes sobre la estructura de código que discutió antes. Los ingenieros reportan tener que repetir contexto sobre módulos que ya habían explorado.

¿Cuál es el enfoque más efectivo para abordar esto?

CorrectaA) Hacer que el agente mantenga un archivo de notas (scratchpad) que registre los hallazgos clave, y consultarlo para las preguntas posteriores.

Correcto. Un scratchpad traslada los hallazgos a un almacenamiento duradero que el agente puede releer cuando lo necesite, dándole una 'memoria' estable independiente de qué tan saturada esté la ventana de contexto.

Tu agente ha dedicado 25 minutos a explorar el subsistema de renderizado de un motor de juego: leyendo código de shaders, gestión de búferes y lógica de sincronización de fotogramas. Un ingeniero ahora le pide que entienda cómo se integra el motor de física con el renderizado para las superposiciones de depuración de colisiones. Notas que las respuestas recientes hacen referencia a "patrones de renderizado típicos" en lugar de las clases específicas VulkanPipeline y FrameGraph que descubrió antes.

¿Cuál es el enfoque más efectivo?

CorrectaC) Resumir los hallazgos clave del renderizado y luego generar un subagente para la exploración de la física con ese resumen en su contexto inicial.

Correcto. Condensa lo que has aprendido sobre el renderizado en un resumen compacto, y luego dale a un subagente nuevo ese resumen más la tarea de física: preservas la señal importante y escapas del contexto degradado.

Un ingeniero le pide al agente que entienda cómo funciona la capa de caché antes de agregar un nuevo disparador de invalidación de caché. Tras las búsquedas iniciales con Grep, el agente ha identificado que la lógica de caché abarca 15 archivos, incluyendo decoradores, middleware y clases de servicio (~8000 líneas en total).

¿Cuál es el siguiente paso más efectivo para construir comprensión a la vez que se gestionan las restricciones de contexto?

CorrectaB) Analizar las importaciones y jerarquías de clases para identificar la clase base de caché, leer ese archivo para entender la interfaz y luego rastrear las implementaciones específicas de invalidación.

Correcto. Empieza desde la raíz arquitectónica (la interfaz) y luego navega solo las implementaciones específicas que importan para la invalidación: lectura enfocada, bajo costo de contexto.

Un cliente plantea tres problemas separados durante una sesión: una consulta de reembolso (turnos 1-15), una pregunta sobre suscripción (turnos 16-30) y una actualización del método de pago (turnos 31-45). En el turno 48, el cliente pregunta "¿Qué pasó con mi reembolso?" La conversación se está acercando a los límites de contexto.

¿Qué estrategia mantiene mejor la capacidad del agente para atender todos los problemas a lo largo de la sesión?

CorrectaC) Resumir los turnos anteriores en una descripción narrativa, preservando el historial completo de mensajes solo para el problema activo.

Correcto. El resumen progresivo comprime los temas resueltos y estables mientras mantiene el hilo activo textualmente: el patrón clásico para conversaciones largas con múltiples problemas cerca del límite de contexto.

Tu agente ha llamado a `lookup_order` varias veces mientras investiga las solicitudes de devolución de un cliente. Cada respuesta incluye más de 40 campos (artículos, detalles de envío, información de pago, historial de estado). Las salidas de las herramientas ahora representan la mayor parte del contexto de la conversación. El cliente menciona dos pedidos más que quiere discutir.

¿Cuál es el enfoque más efectivo antes de hacer búsquedas adicionales?

CorrectaA) Extraer solo los campos relevantes para la devolución (artículos, fecha de compra, ventana de devolución, estado) de cada respuesta de pedido existente, eliminando los detalles verbosos.

Correcto. Conserva los campos que importan para la tarea y descarta el resto. Esto aborda directamente el problema de saturación del contexto antes de agregar dos búsquedas más.

Tu script de pipeline ejecuta `claude "Analyze this pull request for security issues"`, pero el job se cuelga indefinidamente. Los registros muestran que Claude Code está esperando entrada interactiva. ¿Cuál es el enfoque correcto para ejecutar Claude Code en un pipeline automatizado?

¿Cuál es el enfoque correcto?

CorrectaB) Agregar la flag `-p`: `claude -p "Analyze this pull request for security issues"`.

La flag `-p` (o `--print`) es la forma documentada de ejecutar Claude Code de forma no interactiva. Procesa el prompt, imprime el resultado a stdout y sale sin esperar entrada del usuario—ideal para pipelines de CI/CD.

Tu archivo CLAUDE.md ha crecido a más de 400 líneas conteniendo estándares de codificación, convenciones de pruebas, una checklist detallada de revisión de PRs, instrucciones de despliegue y procedimientos de migración de base de datos. Quieres que Claude siga siempre los estándares de codificación y convenciones de pruebas, pero que aplique la guía de revisión de PR, despliegue y migración solo cuando esté haciendo esas tareas.

¿Qué enfoque de reestructuración es más efectivo?

CorrectaD) Mantener los estándares universales en CLAUDE.md y crear Skills para guía específica de flujo (revisión de PR, despliegue, migraciones) con palabras clave de activación.

El contenido de CLAUDE.md se carga en cada sesión, asegurando que los estándares de codificación y las convenciones de pruebas siempre apliquen, mientras que las Skills se invocan bajo demanda cuando Claude detecta palabras clave de activación—ideal para guía específica de flujo como revisión de PR, despliegue y migraciones.

Tu equipo usa un skill `/commit` en `.claude/skills/commit/SKILL.md`. Un desarrollador quiere personalizarlo para su flujo personal (formato de mensaje de commit diferente, verificaciones extra) sin afectar a sus compañeros.

¿Qué recomiendas?

CorrectaC) Crear una versión personal en `~/.claude/skills/commit/SKILL.md` con el mismo nombre.

Los skills personales tienen precedencia sobre los skills del proyecto con el mismo nombre. Un skill personal en `~/.claude/skills/commit/SKILL.md` sobreescribirá el skill del proyecto, permitiendo al desarrollador personalizar su flujo mientras mantiene el nombre familiar `/commit` para uso personal. Este enfoque es mejor que la opción A porque preserva el nombre del comando original, mejorando el flujo del desarrollador sin afectar a los compañeros.

Tu equipo ha usado Claude Code durante meses. Recientemente, tres desarrolladores reportan que Claude sigue la guía "siempre incluir manejo de errores exhaustivo", pero un cuarto desarrollador que acaba de unirse dice que Claude no la sigue. Los cuatro trabajan en el mismo repo y tienen código actualizado.

¿Cuál es la causa más probable y la corrección?

CorrectaA) La guía vive en los archivos `~/.claude/CLAUDE.md` a nivel de usuario de los desarrolladores originales, no en el `.claude/CLAUDE.md` del proyecto. Mover la instrucción al archivo a nivel de proyecto para que todos los miembros del equipo la reciban.

Si la guía se agregó solo a las configuraciones a nivel de usuario de los desarrolladores originales y no al `.claude/CLAUDE.md` a nivel de proyecto, los nuevos miembros del equipo no la recibirán. Moverla a la configuración a nivel de proyecto asegura que todos los miembros del equipo actuales y futuros reciban automáticamente la guía.

Encuentras que incluir 2–3 ejemplos completos de implementación de endpoints como contexto mejora significativamente la consistencia al generar nuevos endpoints de API. Sin embargo, este contexto solo es útil al crear nuevos endpoints—no al depurar, revisar código u otros trabajos en el directorio API.

¿Qué enfoque de configuración es más efectivo?

CorrectaD) Crear un skill que referencie los ejemplos de endpoints y contenga instrucciones de seguimiento de patrones, invocado bajo demanda mediante un comando slash.

Un skill invocado bajo demanda carga el contexto de ejemplos solo al generar nuevos endpoints, no durante tareas no relacionadas como depuración o revisión. Esto mantiene el contexto principal limpio mientras preserva la generación de alta calidad cuando se necesita.

Tu equipo creó un skill `/migration` que genera archivos de migración de base de datos. Toma el nombre de la migración vía `$ARGUMENTS`. En producción observas tres problemas: (1) los desarrolladores a menudo ejecutan el skill sin argumentos, causando archivos mal nombrados, (2) el skill a veces usa detalles de esquema de base de datos de conversaciones previas no relacionadas, y (3) un desarrollador ejecutó accidentalmente limpieza de pruebas destructiva cuando el skill tenía amplio acceso a herramientas.

¿Qué enfoque de configuración corrige los tres problemas?

CorrectaB) Agregar `argument-hint` en el frontmatter para solicitar parámetros requeridos, usar `context: fork` para aislar la ejecución y restringir `allowed-tools` a operaciones de escritura de archivos.

Esto usa tres características de configuración separadas para abordar cada problema: `argument-hint` mejora la entrada de argumentos y reduce los argumentos faltantes, `context: fork` previene fugas de contexto de conversaciones previas, y `allowed-tools` limita el skill a operaciones seguras de escritura de archivos, previniendo acciones destructivas.

Tu base de código contiene áreas con diferentes convenciones de codificación: los componentes React usan estilo funcional con hooks, los manejadores de API usan async/await con manejo específico de errores, y los modelos de base de datos siguen el patrón repository. Los archivos de prueba están distribuidos por la base de código junto al código bajo prueba (por ejemplo, `Button.test.tsx` junto a `Button.tsx`), y quieres que todas las pruebas sigan las mismas convenciones independientemente de la ubicación.

¿Cuál es la forma más soportada de asegurar que Claude aplique automáticamente las convenciones correctas al generar código?

CorrectaD) Crear archivos de regla bajo `.claude/rules/` con frontmatter YAML especificando patrones glob para aplicar convenciones condicionalmente según rutas de archivo.

Los archivos `.claude/rules/` con frontmatter YAML y patrones glob (por ejemplo, `**/*.test.tsx`, `src/api/**/*.ts`) habilitan aplicación de convenciones determinista basada en rutas independiente de la estructura de directorios. Este es el enfoque más soportado para patrones transversales como archivos de prueba distribuidos.

Quieres crear un comando slash personalizado `/review` que ejecute la checklist estándar de revisión de código de tu equipo. Debe estar disponible para cada desarrollador cuando clone o actualice el repositorio.

¿Dónde deberías crear el archivo del comando?

CorrectaB) En el repositorio del proyecto bajo `.claude/commands/`.

Poner los comandos slash personalizados bajo `.claude/commands/` dentro del repositorio del proyecto asegura que estén versionados y automáticamente disponibles para cada desarrollador que clone o actualice el repo. Esta es la ubicación prevista para comandos personalizados a nivel de proyecto en Claude Code.

El CLAUDE.md de tu equipo creció más allá de 500 líneas mezclando convenciones de TypeScript, guía de pruebas, patrones de API y procedimientos de despliegue. Los desarrolladores encuentran difícil ubicar y actualizar las secciones correctas.

¿Qué enfoque soporta Claude Code para organizar las instrucciones a nivel de proyecto en módulos temáticos enfocados?

CorrectaB) Crear archivos Markdown separados en `.claude/rules/`, cada uno cubriendo un tema (por ejemplo, `testing.md`, `api-conventions.md`).

Claude Code soporta un directorio `.claude/rules/` donde puedes crear archivos Markdown separados para guía temática (por ejemplo, `testing.md`, `api-conventions.md`), permitiendo a los equipos organizar grandes conjuntos de instrucciones en módulos enfocados y mantenibles.

Tu equipo quiere agregar un servidor MCP de GitHub para buscar PRs y verificar el estado de CI vía Claude Code. Cada uno de los seis desarrolladores tiene su propio token de acceso personal de GitHub. Quieres herramientas consistentes en el equipo sin commitear credenciales al control de versiones.

¿Qué enfoque de configuración es más efectivo?

CorrectaC) Agregar el servidor al `.mcp.json` del proyecto usando sustitución de variables de entorno (`${GITHUB_TOKEN}`) para autenticación y documentar la variable de entorno requerida en el README del proyecto.

Un `.mcp.json` de proyecto con sustitución de variables de entorno es idiomático: proporciona una única fuente de verdad versionada para la configuración MCP mientras permite a cada desarrollador suministrar credenciales vía variables de entorno. Documentar la variable hace fácil el onboarding sin commitear secretos.

Una ingeniera usó `Claude Code` ayer para investigar los flujos de autenticación en un monolito heredado, acumulando un contexto considerable a lo largo de una sesión de 2 horas. Hoy quiere continuar esa investigación específica. Desde entonces ha trabajado en otros tres códigos base y sabe que la sesión se llamaba "auth-deep-dive".

¿Cómo debería retomarla?

CorrectaD) Usar `--resume` auth-deep-dive para cargar esa sesión específica por nombre

Correcto. `--resume` con el nombre de la sesión está diseñado exactamente para esto: elegir una sesión previa específica entre muchas, por el nombre que le diste.

Tu asistente debe mantener un tono entusiasta, explicar su razonamiento y hacer preguntas aclaratorias. ¿Dónde deben definirse estas pautas de comportamiento?

¿Dónde deben definirse estas pautas de comportamiento?

CorrectaB) En el prompt del sistema.

El prompt del sistema está específicamente diseñado para restricciones y pautas de comportamiento persistentes que aplican a lo largo de toda la conversación. Anteponer a cada mensaje del usuario (A) es sobrecarga redundante. El primer mensaje del asistente (C) es poco confiable porque el modelo puede desviarse de sus propias declaraciones anteriores. Las variables de entorno (D) no tienen efecto en el comportamiento del modelo.

Un webhook notifica a tu sistema que el paquete de un usuario ha sido enviado mientras el usuario está chateando activamente. Quieres que el asistente incorpore esto naturalmente en la siguiente respuesta.

¿Cuál es el mejor enfoque?

CorrectaD) Anteponer la actualización de estado como prefijo al siguiente mensaje del usuario.

Prefijar la actualización de estado al siguiente mensaje del usuario inyecta contexto en tiempo real en un límite de conversación natural sin interrumpir el flujo. Modificar el prompt del sistema (A) requiere reconstruir la sesión. Un mensaje sintético de usuario (B) puede romper el flujo natural del diálogo. Forzar una llamada de herramienta en cada turno (C) es costoso cuando los eventos son raros.

El agente de síntesis recibe hallazgos resumidos de los agentes de búsqueda web y de análisis de documentos, y luego pasa un resumen consolidado al generador de reportes. Durante las pruebas, descubres que los reportes generados hacen afirmaciones factuales sin las citas adecuadas: el generador de reportes no puede atribuir las afirmaciones a sus fuentes originales porque esos metadatos se perdieron durante los pasos de resumen.

¿Cuál es el enfoque más eficaz para asegurar una atribución de fuentes adecuada en los reportes finales?

CorrectaA) Que cada agente emita datos estructurados que separen los resúmenes de contenido de los metadatos de fuente (URLs, nombres de documentos, números de página).

Correcto. El contenido estructurado + los metadatos de fuente separados preservan el mapeo de extremo a extremo, de modo que el generador de reportes recibe tanto lo que se dijo como de dónde provino.

En producción, los reportes finales suelen contener afirmaciones sin la atribución de fuentes adecuada. La investigación muestra que, si bien los agentes de búsqueda web y de análisis de documentos adjuntan correctamente las citas a sus salidas, el agente de síntesis pierde el rastro de qué fuentes respaldan qué conclusiones al combinar los hallazgos.

¿Cuál es el cambio arquitectónico más eficaz?

CorrectaB) Exigir que todos los subagentes emitan mapeos estructurados de afirmación-fuente que el agente de síntesis deba preservar y fusionar al combinar hallazgos de múltiples fuentes.

Correcto. Los mapeos explícitos de afirmación-fuente son una salida de primera clase que el agente de síntesis puede fusionar de forma determinista: no se pierde ninguna atribución durante el resumen.

El cumplimiento normativo exige que los reembolsos que superen los $500 deben escalar automáticamente a un agente humano; esta regla no puede dejarse a discreción del modelo. A pesar de instrucciones claras en el prompt del sistema, los registros de producción muestran que el agente ocasionalmente procesa reembolsos de alto valor directamente (tasa de falla del 3%).

¿Cómo deberías lograr un cumplimiento garantizado?

CorrectaC) Implementar un hook para interceptar las llamadas a herramientas; cuando el monto a procesar por reembolso supere los $500, bloquearla e invocar el escalamiento humano.

Correcto. Las reglas de grado de cumplimiento pertenecen fuera del modelo: un hook determinista sobre la llamada a la herramienta se dispara de forma garantizada cada vez, independientemente del comportamiento del modelo.

Los registros de producción muestran que en el 12% de los casos tu agente omite `get_customer` y llama a `lookup_order` directamente usando solo el nombre proporcionado por el cliente, a veces llevando a cuentas mal identificadas y reembolsos incorrectos. ¿Qué cambio corrige más efectivamente este problema de confiabilidad?

¿Qué cambio es más efectivo?

CorrectaC) Agregar una precondición programática que bloquee `lookup_order` y `process_refund` hasta que `get_customer` devuelva un identificador de cliente verificado.

Una precondición programática proporciona una garantía determinista de que se sigue la secuenciación requerida. Es el enfoque más efectivo porque elimina la posibilidad de saltarse la verificación, independientemente del comportamiento del LLM.

Tu herramienta `remove_team_member` usa un parámetro `dry_run: boolean` para previsualizar impactos antes de ejecutar. El monitoreo de producción muestra que el agente omite el paso de previsualización y llama directamente con `dry_run=false`. Necesitas garantizar que cada eliminación esté precedida por una previsualización que el usuario confirme explícitamente.

¿Cuál es el enfoque más confiable?

CorrectaD) Reemplazar con dos herramientas: `preview_remove_member` devuelve detalles del impacto y un token de confirmación de uso único; `execute_remove_member` requiere ese token, vinculando la ejecución a la previsualización.

El enfoque de vinculación por token hace arquitectónicamente imposible ejecutar sin una previsualización previa. La herramienta de ejecución literalmente requiere un token que solo la herramienta de previsualización puede generar. Es el único enfoque que aplica la restricción a nivel de código, no dependiendo del cumplimiento de instrucciones por el LLM (C), heurísticas de tiempo (A) o infraestructura de orquestación (B).

Tu pipeline de CI ejecuta el CLI de Claude Code (en modo `--print`) usando CLAUDE.md para proporcionar contexto del proyecto a la revisión de código, y los desarrolladores generalmente encuentran las revisiones sustantivas. Sin embargo, reportan que integrar los hallazgos al flujo es difícil—Claude produce párrafos narrativos que deben copiarse manualmente a los comentarios del PR. El equipo quiere publicar automáticamente cada hallazgo como un comentario inline separado del PR en el lugar relevante del código, lo que requiere datos estructurados con ruta de archivo, número de línea, nivel de severidad y corrección sugerida. ¿Qué enfoque es más efectivo?

¿Cuál es el enfoque más efectivo?

CorrectaB) Usar las flags del CLI `--output-format json` y `--json-schema` para imponer hallazgos estructurados, luego parsear la salida para publicar comentarios inline a través de la API de GitHub.

Usar `--output-format json` con `--json-schema` impone salida estructurada a nivel del CLI, garantizando JSON bien formado con los campos requeridos (ruta de archivo, número de línea, severidad, corrección sugerida) que pueden parsearse y publicarse confiablemente como comentarios inline del PR a través de la API de GitHub. Aprovecha capacidades incorporadas del CLI diseñadas específicamente para salida estructurada.

Tu pipeline de extracción procesa facturas y extrae líneas de detalle, subtotales, montos de impuestos y totales generales. Durante la evaluación, descubres que en el 18% de las extracciones la suma de los montos de las líneas extraídas no coincide con el total general extraído, a veces por errores de OCR en el documento fuente, a veces por errores de extracción del modelo. Los sistemas contables posteriores rechazan los registros con totales no coincidentes.

¿Cuál es el enfoque más efectivo para mejorar la confiabilidad de la extracción?

CorrectaA) Agregar un campo "`calculated_total`" donde el modelo sume las líneas extraídas, junto con un campo "`stated_total`". Marcar los registros para revisión humana cuando los valores difieran.

Correcto. Capturar ambos valores convierte la discrepancia en una señal de primera clase: detectas los errores de OCR y los de extracción de manera uniforme, y puedes enrutar solo el 18% no coincidente a humanos.

Tras el despliegue, descubres que el 12% de las extracciones contiene errores semánticos que pasan la validación del esquema JSON (por ejemplo, una duración como "30 minutes" colocada incorrectamente en un campo de cantidad de ingrediente). Los revisores humanos tienen capacidad para revisar solo el 20% de las extracciones.

¿Qué enfoque asigna de forma más efectiva la atención de los revisores?

CorrectaA) Hacer que el modelo produzca puntajes de confianza a nivel de campo, y luego calibrar los umbrales de revisión usando un conjunto de validación etiquetado.

Correcto. La confianza a nivel de campo te permite enrutar a humanos el 20% de baja confianza, que es donde se concentra el 12% de errores semánticos. La calibración hace que la elección del umbral se base en datos.

El coordinador entrega instrucciones detalladas paso a paso al subagente de búsqueda web, especificando consultas de búsqueda exactas, prioridades de fuentes y filtros de fecha. El monitoreo en producción revela tres problemas: (1) el subagente reporta "resultados insuficientes" en lugar de intentar enfoques alternativos cuando las búsquedas preespecificadas fallan, (2) la calidad de la investigación cae para temas emergentes que no coinciden con los patrones esperados, y (3) el subagente rara vez saca a la luz fuentes tangenciales valiosas.

¿Cuál es la forma más eficaz de mejorar la adaptabilidad del subagente?

CorrectaD) Especificar los objetivos de investigación y los criterios de calidad (amplitud de cobertura, diversidad de fuentes, actualidad) en lugar de pasos procedimentales, dejando que el subagente determine su estrategia de búsqueda.

Correcto. Delega la intención y los estándares de calidad, no los procedimientos. Así el subagente puede elegir consultas, seguir tangentes prometedoras y recuperarse de callejones sin salida por su cuenta.

Un ingeniero le pide al agente que encuentre a todos los llamadores de una función antes de eliminarla. La función está definida en una biblioteca central, pero también se expone a través de módulos envoltorio que la renombran para usos específicos del dominio (por ejemplo, calculateTax en la biblioteca se convierte en computeOrderTax en el módulo de pedidos).

¿Qué estrategia de exploración identificará de forma más confiable a todos los llamadores?

CorrectaA) Leer la biblioteca y los módulos envoltorio para identificar todos los nombres expuestos de la función, y luego hacer Grep de cada nombre en todo el código base.

Correcto. Hay que enumerar todos los nombres bajo los que se expone la función; de lo contrario, los envoltorios renombrados ocultan llamadores. Lee los módulos relevantes, reúne todos los alias y luego haz grep de cada uno.

Necesitas agregar Slack como un nuevo canal de notificación. La base de código existente tiene patrones claros y establecidos para canales de email, SMS y push. Sin embargo, la API de Slack ofrece enfoques de integración fundamentalmente diferentes—webhooks entrantes (simple, unidireccional), bot tokens (soportan confirmación de entrega y control programático) o Slack Apps (eventos bidireccionales, requiere aprobación del workspace). Tu tarea dice "agregar soporte para Slack" sin especificar el método de integración ni requerir características avanzadas como seguimiento de entrega.

¿Cómo deberías abordar esta tarea?

CorrectaB) Cambiar a modo de planificación para explorar opciones de integración e implicaciones arquitectónicas, luego presentar una recomendación antes de implementar.

La integración con Slack tiene múltiples enfoques válidos con implicaciones arquitectónicas significativamente diferentes, y los requisitos son ambiguos. El modo de planificación te permite evaluar trade-offs entre webhooks, bot tokens y Slack Apps y alinearte sobre un enfoque antes de la implementación.

Estás encargado de reestructurar la aplicación monolítica de tu equipo en microservicios. Esto impacta cambios en docenas de archivos y requiere decisiones sobre límites de servicio y dependencias entre módulos.

¿Qué enfoque deberías elegir?

CorrectaA) Cambiar a modo de planificación para explorar la base de código, entender dependencias y diseñar el enfoque de implementación antes de hacer cambios.

El modo de planificación es la estrategia correcta para reestructuración arquitectónica compleja como dividir un monolito: permite exploración segura y decisiones informadas sobre límites antes de comprometerse a cambios potencialmente costosos en muchos archivos.

Los usuarios frecuentemente envían solicitudes como "Reserva un lugar para la fiesta." El asistente hace 4+ preguntas aclaratorias, causando un 35% de abandono.

¿Qué enfoque mejora mejor el equilibrio?

CorrectaC) Declarar suposiciones explícitamente y proceder invitando correcciones.

Declarar suposiciones explícitamente y proceder le da al usuario una respuesta inmediata y útil mientras preserva su capacidad de corregir suposiciones incorrectas. Los valores predeterminados ocultos (A) dejan al usuario sin saber qué se asumió. Una lista de preguntas compuesta (B) sigue demandando esfuerzo inicial del usuario. Un formulario estructurado (D) agrega más fricción, no menos.

Los usuarios hacen solicitudes vagas como "¿Puedes ayudar con el informe?" El asistente responde preguntando múltiples preguntas (¿qué informe? ¿qué ayuda? ¿cuál es el plazo?), causando un 40% de abandono.

¿Cuál es la mejor solución?

CorrectaA) Hacer suposiciones razonables, declararlas explícitamente y ofrecer ajustes.

Proceder con suposiciones declaradas razonables elimina el intercambio de ida y vuelta por completo mientras mantiene al usuario informado y en control. Las interpretaciones silenciosas predefinidas (C) confunden a los usuarios cuando la respuesta no coincide con su intención. Un límite de una pregunta (D) sigue requiriendo turnos de ida y vuelta. Un modelo de clasificación más pequeño (B) agrega latencia y complejidad de infraestructura sin resolver el problema central de UX.

Los agentes de búsqueda web y de análisis de documentos completaron sus tareas y devolvieron resultados al coordinador. ¿Cuál es el siguiente paso para crear un informe de investigación integrado?

¿Cuál es el siguiente paso más apropiado?

CorrectaC) El coordinador pasa ambos conjuntos de resultados al agente de síntesis para una integración unificada.

En una arquitectura coordinador–subagente, el coordinador reenvía ambos conjuntos de resultados al agente de síntesis para una integración centralizada, preservando el control y asegurando una fusión de alta calidad.

Después de ejecutar el sistema sobre "el impacto de la IA en las industrias creativas", observas que cada subagente se completa con éxito: el agente de búsqueda web encuentra artículos relevantes, el agente de análisis de documentos los resume correctamente y el agente de síntesis produce un texto coherente. Sin embargo, los informes finales solo cubren artes visuales y omiten por completo música, literatura y cine. En los registros del coordinador, ves que descompuso el tema en tres subtareas: "IA en arte digital", "IA en diseño gráfico" e "IA en fotografía". ¿Cuál es la causa raíz más probable?

¿Cuál es la causa raíz más probable?

CorrectaC) La descomposición de tareas del coordinador es demasiado estrecha, asignando a los subagentes trabajo que no cubre todas las áreas relevantes.

El coordinador descompuso un tema amplio solo en subtareas de artes visuales, omitiendo por completo música, literatura y cine. Como los subagentes ejecutaron sus asignaciones correctamente, la descomposición estrecha es la causa raíz evidente.

Un colega propone que el agente de análisis de documentos envíe sus resultados directamente al agente de síntesis, evitando al coordinador. ¿Cuál es la principal ventaja de mantener al coordinador como hub central de toda la comunicación entre subagentes?

¿Cuál es la principal ventaja de mantener al coordinador como hub central?

CorrectaA) El coordinador puede observar todas las interacciones, manejar errores uniformemente y decidir qué información debe recibir cada subagente.

El patrón coordinador proporciona visibilidad centralizada de todas las interacciones, manejo uniforme de errores en todo el sistema y control fino sobre qué información recibe cada subagente—estas son las ventajas principales de una topología de comunicación en estrella.

Mientras investigas un tema amplio, observas que el agente de búsqueda web y el agente de análisis de documentos investigan los mismos subtemas, llevando a una duplicación sustancial en sus salidas. El uso de tokens casi se duplica sin un aumento proporcional en la amplitud o profundidad de la investigación. ¿Cuál es la forma más efectiva de abordar esto?

¿Cuál es la forma más efectiva de abordar esto?

CorrectaB) El coordinador particiona explícitamente el espacio de investigación antes de delegar, asignando a cada agente subtemas o tipos de fuente distintos.

Hacer que el coordinador particione explícitamente el espacio de investigación antes de delegar es lo más efectivo porque aborda la causa raíz—límites de tarea poco claros—antes de que comience cualquier trabajo. Preserva el paralelismo mientras previene esfuerzo duplicado y tokens desperdiciados.

Los registros de producción muestran que para solicitudes simples como "reembolso para el pedido #1234", tu agente resuelve el problema en 3–4 llamadas a herramientas con 91% de éxito. Pero para solicitudes complejas como "Me cobraron dos veces, mi descuento no se aplicó y quiero cancelar", el agente promedia 12+ llamadas a herramientas con solo 54% de éxito—a menudo investigando problemas secuencialmente y obteniendo datos de cliente redundantes para cada uno. ¿Qué cambio mejora más efectivamente el manejo de solicitudes complejas?

¿Qué cambio es más efectivo?

CorrectaC) Descomponer la solicitud en problemas separados, luego investigar cada uno en paralelo usando contexto de cliente compartido antes de sintetizar una resolución final.

Descomponer en problemas separados e investigar en paralelo con contexto de cliente compartido corrige ambos problemas clave: elimina la recuperación de datos redundante reutilizando el contexto compartido entre problemas y reduce los bucles totales de llamadas a herramientas paralelizando la investigación antes de sintetizar una sola resolución.

Las métricas de producción muestran que tu agente promedia 4+ bucles de API por resolución. El análisis revela que Claude a menudo solicita `get_customer` y `lookup_order` en turnos secuenciales separados incluso cuando ambos se necesitan inicialmente. ¿Cuál es la forma más efectiva de reducir el número de bucles?

¿Cuál es la forma más efectiva de reducir bucles?

CorrectaD) Instruir a Claude en el prompt para agrupar solicitudes de herramientas en un turno y devolver todos los resultados juntos antes de la siguiente llamada a la API.

Promptear a Claude para agrupar solicitudes de herramientas relacionadas en un solo turno aprovecha su capacidad nativa de solicitar múltiples herramientas a la vez. Corrige directamente el patrón de llamada secuencial con cambio arquitectónico mínimo.

Después de que el agente de búsqueda web encuentra 25 fuentes (120K tokens de contenido sin procesar), el agente de análisis de documentos extrae ideas clave (15K tokens) y el agente de síntesis produce un borrador de narrativa coherente (3K tokens), el coordinador debe pasar el contexto al agente de generación de reportes para la salida final con las citas de fuentes adecuadas.

¿Qué estrategia para pasar el contexto ofrece el mejor equilibrio entre completitud y eficiencia?

CorrectaB) Pasar el borrador de síntesis junto con un índice de fuentes estructurado que mapee las afirmaciones clave con las URLs de sus fuentes y los extractos relevantes.

Correcto. La síntesis aporta la narrativa; el índice de fuentes le da al generador de reportes exactamente la vinculación que necesita para citar sin volver a leer 120K tokens de contenido sin procesar.

El agente de búsqueda web ha reunido varias fuentes relevantes para un tema de investigación. El agente de análisis de documentos ahora necesita examinar esas fuentes.

¿Cómo fluye normalmente la información entre estos dos subagentes especializados?

CorrectaC) El coordinador recibe la salida del agente de búsqueda web e incluye los hallazgos relevantes en el prompt al invocar al agente de análisis de documentos.

Correcto. En un patrón coordinador-trabajador, el coordinador es el eje. Recoge la salida de cada subagente y reenvía explícitamente las partes relevantes al prompt del siguiente subagente.

En producción observas que consultas simples de verificación de hechos (p. ej., "¿En qué año se firmó el Acuerdo de París sobre el Clima?") recorren los cuatro subagentes de forma secuencial, consumiendo más de 40 segundos y bastantes tokens por consulta. La investigación comparativa compleja sí se beneficia del pipeline completo. Tu distribución de consultas es diversa y evoluciona a medida que los usuarios descubren nuevas aplicaciones.

¿Cuál es el enfoque más eficaz para optimizar ante una complejidad de consulta variable?

CorrectaC) Que el coordinador analice cada consulta y decida dinámicamente qué subagentes invocar según su evaluación de los requisitos de la consulta.

Correcto. Dejar que el LLM coordinador razone sobre cada consulta y elija solo los subagentes que necesita se adapta de forma natural a una distribución de consultas diversa y en evolución: esa es la fortaleza del patrón de coordinador.

Después de que el agente de búsqueda web y el agente de análisis de documentos completan sus tareas, el coordinador invoca al agente de síntesis. Sin embargo, el agente de síntesis responde que no puede completar la tarea porque no se le proporcionaron hallazgos de investigación.

¿Cuál es la causa más probable de este problema?

CorrectaB) El coordinador no incluyó las salidas de los agentes previos en el prompt del agente de síntesis.

Correcto. Las invocaciones de subagentes están aisladas: nada fluye entre ellas a menos que el coordinador lo coloque explícitamente en el prompt. El mensaje 'no se proporcionaron hallazgos' es exactamente lo que verías.

Al analizar casos legales complejos que citan múltiples precedentes, el subagente de análisis de documentos procesa cada uno de forma secuencial. Un caso emblemático que cita 12 precedentes tarda más de 3 minutos en analizarse por completo.

¿Cuál es la forma más eficaz de reducir esta latencia preservando la capacidad del coordinador para monitorear y depurar el sistema?

CorrectaC) Que el coordinador genere subagentes de análisis de documentos en paralelo, cada uno encargándose de un subconjunto de precedentes, y luego agregue los resultados antes de la síntesis.

Correcto. El paralelismo gestionado por el coordinador reparte el trabajo, mantiene acotado el alcance de cada subagente y preserva un único eje para el monitoreo y la agregación.

Un desarrollador le pide al agente que investigue por qué un endpoint de API específico devuelve errores 500 de forma intermitente. El código base tiene más de 200 archivos y el desarrollador no sabe qué componentes están involucrados. El agente debe rastrear el error a través de las capas de enrutamiento, middleware, lógica de negocio y base de datos.

¿Qué enfoque de descomposición de tareas sería más efectivo?

CorrectaB) Hacer que el agente genere dinámicamente subtareas de investigación según lo que descubre en cada paso, adaptando su plan de exploración a medida que emerge nueva información sobre la ruta del error.

Correcto. La depuración es adaptativa por naturaleza: cada archivo que lees cambia cuál es el siguiente paso más útil. Deja que el agente siga la evidencia.

Un ingeniero que acaba de unirse al equipo le pide al agente que lo ayude a entender la arquitectura de autenticación y autorización antes de realizar mejoras de seguridad. El código base tiene más de 800 archivos repartidos en múltiples servicios.

¿Qué estrategia de exploración construirá la comprensión de forma más efectiva, dadas las herramientas integradas de Claude y los límites de contexto?

CorrectaC) Usar Grep para encontrar los puntos de entrada de autenticación, leer esos archivos y luego seguir las importaciones y llamadas a funciones para mapear el flujo de autenticación de forma incremental.

Correcto. Empieza en los puntos de entrada (login, verificación de token, middleware) y luego rastrea hacia afuera siguiendo las aristas reales del código. Incremental, fundamentado y se ajusta a los límites de contexto.

Un pull request cambia 14 archivos en un módulo de seguimiento de inventario. Una revisión de una sola pasada que analiza todos los archivos juntos produce resultados inconsistentes: retroalimentación detallada en algunos archivos pero comentarios superficiales en otros, errores obvios omitidos y retroalimentación contradictoria (un patrón se marca en un archivo pero código idéntico se aprueba en otro archivo del mismo PR). ¿Cómo deberías reestructurar la revisión?

¿Cómo deberías reestructurar la revisión?

CorrectaB) Dividir en pasadas enfocadas: revisar cada archivo individualmente para problemas locales, luego ejecutar una pasada separada orientada a la integración para examinar flujos de datos entre archivos.

Las pasadas enfocadas por archivo abordan la causa raíz—dilución de atención—asegurando profundidad consistente y detección confiable de problemas locales. Una pasada separada orientada a la integración cubre luego preocupaciones entre archivos como dependencias e interacciones de flujo de datos.