M1 · Claude Platform & Solution Design — Resumen de estudio

Curso 1 de 5 · Claude Certified Architect – Professional · ~238 min · 34 pantallas, 12 secciones, 11 checkpoints

Términos técnicos en inglés (así aparecen en el examen).

Idea central

Antes de construir, un Architect toma 4 decisiones en orden:

1. ¿Qué parte del trabajo es de Claude? (vs. sistemas existentes vs. humanos)
2. ¿Qué forma tiene el trabajo? (augmented call, workflow o agent)
3. ¿Qué reference architecture adopto?
4. ¿Dónde interactúa la solución con Claude? (entry point, modelo, context strategy)

Desordenarlas es el camino más seguro a un pivot caro.

1. Las 4 propiedades de Claude (se diseña alrededor de ellas, no son defectos)

Errores de context window (no confundir):

• Request demasiado grande → rechazado antes de generar: 400 invalid_request_error (prompt too long) o 413 request_too_large (bytes).
• El prompt cabe pero la generación choca con el techo → stop reason model_context_window_exceeded con salida truncada.
• Prevención: revisar el campo usage en cada respuesta y usar la token-counting API.

De propiedad a consecuencia de diseño (clave para el checkpoint):

• Non-determinism → por qué existen los evaluation frameworks
• Knowledge boundary → por qué existen retrieval y tools
• Context como recurso finito → por qué la context strategy es una decisión de diseño
• Confidence ≠ correctness → por qué importa dónde se pone el human-in-the-loop

Caso: una demo funcionó 5 veces seguidas y se asumió determinismo. En producción la conciliación financiera cambiaba de categoría al reprocesar. Una demo no es evidencia de determinismo.

2. Mapa de la plataforma: 3 capas distintas

Toda implementación usa las tres. Confundirlas es la causa nº 1 de conversaciones de arquitectura confusas. (Ej.: poner Claude Code, una herramienta de ingeniería, frente al personal de una sucursal bancaria "porque todo es Claude".)

Los 7 primitives (y su "trabajo" en una palabra)

Regla: usa los menos primitives posibles que cumplan el requisito.

3. Decomposition: Claude / sistemas existentes / humanos

• Claude: comprensión de lenguaje, resumir, planear, redactar, acciones mediadas por tools.
• Sistemas existentes: lo que el partner ya pagó para que sea fiable (servicio de estado de pedidos, policy engine, tabla de reglas, base de datos de registro).
• Humanos: juicio, excepciones, aprobaciones, momentos donde acertar importa más que ser rápido.

Delegation (1ª competencia de AI Fluency): justifica cada asignación por Reversibility, Stakes y Accountability. Hay trabajo AI-appropriate, human-retained y colaborativo (Claude redacta y una persona decide).

Cambio de enfoque clave: no preguntes "¿dónde puede ayudar Claude?", sino "¿dónde las 4 propiedades justifican usar Claude en vez del sistema que ya lo hace bien?"

Ejemplo, claims triage: leer el claim → Claude · decidir prioridad → rule engine (sistema) · buscar cobertura → sistema vía tool/MCP · email → Claude redacta, el sistema de email envía, un humano aprueba por encima de un umbral.

⚠️ Watch out: la regla "claims > £5,000 → senior adjuster" se pasó de SQL a Claude. 41 de 14,000 se enrutaron mal ("alrededor de cinco mil libras"). Una regla determinista que debe acertar siempre no va en un sistema probabilístico que acierta casi siempre. Lo detectó una auditoría, no el monitoreo.

4. Pattern selection: Augmented LLM vs Workflow vs Agent

Workflow sub-patterns: Chaining (secuencial) · Routing (un clasificador elige el camino) · Parallelization (llamadas concurrentes que se agregan o votan) · Evaluator-optimizer (generar → evaluar → revisar hasta cumplir el criterio o un límite de reintentos). Se combinan; elige el más simple que cumpla y escala solo con datos.

5 factores en orden (el primero que descarta un patrón decide): Predictability → Error cost → Observability → Latency budget → Cost.

Prompting antes que fine-tuning: optimizar el prompt → añadir tools/retrieval → patrón más fuerte (evaluator-optimizer) → solo entonces fine-tuning (alto volumen, latencia crítica, formato que el prompting no logra). Disponibilidad limitada: confirmar con el account team.

Empaquetado: prompt-only → tool use directo → Skill (cuando el procedimiento se repite, se distribuye entre equipos o necesita versionado y gobierno).

⚠️ Watch out: se eligió un agent "para no limitarlo". Las trazas mostraron solo 4 caminos → bastaba un router + 4 chains. Además, compliance preguntó qué paso aprobó un desembolso y la respuesta era "un turno del modelo", con una versión del modelo sin fijar (unpinned) ni revalidar. Ante la duda, un agent no es la opción segura por defecto.

Multi-agent

