El Claude Agent SDK ha dejado de ser una novedad para convertirse en la forma estándar de construir agentes sobre Claude. A septiembre de 2026 la librería va por la rama 0.3.x, se distribuye oficialmente para Python y TypeScript, y pone en tus manos el mismo bucle de agente, las mismas herramientas integradas y la misma gestión de contexto que mueven Claude Code por dentro.
Esta guía explica qué aporta realmente el SDK, qué piezas tienes que poner tú, cuánto cuesta mantener un agente en producción y en qué casos compensa construir uno propio en lugar de tirar de un asistente genérico. Si vienes de la automatización clásica, te interesa contrastarlo antes con nuestro repaso de casos reales de agentes IA en empresa.
Agent SDK: construye agentes IA a medida para tu negocio
Anthropic ha publicado el Claude Agent SDK, un framework de desarrollo que permite a empresas y desarrolladores construir agentes de inteligencia artificial personalizados. Si Claude Code es el agente de programación y Cowork el de oficina, el Agent SDK es el kit de construcción para crear tu propio agente adaptado a los procesos específicos de tu negocio.
Qué es un agente y por qué necesitas uno personalizado
Un agente IA es un programa que combina el razonamiento de un modelo de lenguaje con la capacidad de usar herramientas externas para completar tareas de forma autónoma. La diferencia con un chatbot es que el agente puede planificar pasos, ejecutar acciones, verificar resultados y adaptarse si algo falla.
Los agentes genéricos como ChatGPT o Claude sirven para tareas generales, pero los agentes personalizados están diseñados para ejecutar workflows específicos de tu empresa: un agente de onboarding que guía a nuevos clientes a través de tu proceso, un agente de soporte que resuelve tickets consultando tu base de conocimiento, o un agente comercial que prepara propuestas usando datos de tu CRM.
Chatbot, automatización clásica y agente no son lo mismo
La confusión entre estos tres conceptos es la causa número uno de proyectos de IA que decepcionan. Conviene tenerlo claro antes de escribir una línea de código:
| Enfoque | Cómo decide | Dónde encaja | Dónde se rompe |
|---|---|---|---|
| Automatización clásica (n8n, Make, scripts) | Reglas fijas que tú escribes paso a paso | Procesos deterministas y de alto volumen | Cuando la entrada no viene siempre igual |
| Chatbot | Genera texto a partir de un prompt | Responder preguntas, redactar, resumir | Cuando hay que hacer algo, no solo contarlo |
| Agente | Planifica, llama herramientas y verifica resultados | Tareas con varios pasos y criterio de por medio | Cuando no hay forma de comprobar si acertó |
La regla práctica: si puedes dibujar el proceso completo en un diagrama de flujo sin un solo rombo de «depende», no necesitas un agente — necesitas una automatización, y probablemente te salga más barata y más predecible con n8n combinado con IA. El agente gana justo donde el diagrama se llena de excepciones.

Cómo funciona el Agent SDK
El SDK proporciona las piezas fundamentales para construir agentes. Tools (herramientas): defines las acciones que tu agente puede ejecutar, como consultar una API, leer una base de datos o enviar un email. Cada herramienta es una función que el agente puede invocar cuando lo necesite. System prompts: defines la personalidad, el conocimiento base y las restricciones del agente. Orchestration: el SDK maneja el ciclo de razonamiento del agente: recibe una tarea, planifica los pasos, ejecuta herramientas, evalúa resultados y decide si continúa o entrega el resultado.
Lo que hereda de Claude Code
La clave del SDK es que no es un framework genérico escrito desde cero: expone las mismas capacidades que ya usa Claude Code a diario, probadas en un producto con tráfico real. Estas son las que tienes disponibles hoy:
| Capacidad | Para qué la vas a usar |
|---|---|
| Herramientas integradas | Leer, escribir y editar ficheros, ejecutar comandos y buscar en la web sin implementarlo tú |
| Hooks | Ejecutar código propio en puntos concretos del ciclo de vida: registrar auditoría, validar una salida, bloquear una acción |
| Subagentes | Delegar subtareas en agentes especializados con su propio contexto, sin contaminar la conversación principal |
| MCP | Conectar herramientas y fuentes de datos externas mediante el Model Context Protocol |
| Permisos | Decidir qué herramientas se ejecutan solas y cuáles requieren aprobación humana |
| Sesiones | Mantener contexto entre intercambios, reanudar una sesión antigua o bifurcarla |
| Skills, comandos y memoria | Cargar automáticamente lo que haya en el directorio .claude/ del proyecto y del usuario |
| Plugins | Empaquetar skills, agentes, hooks y servidores MCP y cargarlos como una unidad |
De todas ellas, las dos que más subestiman los equipos que empiezan son hooks y permisos. Son precisamente las que convierten un prototipo simpático en algo que puedes dejar corriendo contra sistemas de producción sin sudar frío.

