La mayoría del material de preparación para el CCA-F trata el examen como una lista de trivia: memoriza qué hace el prompt caching, conoce la spec de MCP de nombre. Eso cubre quizás la mitad del examen. La otra mitad se basa en escenarios — el exam guide publica 6 escenarios completos, y cada examen real sortea 4 de ellos, pidiéndote razonar sobre decisiones de arquitectura dentro de ese escenario.
Este es el primero de una serie de 6 partes recorriendo cada uno, con una implementación de referencia que realmente puedes ejecutar — no solo un diagrama. Código fuente completo: aicert-labs/cca-f/scenario-1-customer-support-agent.
El escenario, tal como está en el exam guide
Un agente de soporte construido sobre el Claude Agent SDK maneja devoluciones, disputas de facturación y consultas de cuenta a través de tools MCP personalizadas — get_customer, process_refund, escalate_to_human — con meta de 80%+ de resolución en el primer contacto.
Toca tres dominios a la vez, y por eso exactamente el CCA-F usa escenarios en lugar de preguntas aisladas — las decisiones reales de arquitectura rara vez caben en un solo dominio.
| Dominio | Peso | Dónde aparece en este escenario |
|---|---|---|
| Agentic Architecture & Orchestration | 27% | El loop que permite a Claude llamar tools, leer resultados estructurados y decidir si continúa o escala |
| Tool Design & MCP Integration | 18% | Tres tools con un servidor MCP real — y específicamente, cómo process_refund reporta el fallo |
| Context Management & Reliability | 15% | Qué evita que el agente entre en loop infinito, y qué hace el system prompt vs. qué garantiza la tool |
La decisión de diseño que vale la pena estudiar
Una versión ingenua de process_refund recibe un ID de pedido y un monto, y el system prompt dice "solo reembolsa por debajo de $100". Eso es frágil: depende de que el modelo lea y obedezca instrucciones en prosa en cada llamada, sin nada que lo garantice. Sube el límite, ajusta el prompt en otro lugar, o el modelo simplemente tenga un mal día, y la regla deja de cumplirse silenciosamente.
La implementación de referencia mueve la regla dentro de la propia tool. process_refund no reembolsa-o-da-error — devuelve una señal tipada:
{ "needs_escalation": true, "reasonCode": "over_auto_approve_limit", "orderAmountUsd": 219, "priorRefunds": 2 }
El trabajo del agente se vuelve mecánico: ve needs_escalation, llama a escalate_to_human. No hay prosa que malinterpretar. Esa es la diferencia entre "instruir a un agente para que se comporte" y "diseñar una tool que no pueda usar mal" — exactamente el tipo de juicio que las preguntas de escenario del CCA-F están hechas para evaluar.
Qué evita que el agente entre en loop infinito
El segundo modo de fallo que este escenario está diseñado para exponer: un agente que llama a process_refund, recibe la indicación de escalar, y simplemente... intenta process_refund de nuevo. Y de nuevo. Dos cosas en la implementación de referencia protegen contra esto:
- El system prompt es explícito en que un resultado
needs_escalation: trueno es señal de reintento — es señal de enrutamiento haciaescalate_to_human. agent.tslimita el loop a un número fijo de turnos y registra una advertencia si se alcanza, en lugar de ejecutarse indefinidamente. En una pregunta real de examen, "el agente no tiene lógica de reintento acotada" es exactamente el tipo de brecha de confiabilidad que se esperaría que señales.
Ejecútalo tú mismo
git clone https://github.com/AICERT-STUDY/aicert-labs
cd aicert-labs/cca-f/scenario-1-customer-support-agent
npm install
cp .env.example .env # agrega tu ANTHROPIC_API_KEY
npm run agent -- cust_1001 ord_9001 "the keyboard arrived with a broken key" # auto-aprobado
npm run agent -- cust_1002 ord_9002 "these headphones stopped charging" # fuerza escalación
El README de esa carpeta tiene algunas sugerencias de cambios para probar (bajar el límite de auto-aprobación, quitar el campo tipado needs_escalation y ver al agente comportarse mal) si quieres ver los modos de fallo, no solo leer sobre ellos.
Pon a prueba tus conocimientos
1. En la implementación de referencia, ¿por qué process_refund devuelve needs_escalation: true en lugar de lanzar un error cuando el monto supera el límite?
Respuesta: un resultado tipado permite que el agente decida de forma programática, en lugar de depender de que el modelo interprete correctamente un mensaje de error.
Una cadena de error todavía exige que el modelo lea y reaccione correctamente a la prosa. Un campo estructurado es algo que el código llamador (o el propio razonamiento del modelo sobre la salida estructurada de la tool) puede verificar de forma determinista.
2. ¿A qué dominio se dirige principalmente el límite de 8 turnos en agent.ts?
Respuesta: Context Management & Reliability.
No es una decisión de arquitectura/orquestación (eso es el propio loop de llamadas a tools) ni de diseño de tool (eso es el servidor MCP) — es una salvaguarda contra un loop agentic sin límite, lo cual es una cuestión de confiabilidad.
3. El escenario pide 80%+ de resolución en el primer contacto. ¿Qué decisión de diseño de tool respalda más directamente esa meta?
Respuesta: exigir get_customer antes de cualquier acción en la cuenta, para que el agente siempre tenga contexto verificado antes de actuar.
La resolución en el primer contacto cae drásticamente cuando un agente actúa sobre datos de cuenta desactualizados o incorrectos y tiene que retroceder. Verificar la identidad y obtener el historial de pedidos de antemano es lo que hace posible la resolución en una sola pasada.
4. Un cliente con 2 reembolsos previos solicita un reembolso de $30 — muy por debajo del límite de auto-aprobación de $100. ¿Qué sucede?
Respuesta: la tool igual devuelve needs_escalation: true, porque el umbral de reembolsos repetidos se verifica independientemente del monto.
Esto es deliberado: un cliente por encima del umbral de reembolsos repetidos se enruta a un humano sin importar el monto, porque el patrón de comportamiento — no la cifra en dólares — es la señal que merece revisión humana.
5. Si reemplazas el CRM simulado del servidor MCP por uno real, ¿qué tiene que cambiar en esta arquitectura?
Respuesta: solo la implementación dentro de mock-crm.ts — los contratos de las tools en mcp-server.ts y el loop del agente en agent.ts siguen igual.
Ese es el objetivo de poner la regla de negocio dentro de la frontera de la tool: el agente y la interfaz de la tool MCP no saben ni les importa si el dato viene de un objeto en memoria o de una API real de CRM.
Simulacro gratuito del CCA-F, cubriendo los 5 dominios: aicert.study/certifications/ccaf.