• Orchestrator: descompone, delega y sintetiza (no hace el trabajo de las sub-tareas). Subagents: sub-tareas acotadas en su propio contexto.
• El patrón típico es el fan-out: unidades independientes en paralelo y síntesis al final.
• Un fallo de subagent suele ser recuperable (reintentar, redirigir o marcar el hueco). Un fallo del orchestrator suele no serlo (protege su estado y usa checkpoints).
• Propaga un trace ID compartido. Pon un gate humano antes de acciones irreversibles; las de bajo riesgo se muestrean.
• Coverage check en la síntesis: resultados recibidos = unidades despachadas.

⚠️ Watch out: contrato de 50 secciones con resultado "48 reviewed, 3 flagged". Dos subagents fallaron en silencio. Una síntesis segura sobre trabajo incompleto es el fallo más peligroso.

5. Reference architectures

• Combina dos patrones solo si las partes fallan de forma distinta. Si no, adapta uno.
• Error más común: retrieval aplicado a live state. Síntomas: chunks viejos, respuestas que contradicen la base de datos. La solución es una tool call al sistema de registro, no un mejor embedding ni refrescos más frecuentes.
• Retrieval = conocimiento estable. Tool use = live state. La similitud no es verdad.

6. RAG pipeline design

Chunking (según la estructura del corpus): Fixed-size (texto homogéneo) · Semantic (prosa; chunks autocontenidos) · Hierarchical (contratos, manuales, políticas con secciones).

Indexing (según cómo se formulan las consultas): Dense/embeddings (significado, paráfrasis) · Sparse/BM25 (términos exactos: SKUs, artículos de ley, códigos de error) · Hybrid (el caso típico en producción). Se fusionan las listas con Reciprocal Rank Fusion.

Trade-off triple: calidad de retrieval vs latencia vs mantenimiento. La calidad no se ve en el output; se mide con un set etiquetado.

Ejercicio resuelto: contratos y handbook → hierarchical; write-ups → semantic; corpus → hybrid (la variedad de consultas es la restricción dominante).

7. Model, context window y context strategy

No confundir: context window (atención activa, se reinicia entre llamadas) · retrieval (conocimiento traído en el momento) · persistent application state (lo maneja tu sistema; requiere tool call) · summaries/memory (continuidad gestionada por la app).

• Modelo: empieza con Sonnet. Sube a Opus o baja a Haiku solo con un eval que lo justifique.
• Tamaño de la ventana: mide tokens con usage. No presupuestes la ventana completa: es un techo, no una meta.
• Context strategies:
  • Monolithic: tareas acotadas, prefijos estables (caching). Falla cuando el contexto se acumula.
  • Progressive: el default en producción. Falla con coherencia de largo alcance y debugging difícil.
  • Retrieval: corpus grandes o cambiantes, citas. Falla en síntesis multi-documento, chunking malo, recall.
  • Compaction: agentes largos. Falla si pierde detalles críticos y es irreversible.
• En la práctica se combinan. Ejemplo, coding agent: prefijo monolithic → progressive → retrieval just-in-time → compaction.
• Extended thinking: se factura como output tokens y añade latencia. En modelos actuales se usa adaptive thinking + effort parameter; budget_tokens está deprecado (en 4.6) o eliminado (en Sonnet 5, da error 400). Actívalo solo si un eval muestra una brecha de precisión.
• Cada cambio de modelo es un release: (1) test set curado, (2) grading function, (3) umbral de delta fijado ANTES de correr el eval.
  • Caso Sonnet → Haiku: 0.94 vs 0.86, con dos tipos de documento en 0.71 y 0.74. El criterio previo (<0.85 por tipo = rechazo) llevó a una migración parcial: esos 2 tipos siguen en Sonnet y el resto pasa a Haiku.

⚠️ Watch out: Opus en todas partes → 7× el costo, 2.3 s de latencia y la misma satisfacción del cliente. Solución: Haiku para el classifier, Sonnet para el resumen y Opus solo en la composición final (−71% de costo, 940 ms). No elegir modelo equivale a elegir el más caro.

Calculadora (checkpoint): el control load-bearing es el que mueve la restricción con menos margen → respuesta B.

8. Prompting as architecture

• System prompt empresarial: rol y alcance + restricciones (siempre / nunca) + output contract. La ambigüedad se multiplica en cada request.
• Templates: slots parametrizados + andamiaje fijo que lleva las garantías; el camino seguro es el camino por defecto.
• Description (competencia 4D): scope, format, constraints. El underspecification es un hueco que el modelo rellena distinto cada vez.
• Un guardrail mal especificado es peor que ninguno: aparenta un control que no existe.
• Técnicas: zero-shot (prueba esto primero) → few-shot (si es más fácil mostrar que describir) → chain-of-thought (lógica de varios pasos). Elige la más ligera que cumpla.
  • Checkpoint: clasificar tickets = zero-shot · extraer recibos variados = few-shot · cláusula con 3 condiciones = CoT · resumir 400 palabras = zero-shot.
