Architect – Foundations
Es el examen más predecible del programa: presenta cuatro escenarios extraídos de un banco de seis, y la guía oficial describe los seis. Por eso esta ruta va escenario por escenario y no por temario, que es como está construido el examen. La guía es la fuente para el temario y los pesos; esta página es la ruta de trabajo.
Empieza por aquí: delimita el temario
La guía oficial cierra con un apéndice que enumera qué queda explícitamente fuera del examen. Es lo primero que hay que leer, porque ahorra más tiempo que cualquier otra cosa — y porque buena parte de lo que se estudia para el Developer no cuenta aquí.
Consulta el apéndice de la guía para la lista completa antes de planificar. Como regla práctica derivada
de ella: de nuestra referencia técnica aquí solo aplican tool_use con
JSON schemas, los valores de tool_choice, stop_reason, max_tokens,
los system prompts y el Batch API. El resto de secciones son para el Developer.
La ficha
| Código | CCAR-F | Ítems | 60 |
|---|---|---|---|
| Estructura | 4 escenarios de un banco de 6 publicados | ||
| Tiempo | 120 min | Corte | 720 / 1000 |
| Dominio | Peso | Ítems | Task statements |
|---|---|---|---|
| 1 · Agentic Architecture & Orchestration | 27% | 16 | 7 |
| 3 · Claude Code Configuration & Workflows | 20% | 12 | 6 |
| 4 · Prompt Engineering & Structured Output | 20% | 12 | 6 |
| 2 · Tool Design & MCP Integration | 18% | 11 | 5 |
| 5 · Context Management & Reliability | 15% | 9 | 6 |
Cómo razonar los ítems
Los ítems son escenarios de producción con cuatro opciones que suenan todas razonables. Tras trabajar el material, estas son las heurísticas que más veces deciden entre dos opciones defendibles.
| Si el problema es… | La respuesta suele ser… |
|---|---|
| Se salta un paso obligatorio con consecuencias graves | Enforcement programático, no una instrucción en el prompt |
| Confunde dos tools parecidas desde el primer turno | Ampliar las descripciones: formatos, ejemplos, casos límite y fronteras |
| La selección de tool se degrada tras N turnos | La ventana de contexto, no el esquema |
| Decide mal cuándo escalar | Criterios explícitos con ejemplos, no autoconfianza del modelo |
| Algo debe llegar a todo el equipo | El scope de proyecto, versionado en el repo |
| Convenciones para ficheros dispersos por el repo | Reglas por ruta con globs, no un fichero por directorio |
| Cambio grande con varias arquitecturas posibles | Plan mode antes de tocar nada |
| Informe incompleto y subagentes que funcionan bien | La descomposición del coordinador |
| Un subagente falla | Error estructurado: tipo, intento, resultados parciales, alternativas |
| Revisión larga con resultados inconsistentes | Pasadas separadas: por unidad y luego de integración |
| Ahorrar coste en un flujo que bloquea a alguien | Batch solo para lo que nadie espera |
Qué evalúa cada dominio
La guía desarrolla cada dominio en varios task statements con lo que hay que saber y lo que hay que saber hacer. Ese detalle está en el documento oficial y merece leerse entero. Aquí va el mapa de temas para orientar el estudio, y el desarrollo conceptual de cada uno está en los apuntes.
Agentic Architecture & Orchestration
27%Bucles agénticos y su condición de parada · coordinador y subagentes, con el paso explícito de contexto y el spawn en paralelo · enforcement y handoff en flujos multi-paso · hooks para interceptar y normalizar · descomposición fija frente a dinámica · gestión de sesiones, reanudación y ramificación.
Claude Code Configuration & Workflows
20%Jerarquía y modularidad de la configuración de proyecto · comandos y skills, con sus ámbitos y sus opciones de aislamiento · reglas condicionales por ruta · cuándo planificar antes de ejecutar · técnicas de refinamiento iterativo · integración en CI con salida estructurada.
Prompt Engineering & Structured Output
20%Criterios explícitos para reducir falsos positivos · few-shot para consistencia y para casos ambiguos · salida estructurada con tool use y JSON Schema, y qué garantiza y qué no · validación, reintento y bucles de feedback · cuándo el procesamiento por lotes es apropiado · arquitecturas de revisión en varias pasadas e instancias.
Tool Design & MCP Integration
18%Descripciones que diferencian tools parecidas · errores estructurados con categoría y reintentabilidad · distribución de tools por rol y configuración de la elección · integración de servidores MCP con sus ámbitos y credenciales · selección de las tools integradas de lectura, búsqueda y edición.
Context Management & Reliability
15%Preservar información crítica en interacciones largas · criterios de escalado y resolución de ambigüedad · propagación de errores entre agentes · contexto en exploración de código grande · revisión humana y calibración de confianza · procedencia de la información e incertidumbre en síntesis multi-fuente.
Los seis escenarios
El examen presenta cuatro de seis, y la guía oficial los describe con detalle: léelos ahí. Lo que sigue es lo que conviene tener trabajado de cada uno — las decisiones que hay que saber defender y los anti-patrones que aparecen como distractores.
1 · Agente de resolución de soporte
Decisiones que defender
- El bucle se controla por
stop_reason, no por un tope de iteraciones. - Una operación irreversible lleva checkpoint humano o prerequisito programático antes de cablear el bucle; y si el rol no la necesita, se quita la tool.
- La tool de escalado compite con las demás: sin condición de exclusión en las descripciones, se convierte en la salida fácil o no se usa nunca.
- Los fallos vuelven con bandera de error y categoría, nunca como resultado vacío.
- Las conversaciones largas exigen sacar los hechos transaccionales del historial que se resume.
Anti-patrones
- Auditar una capacidad peligrosa en vez de retirarla.
- Confiar en una instrucción del prompt donde hace falta enforcement.
- Fijar un objetivo de resolución sin definir qué cuenta como resuelto.
2 · Generación de código con Claude Code
Decisiones que defender
- Planificar antes de ejecutar cuando hay varias arquitecturas posibles y muchos ficheros en juego.
- La configuración de proyecto se concatena entre niveles: las reglas contradictorias hay que eliminarlas, no esperar a que gane una.
- Las reglas de permisos se evalúan en un orden fijo y el primer match decide.
- Cada mecanismo de contexto duradero resuelve un problema distinto; amontonarlos en un solo fichero los degrada todos.
- Dos correcciones sobre el mismo problema significan contexto contaminado: limpiar y replantear.
Anti-patrones
- Modo permisivo «por velocidad» contra un repositorio vivo.
- Confiar una prohibición a una nota en la configuración en vez de a un control.
3 · Sistema multi-agente de investigación
Decisiones que defender
- Los subagentes no heredan contexto: los hallazgos viajan en el prompt con el que se lanzan.
- Paralelizar es emitir varias llamadas de spawn en una sola respuesta.
- Particionar el alcance entre subagentes para no duplicar trabajo.
- Un bucle de refinamiento donde el coordinador detecta huecos y re-delega con consultas dirigidas.
- Separar contenido de metadatos para que la atribución sobreviva a cada resumen.
Anti-patrones
- Culpar a los subagentes cuando el fallo está en cómo se repartió el trabajo.
- Recorrer siempre el pipeline completo en vez de elegir según la consulta.
- Usar multi-agente en trabajo acoplado, donde multiplica coste sin ganancia.
4 · Productividad de desarrollo
Decisiones que defender
- Modelo híbrido de contexto: precargar lo estable y recuperar el resto bajo demanda.
- Delegar en un subagente la exploración que inundaría el contexto principal.
- Elegir la tool por lo que busca: contenido, rutas o edición puntual, con su alternativa cuando falla.
- Conectar servidores deliberadamente: cada uno gasta contexto aunque no se use.
- Acotar el catálogo de tools por rol antes de que la selección se degrade.
Anti-patrones
- Cargar el repositorio entero «para que tenga contexto».
- Repartir muchas tools entre varios servidores creyendo que reduce la confusión.
5 · Claude Code en CI/CD
Decisiones que defender
- Los hallazgos son material para triar, no un veredicto: se confirma lo demostrable desde el diff.
- La puerta humana va donde un hallazgo se convierte en acción difícil de revertir.
- Los falsos positivos bajan dando las convenciones del equipo, no pidiendo «más rigor».
- Modo no interactivo con salida estructurada para consumir el resultado en el pipeline.
- Una instancia independiente revisa mejor que la que generó el código.
Anti-patrones
- Bloquear el merge con cada hallazgo: en una semana se aprueba en automático.
- Aceptar afirmaciones sobre comportamiento en ejecución que el revisor no pudo medir.
6 · Extracción de datos estructurados
Decisiones que defender
- El esquema garantiza la forma, no el significado: la validación semántica sigue siendo tuya.
- Campos anulables para que el modelo pueda abstenerse en vez de inventar.
- Válvulas de escape en las categorías cerradas, porque las listas fijas envejecen.
- Reintento con el error concreto como feedback, sabiendo cuándo es inútil: si el dato no está, no aparecerá.
- Confianza por campo y muestreo para decidir qué revisa un humano.
Anti-patrones
- Recalcular un total a partir de las líneas: fabrica datos que ahora pasan validación.
- Reintentar con el mismo prompt esperando un resultado distinto.
Cuatro laboratorios
La guía propone ejercicios prácticos de preparación. Estos son los que yo montaría, alineados con ellos y con lo que más pesa en el examen. Construir uno enseña más que releer tres veces la teoría.
| # | Laboratorio | Refuerza |
|---|---|---|
| 1 | Agente con tres o cuatro tools, dos de ellas deliberadamente parecidas. Bucle controlado por stop_reason, errores con categoría y reintentabilidad, y un control programático que bloquee una operación por encima de un umbral. | Orquestación · tools · contexto |
| 2 | Configurar un repositorio para un equipo: reglas de proyecto, reglas condicionales por ruta, una skill aislada con permisos restringidos, y un servidor MCP compartido con credenciales fuera del repo. | Claude Code · MCP |
| 3 | Pipeline de extracción con campos anulables y categorías extensibles, bucle de validación y reintento con feedback, y un lote grande con reenvío selectivo de los fallidos. | Salida estructurada · contexto |
| 4 | Coordinador con dos subagentes lanzados en paralelo, salida estructurada que separe afirmación, evidencia, fuente y fecha, un timeout simulado para probar la propagación de errores, y fuentes en conflicto. | Orquestación · tools · contexto |