Es lunes. Tu agente de soporte resuelve el 62 % de los casos al primer contacto y el objetivo es 80 %. Los logs muestran dos cosas: reembolsos de más de 500 $ que se aprueban sin pasar por nadie, y clientes que piden una persona y reciben otro intento de solución. Tienes tres propuestas sobre la mesa: un modelo más grande, un clasificador de sentimiento y un párrafo más en el prompt. Ninguna es la buena.
Esta lección no introduce temas nuevos. Es el cruce. El examen no pregunta por dominios aislados: te da 4 escenarios elegidos al azar entre 6 y cada pregunta mezcla decisiones de varios dominios. Vamos a resolver cuatro escenarios de principio a fin y a fijar el método. Los detalles de cada pieza los tienes en las lecciones 2 a 6; aquí practicamos a combinarlos.
El método: síntoma, causa raíz, garantía
Casi todas las preguntas de la guía tienen el mismo molde: un síntoma medido en producción («en el 12 % de los casos…») y la pregunta por la mejor primera medida, la causa raíz o el enfoque más eficaz. Antes de mirar las opciones, hazte tres preguntas:
- ¿Es un fallo de garantía o de criterio? Si la regla no puede fallar nunca (límite de reembolso, orden de herramientas), la respuesta es programática: hooks o requisitos previos. Si es una cuestión de juicio (qué marcar, cuándo escalar), la respuesta es criterios explícitos y ejemplos.
- ¿Dónde está el fallo? Culpar a un componente que funciona bien es un distractor clásico.
- ¿Es la medida más simple que ataca la causa? La sobreingeniería (clasificador, capa de enrutado, modelo entrenado) casi nunca es la primera medida.
Hace falta garantía
la regla no puede fallar
- Límite de reembolso, identidad verificada antes de actuar
- Hook que intercepta la llamada y redirige a escalado
- Requisito previo programático entre herramientas
- Un prompt tiene una tasa de fallo no nula
Hace falta criterio
es cuestión de juicio
- Cuándo escalar, qué comentario marcar, qué severidad
- Criterios categóricos concretos, no «sé conservador»
- 2-4 ejemplos few-shot en los casos ambiguos
- Descripciones de herramientas claras y sin solapes
Si el enunciado dice «siempre» o «nunca», piensa en código. Si dice «a veces se equivoca al decidir», piensa en criterios y ejemplos.
Escenario 1: agente de soporte (dominios 1, 2 y 5)
El agente usa el Agent SDK con get_customer, lookup_order, process_refund y escalate_to_human. Vamos a leer el diseño completo.
Bucle (1.1). Continúa mientras stop_reason sea tool_use; termina con end_turn. Los resultados de herramientas se añaden al historial. Nada de parar porque «hay texto» ni de usar un tope de iteraciones como criterio principal.
Garantías (1.4 y 1.5). Aquí está el primer síntoma de la apertura: reembolsos grandes sin supervisión. Instruir en el prompt «no apruebes más de 500 $» deja una probabilidad de fallo. La solución es un hook que intercepte process_refund, compruebe el importe y redirija a escalate_to_human. Del mismo modo, process_refund no debe ejecutarse sin que get_customer haya verificado al cliente: requisito previo programático. Un hook PostToolUse normaliza fechas y códigos que devuelven distintos sistemas.
Herramientas (2.1 y 2.2). Si el agente confunde get_customer con lookup_order, la causa raíz suele estar en las descripciones: formatos de entrada, casos límite, cuándo usar cada una. Los errores salen estructurados: categoría (transitorio, validación, negocio, permiso), isRetryable y mensaje legible. Un pedido «no encontrado» y un fallo de acceso no son lo mismo.
Contexto y escalado (5.1 y 5.2). Los datos del caso viven en un bloque persistente fuera del historial resumido. Se escala de inmediato si el cliente pide una persona, ante huecos de política o si el agente no puede avanzar. Con varias coincidencias de cliente se piden más identificadores. Sentimiento y confianza autodeclarada no son indicadores fiables. Y al traspasar, el resumen va estructurado: ID de cliente, causa raíz, importe, acción recomendada. El humano no ve la conversación.
El agente llama a get_customer. Si hay varias coincidencias, pide más identificadores en lugar de elegir una.
Escenario de soporte: el 8 % de los reembolsos superiores al límite de la política se aprueban sin escalar, aunque el prompt del sistema lo prohíbe de forma explícita. ¿Cuál es la mejor primera medida?
Escenario 2: extracción de datos estructurados (dominios 4 y 5)
Procesas facturas, contratos y albaranes con estructuras muy distintas. Quieres JSON validado que entre en el ERP. Es el escenario donde más se cruzan prompt y fiabilidad.
Esquema (4.3). Usar tool use con JSON Schema elimina los errores de sintaxis, pero no los semánticos: líneas que no suman el total, un valor en el campo equivocado. Por eso el esquema lleva campos opcionales o nullable (así Claude no inventa lo que no está en el documento) y enums con unclear y other más un campo de detalle. Una nota de actualidad: con Opus 5.5, Sonnet 5.5 y Fable 5.1, tool_choice de tipo any o tool devuelve error 400; la alternativa es auto con strict tool use o structured outputs.
Few-shot (4.2). Para formato consistente con estructuras variadas, 2-4 ejemplos dirigidos a los casos ambiguos, que muestren por qué se eligió una opción. Reducen los campos vacíos o fabricados.
Validación y reintento (4.4). Se valida en código (por ejemplo, calculated_total frente a stated_total y un booleano conflict_detected). Si falla, el reintento incluye el documento original, la extracción fallida y el error concreto. Pero si el dato no está en el documento, reintentar no sirve: el campo debe poder quedar a nulo.
Lotes (4.5). La Message Batches API cuesta un 50 % menos y tarda hasta 24 horas, sin SLA de latencia. Sirve para cargas no bloqueantes (cierres nocturnos, auditorías) y no para algo que bloquea a un usuario. Cada petición lleva un custom_id; los fallidos se reenvían solo ellos, troceando los documentos demasiado largos. Antes de lanzar el lote, afina el prompt con una muestra.
Humanos (5.5). Una precisión global alta puede esconder un tipo de documento o un campo que falla mucho. Se mide por tipo y campo, se audita con muestreo aleatorio estratificado y la confianza por campo se calibra con un conjunto etiquetado antes de usarla para enrutar a revisión humana.
Escenario 3: sistema multiagente de investigación (dominios 1, 2 y 5)
Un coordinador reparte el trabajo entre subagentes de búsqueda web, análisis de documentos y síntesis. El informe final lleva citas.
Arquitectura (1.2 y 1.3). Es hub-and-spoke: toda comunicación pasa por el coordinador y cada subagente tiene contexto aislado. Por eso el contexto va explícito en el prompt del subagente y no se hereda. El coordinador necesita Agent en allowedTools y puede lanzar subagentes en paralelo con varias llamadas en una sola respuesta. Los prompts dan objetivos y criterios de calidad, no recetas paso a paso.
Cobertura (1.2). Un síntoma típico: el informe sobre «arte creado con IA» solo habla de artes visuales. La causa raíz está en el coordinador, que descompuso el tema de forma demasiado estrecha. Los subagentes hicieron bien lo que se les pidió. Culpar a la búsqueda es el distractor.
Herramientas (2.3). Cada subagente recibe las herramientas de su rol. Si el de síntesis necesita comprobar un dato suelto, una herramienta cruzada acotada como verify_fact evita dar acceso a todo.
Errores y procedencia (5.3 y 5.6). Un fallo de acceso no es un resultado vacío. Lo transitorio se reintenta en el subagente; lo demás sube como error estructurado con tipo, intento, parciales y alternativas. La síntesis anota la cobertura. Los subagentes devuelven datos con afirmación, fuente y fecha, de modo que el conflicto entre dos cifras se anota con su origen y se distingue de una diferencia temporal.
Hueco · Informe incompleto por tema
Los subagentes ejecutaron bien su tarea, pero el coordinador la descompuso de forma demasiado estrecha. Se corrige la descomposición del coordinador.
Pulsa cada síntoma: el examen siempre te pide localizar el componente culpable.
Escenario 4: Claude Code en CI (dominios 3 y 4)
Revisión automática de pull requests y generación de tests. El problema real de este escenario es la confianza: si el equipo ve falsos positivos, deja de leer los comentarios.
Configuración (3.6). Se ejecuta con -p y salida --output-format json con --json-schema para que el pipeline la procese. CLAUDE.md da el contexto del proyecto. La revisión la hace una instancia independiente de la que escribió el código. Si hay nuevos commits, se incluyen los hallazgos previos para no duplicar comentarios, y los tests existentes deben pasar.
Falsos positivos (4.1). Un «sé conservador» no sirve. Hacen falta criterios categóricos concretos, por ejemplo marcar un comentario solo si contradice lo que hace el código, y criterios de severidad con ejemplos de código por nivel. Si una categoría genera muchos falsos positivos, se desactiva temporalmente mientras se mejora: sus errores hunden la confianza en todas las demás.
Multipasada (4.6). Para un PR grande, una pasada por archivo y una pasada de integración que mire las interacciones entre archivos. Reduce la dilución de atención sin recurrir a un modelo mayor. Que el modelo reporte confianza por hallazgo puede servir para enrutar, no como prueba.
Síncrono o lote (4.5). El check previo al merge bloquea a un desarrollador: va síncrono. La auditoría semanal de todo el repositorio no bloquea a nadie: va por Batch API, con el 50 % de ahorro. Las dos cosas pueden convivir en el mismo equipo.
Cómo se cruzan los dominios
| Si el síntoma es… | Piensa en… |
|---|---|
| Regla que a veces se salta | Hook o requisito previo (D1) |
| Herramienta equivocada elegida | Descripciones y reparto (D2) |
| Resultados inconsistentes de formato | Few-shot y esquema (D4) |
| Datos que se vuelven vagos | Hechos persistentes (D5) |
| Muchos falsos positivos | Criterios explícitos (D4) |
| Fallo de un subagente | Error estructurado y cobertura (D5) |
Para el examen
Un último hábito antes del simulacro: lee la última frase del enunciado primero. Te dice si buscan primera medida, causa raíz o enfoque más eficaz, y cambia la respuesta. Descarta después los distractores típicos: soluciones probabilísticas donde hace falta garantía, sobreingeniería, confianza autodeclarada como métrica, modelos más grandes o más contexto como remedio de la atención, y funciones inventadas.
Dominio · Cruce de dominios 1-5 · Escenarios de soporte, extracción, multiagente y CI
Lo que tienes que dominar
- Reglas que no pueden fallar: hooks o requisitos previos programáticos, no más instrucciones en el prompt.
- Soporte: bloque de hechos del caso, escalado inmediato si piden persona y traspaso con resumen estructurado.
- Extracción: el esquema evita errores de sintaxis, no semánticos; campos nullable y validación en código.
- Reintento con documento, extracción fallida y error concreto; inútil si el dato no está en el documento.
- Batch API para cargas no bloqueantes con custom_id; checks previos al merge, síncronos.
- Multiagente: contexto explícito al subagente, descomposición del coordinador como causa de huecos de cobertura.
- Fallo de acceso no es resultado vacío; la síntesis anota cobertura, fuente y fecha.
- CI: criterios categóricos contra falsos positivos, revisor independiente y pasada por archivo más integración.
- Precisión global alta: desglosar por tipo y campo, y calibrar la confianza con datos etiquetados.
Donde se suele fallar
- Reforzar el prompt cuando la regla exige una garantía.
- Culpar a los subagentes cuando la causa es la descomposición del coordinador.
- Pensar que un JSON que valida contra el esquema ya es correcto.
- Usar Batch API para un check que bloquea un merge.
- Escalar por sentimiento o por confianza autodeclarada.
- Resolver degradación de contexto o atención con una ventana o un modelo mayores.
- Añadir un clasificador o una capa de enrutado antes de arreglar descripciones o criterios.
Checklist para el examen
0 de 8 dominadosMarca lo que ya sabrías responder en el examen.
Ponte a prueba
Tipo test
6 preguntas sobre esta lección. Responde una a una; verás las soluciones al terminar.