El problema
Un equipo quiere automatizar la clasificación y resolución de tickets de soporte. Alguien sugiere: "utilicemos Claude Code para esto". Otra persona propone: "no, este es un caso para un servidor MCP". Una tercera opina que basta con invocar la API directamente desde el backend. Las tres pueden tener parte de razón — la pregunta equivocada es "¿qué herramienta conozco mejor?", mientras que la pregunta correcta es "¿qué superficie soporta este trabajo con la menor complejidad posible?"
Claude Code, el Claude Agent SDK, la API de Messages directa y el Model Context Protocol (MCP) no son capas de una misma pila ordenadas por grado de sofisticación. Son superficies con propósitos distintos, y elegir la equivocada no es simplemente "menos elegante" — resulta más costosa de mantener, más difícil de probar o sencillamente no cumple con el requisito.
Las cuatro superficies y qué resuelve cada una
API de Messages directa es la capa fundamental: una solicitud, una respuesta, sin estado entre llamadas salvo el contexto que reenvíes explícitamente. Es ideal para aplicaciones que ya cuentan con su propia orquestación y solo requieren inferencia puntual — un endpoint de resumen o un clasificador integrado en una canalización existente.
Claude Agent SDK añade un arnés de ejecución alrededor de la API: gestión de sesiones, hooks, subagentes y el bucle de herramientas ya resuelto de fábrica. Es la opción adecuada cuando la aplicación necesita un comportamiento agéntico persistente — múltiples turnos, delegación y controles deterministas que las instrucciones de un prompt por sí solas no pueden garantizar.
Claude Code es una aplicación de desarrollo de software que utiliza el Agent SDK por debajo, configurable mediante CLAUDE.md, comandos y Skills. Está diseñada específicamente para flujos de trabajo de ingeniería — no es la herramienta adecuada para construir un servicio de producción destinado al cliente final.
MCP no es una alternativa a las otras tres — es el protocolo que estandariza la exposición de herramientas y recursos para que cualquiera de ellas pueda consumirlos. La cuestión nunca es "Agent SDK o MCP", sino "¿este conjunto de herramientas debería ser un servidor MCP reutilizable o una función invocada directamente en el código de mi aplicación?"
El criterio: requisitos antes que familiaridad
El error más común no es una mala decisión puramente técnica — es elegir la superficie porque el equipo ya está acostumbrado a ella. Un ingeniero que trabaja habitualmente con Claude Code tiende a canalizar todo a través de él, incluso tareas que deberían ser una simple llamada directa a la API dentro de un servicio existente.
El marco de decisión es fácil de enunciar y exigente de aplicar bajo presión:
- ¿La tarea requiere estado a lo largo de múltiples turnos? Si no, la API directa es suficiente — no añadas un arnés de agente para una única invocación puntual.
- ¿La tarea necesita herramientas compartidas por múltiples clientes o agentes? Si es así, es candidata a un servidor MCP en lugar de lógica acoplada.
- ¿La tarea forma parte del propio ciclo de desarrollo de software (generar código, revisar pull requests, ejecutar pruebas)? Eso es Claude Code, no una aplicación independiente.
- ¿La tarea es una aplicación de producción que exige un comportamiento agéntico continuo? Eso corresponde al Agent SDK.
Un distractor clásico en escenarios de examen: "usar Claude Code para automatizar una tarea de producción porque el equipo ya está familiarizado con CLAUDE.md". La familiaridad del equipo no es un requisito técnico — Claude Code no fue diseñado para integrarse de forma desatendida en un servicio de producción de cara a clientes externos.
Combinar superficies es con frecuencia la respuesta correcta
No todos los escenarios se resuelven con una única superficie. Una canalización de CI puede ejecutar Claude Code de forma no interactiva para la revisión de código, mientras que el servicio de producción revisado utiliza el Agent SDK con sus propios servidores MCP para consultar el historial de incidentes. Ambas conviven porque resuelven problemas distintos — interpretar esto como indecisión pasa por alto lo que constituye una arquitectura madura.
Ponlo en práctica
El laboratorio de esta lección implementa un clasificador de requisitos: a partir de una serie de señales sobre una tarea (¿requiere estado? ¿necesita herramientas reutilizables? ¿es sobre el ciclo de desarrollo?), recomienda la superficie adecuada y justifica el porqué — la misma lógica que aplicarás en cuestión de segundos durante el examen.