El agente más corto que puedes escribir
Una de las cosas que sorprende al abrir el SDK por primera vez es lo poco que hay que escribir para tener un agente funcional. En Python:
import anyio
from claude_agent_sdk import query
async def main():
async for message in query(
prompt="Revisa el fichero facturas.csv y dime qué facturas llevan más de 60 días vencidas"
):
print(message)
anyio.run(main)
Y el equivalente en TypeScript:
import { query } from "@anthropic-ai/claude-agent-sdk";
for await (const message of query({
prompt: "Revisa facturas.csv y lista las vencidas a más de 60 días",
})) {
console.log(message);
}
Eso ya es un agente: lee el fichero, razona sobre el contenido y responde. A partir de ahí, el trabajo real consiste en añadir tus herramientas de negocio, acotar los permisos y escribir un system prompt que refleje cómo trabaja tu empresa de verdad. El SDK es una librería para Python y TypeScript; si tu stack va por otro lado, la vía soportada es ejecutar la CLI como subproceso en modo headless con salida en JSON, algo que funciona bien desde PHP, Go o Java.
Agent SDK, CLI, Client SDK o Managed Agents: cuál te toca
Anthropic mantiene cuatro formas distintas de trabajar con Claude de forma programática y elegir mal es la vía rápida a reescribir el proyecto a mitad. Esta es la comparativa a fecha de hoy:
| Si estás… | Usa | Por qué |
|---|---|---|
| Construyendo un agente sin querer implementar el bucle de herramientas | Agent SDK | Librería Python/TypeScript que ejecuta el bucle del agente por ti |
| Trabajando de forma interactiva o lanzando tareas puntuales desde terminal | Claude Code CLI | Interfaz de terminal pensada para el uso diario |
| Llamando a la API directamente y montando tú el bucle | Client SDK | Acceso directo a la API, con control total y también con todo el trabajo |
| Ejecutando agentes largos o asíncronos sin querer gestionar sandbox ni sesiones | Managed Agents | API REST alojada: Anthropic ejecuta el agente y el sandbox |
Para el 90% de los proyectos de empresa que llegan a nuestra mesa la respuesta es el Agent SDK: quieres tus herramientas, tus datos y tu infraestructura, pero no quieres mantener a mano el bucle de razonamiento ni la gestión de contexto. Un detalle importante si vas a integrar el agente en un producto propio: Anthropic no permite, salvo aprobación previa, ofrecer login o límites de claude.ai a terceros desde un agente construido con el SDK — la autenticación va con tu clave de API.
Ejemplo práctico: agente de gestión comercial para SuiteCRM
Imaginemos un agente construido con el SDK que automatiza la preparación de reuniones comerciales. El agente recibe el nombre de la empresa y la fecha de la reunión, luego consulta SuiteCRM para obtener el historial completo del contacto, busca noticias recientes sobre la empresa, analiza las oportunidades abiertas y su estado, revisa emails recientes intercambiados, y genera un briefing completo con talking points, objeciones probables y propuesta de siguiente paso.
Este agente, una vez configurado, se ejecuta automáticamente antes de cada reunión del equipo comercial, transformando minutos de preparación manual en segundos de preparación automática con contexto completo.
Cómo se monta eso de verdad
Bajando del ejemplo a la implementación, el proyecto se reduce a cuatro decisiones concretas:
- Qué herramientas expones. Aquí no se trata de dar al agente acceso a «la base de datos»: se trata de definir funciones acotadas — obtener_contacto, listar_oportunidades_abiertas, buscar_emails_recientes — cada una con parámetros tipados y un resultado predecible. Cuanto más estrecha es la herramienta, menos margen hay para que el agente improvise.
- Qué entra en el system prompt. No la documentación entera del CRM, sino lo que el modelo no puede deducir: cómo llamáis a cada fase del embudo, qué significa que una oportunidad esté en «propuesta enviada», qué tono usa el equipo comercial, qué no debe decirse nunca en un briefing.
- Qué permisos tiene. Lectura de CRM automática; escritura en el CRM, envío de emails o cambio de estado de una oportunidad, con aprobación explícita. Este límite se define una vez y se respeta siempre.
- Cómo se dispara. Un cron que mira la agenda del día anterior suele bastar, y es mucho más barato de mantener que un webhook por cada integración.
La parte que casi nunca se presupuesta bien es la cuarta pieza invisible: la observabilidad. Un agente que falla en silencio es peor que no tener agente, porque el comercial descubre que el briefing venía mal en mitad de la reunión. Con hooks puedes registrar cada llamada a herramienta y cada decisión en tu propio log, y eso es lo que permite auditar después por qué el agente dijo lo que dijo. La misma lógica que aplicamos al montar workflows de Claude sobre SuiteCRM.
¿Tienes un proceso que pide a gritos un agente?
En Keliam diseñamos, desarrollamos y mantenemos agentes con el Agent SDK integrados con tu CRM, tu ERP y tus herramientas internas. Empezamos siempre por un proceso concreto y medible, no por un piloto genérico.
Model Context Protocol (MCP) como estándar de integración
El Agent SDK se apoya en MCP (Model Context Protocol), un protocolo abierto que estandariza cómo los agentes se conectan con herramientas externas. Esto significa que un agente construido con el SDK puede conectarse a cualquier servicio que implemente MCP: CRMs, bases de datos, herramientas de comunicación, APIs de terceros y más.
Dónde está MCP en 2026
Cuando publicamos la primera versión de este artículo, MCP era todavía un protocolo joven y respaldado esencialmente por una empresa. Ese argumento ya no aplica. En diciembre de 2025 Anthropic donó el protocolo a la Agentic AI Foundation, bajo el paraguas de la Linux Foundation, y desde entonces la gobernanza es multiempresa, con compromisos públicos de producción por parte de AWS, Cloudflare y Google.
Los números acompañan a la gobernanza: en marzo de 2026 MCP superó los 97 millones de descargas mensuales de sus SDKs, frente a los cerca de 2 millones del lanzamiento en noviembre de 2024. El ecosistema ronda ya los 5.800 servidores MCP y más de 300 clientes, con despliegues en empresas como Block, Bloomberg o Amazon. Y en el lado corporativo, la extensión de autorización gestionada por la empresa pasó a estable, lo que permite controlar el acceso a los servidores MCP desde el proveedor de identidad que ya usas.
Para una empresa que valora el riesgo de plataforma, esto cambia la conversación: integrar por MCP dejó de ser apostar por el formato de un proveedor y pasó a ser adoptar un estándar con gobernanza independiente. Si quieres entrar al detalle técnico, lo desarrollamos en nuestra guía del protocolo MCP para integrar herramientas con IA.
Cuánto cuesta tener un agente en producción
La pregunta que siempre llega en la segunda reunión. El coste de un agente tiene tres capas y sólo una de ellas depende de Anthropic.
1. Tokens. Los precios de la API a septiembre de 2026, por millón de tokens de entrada y salida, son: Claude Haiku 4.5 a 1 / 5 dólares, Claude Sonnet 5 a 2 / 10, Claude Opus 5 a 5 / 25 y Claude Fable 5.1 a 10 / 50. Conviene señalar un detalle que ha despistado a mucha gente: el precio de 2 / 10 de Sonnet 5 se anunció como introductorio hasta el 31 de agosto de 2026, con una subida prevista a 3 / 15 a partir de septiembre, y esa subida finalmente no se aplicó. Si tienes una hoja de cálculo de costes hecha en primavera, revísala.
2. Optimizaciones que sí mueven la aguja. Los aciertos de caché se facturan al 10% del precio de entrada, y la Batch API reduce a la mitad tanto entrada como salida. En un agente cuyo system prompt y catálogo de herramientas son idénticos en cada ejecución — es decir, casi cualquier agente de negocio — la caché de prompt no es un extra: es la diferencia entre un coste asumible y uno absurdo. Y no hay comisión de plataforma por encima de eso.
3. Elección de modelo por tarea. El error caro es poner el modelo más potente en todo el bucle. Un patrón que funciona bien: Haiku para clasificar, extraer campos y decidir si algo merece atención; Sonnet para el razonamiento central y la redacción; y el modelo grande sólo donde la calidad del juicio justifica el precio. Con subagentes esto se implementa de forma natural, porque cada subagente puede correr con su propio modelo.
La capa que nadie factura pero todos pagan es la cuarta: mantenimiento. Un agente vive conectado a sistemas que cambian — el CRM añade un campo, la API de un proveedor cambia un formato, alguien renombra una fase del embudo — y sin alguien vigilando, la degradación es silenciosa. Es exactamente el tipo de riesgo que cubre un contrato de mantenimiento de software.
Seguridad y gobernanza: la parte aburrida que evita disgustos
Un agente es, por definición, software con capacidad de actuar sobre tus sistemas usando decisiones tomadas por un modelo a partir de datos que muchas veces vienen de fuera. Eso amplía la superficie de ataque de formas que no aparecen en los tutoriales.
Tres riesgos concretos
- Inyección de instrucciones vía contenido. Si tu agente lee emails, tickets o páginas web, alguien puede escribir ahí instrucciones dirigidas al agente. La defensa no es pedirle al modelo que se porte bien: es tratar todo lo que llega por herramienta como datos, nunca como órdenes, y exigir aprobación humana para cualquier acción con efecto (enviar, borrar, transferir, publicar).
- Exceso de permiso. Cada herramienta debe correr con las credenciales mínimas para su función. Un agente comercial que consulta el CRM no necesita un usuario administrador, aunque sea lo más cómodo de configurar el primer día.
- Trazabilidad ausente. Si no puedes reconstruir qué herramientas se llamaron, con qué parámetros y qué devolvieron, no puedes auditar un incidente. Los hooks del SDK existen precisamente para eso.
Si tu organización va camino de una certificación, estos controles no son opcionales: encajan directamente con los controles técnicos de ISO 27001 sobre desarrollo seguro, y merece la pena diseñar el agente ya alineado con ellos en lugar de reformarlo después. Para equipos que parten de cero en esto, nuestra guía de seguridad informática para pymes desde cero es un buen punto de partida, y las mismas precauciones sobre credenciales y permisos que explicamos para entornos n8n aplican palabra por palabra aquí.
Cuándo tiene sentido construir un agente personalizado
Un agente personalizado merece la inversión cuando tienes un proceso repetitivo que requiere razonamiento (no solo automatización mecánica), cuando el proceso necesita datos de múltiples fuentes, cuando la calidad del output depende del contexto específico de tu empresa, o cuando quieres escalar un proceso que hoy depende del conocimiento de personas específicas.
Checklist rápido antes de aprobar el proyecto
Si puedes responder que sí a al menos cuatro de estas seis, el proyecto tiene buena pinta:
- El proceso se ejecuta con frecuencia suficiente como para que ahorrar minutos importe.
- Existe una forma objetiva de comprobar si el resultado es correcto.
- Los datos que necesita ya están accesibles por API o base de datos, sin un proyecto de integración previo de seis meses.
- Hay una persona que hoy hace ese trabajo y puede explicar cómo decide — ese conocimiento es el system prompt.
- Un error del agente es recuperable y detectable, no irreversible.
- Alguien concreto será responsable de revisarlo cada mes.
Los tres errores que más veces hemos visto
Empezar por el proceso más complejo. El agente que «coordine todo el departamento» no llega nunca a producción. El que prepara un briefing antes de cada reunión sí, y además genera la confianza necesaria para el siguiente.
Confundir demo con producción. Un agente funciona a la primera con datos limpios de ejemplo. La distancia real está en los casos raros: el contacto duplicado, el campo vacío, la empresa con dos razones sociales. Ahí es donde se van las horas.
No medir nada. Sin una línea base de cuánto costaba el proceso antes, la discusión sobre si el agente merece la pena se vuelve una cuestión de opiniones. Medir el antes cuesta una tarde y salva el proyecto.
En Keliam diseñamos y desarrollamos agentes personalizados que se integran con sistemas de gestión comercial y herramientas de productividad con IA. Si tienes un proceso que podría beneficiarse de un agente inteligente, hablemos.
Conclusión
El Agent SDK ha madurado hasta el punto en que la pregunta ya no es si la tecnología aguanta, sino si el proceso que quieres automatizar está lo bastante claro como para que alguien —humano o agente— pueda ejecutarlo bien. El SDK resuelve el bucle de razonamiento, la gestión de contexto, los permisos y la conexión con herramientas externas mediante un MCP que hoy es un estándar con gobernanza independiente y adopción masiva.
Lo que sigue estando en tu tejado es lo de siempre: elegir un proceso concreto, definir herramientas estrechas, escribir bien el contexto de negocio, acotar permisos y dejar a alguien vigilando. Los agentes que fracasan casi nunca fracasan por el modelo. Fracasan porque nadie decidió con precisión qué tenían que hacer.