• El mismo prompt se comporta distinto entre modelos: lo que envías a producción es el par prompt-modelo.
• Bias: fraseo neutral y ejemplos balanceados.
• Prompt caching: prefijo estable y lo estático antes de lo dinámico. Breakpoints, TTL según frecuencia y cambios, y saber que escribir en caché cuesta (no conviene si las llamadas son poco frecuentes o el prefijo es pequeño).
• Prompt library vs Skill: library = fragmentos dentro de un equipo, gobierno ligero. Skill = procedimiento estable, distribuido, con versionado, aprobación y rollback.
  • Ejercicio: tono, contrato y guardrail en el prefijo; ticket y manual al final; el "nunca prometer reembolsos" se impone en el output contract; se entrega como Skill versionado.

9. Entry points, build-time interfaces, delivery routes y gobierno

Entry points:

• Claude.ai: consumer (Free/Pro/Max) y Claude for Work. Team añade SSO/SAML, admin y compromiso de no entrenar con los datos. Enterprise añade SCIM, retención, audit logs, Compliance API y opción HIPAA con BAA. Cero código, cero integración.
• Claude Code: terminal, IDE, desktop y web. Hecho para ingeniería.
• Claude Cowork: agente de escritorio para no desarrolladores; los permisos importan más.
• Claude in Chrome y Claude for Excel.

Build-time interfaces:

• Direct API: máximo control y máxima responsabilidad.
• SDKs: el default para integrar en un producto.
• MCP: compartir tools entre varios clientes. Con un solo cliente es sobrecarga.
• Agent SDK: el loop de Claude Code embebido en tu app.
• API tool use ≠ MCP: son capas distintas. Anthropic SDK ≠ Agent SDK.

Capas de Claude Code:

• SHAPING (qué sabe y hace): CLAUDE.md, Skills, Subagents, MCP.
• GOVERNING (qué puede tocar): Hooks, permisos y aprobaciones, sandboxing.
• 6 permission modes: default · acceptEdits · plan (solo lectura hasta aprobar) · auto (clasificador, research preview) · dontAsk (CI cerrado, solo allow rules) · bypassPermissions (solo contenedores/CI).

Delivery routes: decide lo que el partner ya tiene contratado, no la capacidad técnica (el modelo es el mismo).

• AWS → Bedrock (IAM) · GCP → Vertex · Azure → Foundry (Entra ID; hosted on Azure vs on Anthropic).
• Sin preferencia cloud o necesidad de features nuevas → API de Anthropic (las CSPs van semanas atrás en features).

Skills como integración: container.skills, endpoint /v1/skills; requieren el Code Execution Tool.

Restricciones reguladas (eliminan opciones ANTES que costo o preferencias):

⚠️ Watch out: asistente para un banco con Claude Code en las laptops, MCP para todo y compliance en subagents. Las tres decisiones están mal. Correcto: una web app propia sobre la API, compliance en código determinista del servidor, SSO y auditoría en el límite del servidor.

Respuestas de los checkpoints (para autoevaluarte)

• Capas: entry points = claude.ai, Claude Desktop, Claude Code · build-time = Direct API, SDKs, MCP, Agent SDK · delivery = Bedrock/Vertex/Foundry.
• Field service:
  • Claude = resumir notas, extraer el número de pieza de una foto, redactar el email.
  • Sistemas = stock del SKU, calcular horas facturables, garantía por número de serie.
  • Humano = reembolso > £2,000, escalar un incidente de seguridad.
• Logística: leer la nota = Claude · elegibilidad de reembolso = sistema · tier de contrato = sistema · redactar = Claude · emitir el reembolso = humano.
• Orchestration critique: defectuosos = 3 (síntesis sin coverage check), 4 (auto-archive sin gate), 5 (sin retry ni marca de hueco).
• Diagram critique: mal aplicados = 2 (retrieval sobre el estado de pedidos), 4 (agent con refund/cancel), 5 (falta el escalamiento a humano).
• Entry point + tradeoff: Esc. 2 = A (Bedrock) · Esc. 3 = B (API detrás del gateway de la firma) · Esc. 4 = B (claude.ai + Project) · Esc. 5 = C (Bedrock, el BAA existente) · Esc. 6 = A (Vertex, latencia).
• Law firm (assembly): Opción D.
  • A falla por privilegio (Claude.ai).
  • B carga el playbook entero (monolithic).
  • C usa un agent abierto + Opus en todo.

Para recordar (key takeaways)

1. La decomposition va antes que la arquitectura.
2. Elegir un patrón es elegir cuánta autonomía das; decide la restricción más estricta.
3. Usa reference architectures probadas; nunca retrieval para live state.
4. Sonnet por defecto y cada cambio de modelo es un release con eval y criterio de rollback previo.
5. El entry point sigue al usuario y al trabajo; di el tradeoff en voz alta.