Cada Equipo que Conozco Pasó Meses Cableando un Prompt a una Función y Llamándolo "Agente". Anthropic Acaba de Enviar el Agente Mismo — con su Loop de Producción Completo — como Dependencia de TypeScript
*El mundo no está construyendo agentes. Está reimplementando un loop que ya está resuelto.*
La mayoría de vosotros habéis construido "agentes" así: llamada al modelo, prompt gigante, un bucle manual que parsea tool calls, maneja errores, reintenta, gestiona contexto... y reza por que en producción no se rompa.
Eso era razonable en 2024.
En 2026, Anthropic ha distribuido como paquete npm (`@anthropic-ai/claude-agent-sdk`) el mismo loop de agente que potencia Claude Code. El agente planifica, usa herramientas y itera de forma autónoma. No es una API de chat con esteroides. Es el agente entero, empaquetado, versionado y mantenido.
Esto ya no es un problema de ingeniería. Es un problema de configuración.
Y casi todo el mundo lo está haciendo mal.
<br>
El Problema: Seguís Pagando el Peaje de una Abstracción que ya no Necesitáis
El argumento convencional dice que construir un agente significa elegir un framework de orquestación — LangChain, CrewAI, AutoGen, LangGraph — y montar tú mismo los prompts, las llamadas al modelo y las herramientas.
El SDK invierte esa suposición por completo.
❌ El enfoque heredado: Ciento cincuenta líneas de orquestación casera. Cada equipo reimplementa el plan-actúa-observa-itera a mano, lo depura durante semanas y lo rompe en producción.
✅ El enfoque del Claude Agent SDK: Importas el SDK, defines qué herramientas expones, qué permisos concedes y cuántas iteraciones permites. El loop — la parte más difícil, frágil y propensa a errores de cualquier agente — ya está escrito, endurecido y desplegado dentro de Claude Code.
El valor marginal de escribir tu propia orquestación colapsa.
Esto no es especulación. Es la diferencia entre reimplementar React a mano y usar React porque el DOM ya lo resuelve alguien que lleva años depurándolo en producción.
<br>
La Evidencia: El Loop es el Producto, no un Detalle de Implementación
Mirad lo que expone el SDK en su superficie pública. No es un constructor de prompts. Es la infraestructura del agente como API:
Dos modos de entrada que mapean a necesidades de control distintas:
`query()` — para un resultado simple y streameado
`streamQuery()` — para control granular del ciclo de vida con soporte de `AbortSignal`
Sistema de herramientas embebido: El SDK trae el toolset completo de Claude Code — `Bash`, `Read`, `Write`, `Edit` — sin que tengas que implementar ni uno. Las capacidades web y de búsqueda llegan vía conexiones MCP servers.
Gobernanza como parámetro de primera clase: `allowedTools`, `permissionMode`, y límites de ejecución como `maxTurns` y `maxTokens` son opciones de configuración, no ideas de último momento.
Persistencia de sesión: Hooks y checkpoints con `resume`. Una sesión se puede pausar, inspeccionar y continuar. No es fire-and-forget.
Aquí está el código mínimo de un agente funcional:
```typescript
import { query } from '@anthropic-ai/claude-agent-sdk';
const result = await query({
prompt: 'Revisa el fichero src/main.ts, encuentra las vulnerabilidades y aplícalas.',
options: {
allowedTools: ['Bash', 'Read', 'Edit'],
permissionMode: 'acceptEdits',
maxTurns: 25,
},
});
for await (const message of result) {
if (message.type === 'assistant') {
console.log(message.message.content);
}
}
```
Diez líneas. Un agente autónomo que lee, edita y ejecuta. Sin framework. Sin bucle manual. Sin orchestrator.
Si alguien te dice que necesitas LangChain para esto, te está vendiendo una abstracción que ya no necesitas.
<br>
El Análisis: Qué Significa que el Fabricante del Modelo Posea el Loop
Esto no es solo una mejora de developer experience. Es un cambio estructural del mercado.
Cuando el vendor del modelo posee el loop y opcionalmente el runtime — vía la gestionada Claude Agent API — el diferenciador para los desarrolladores deja de ser el código de orquestación.
*El diferenciador es la configuración.*
Qué herramientas expones. Qué permission modes activas. Cómo modelas los checkpoints para revisión humana. Esas son las superficies donde un agente real triunfa o fracasa.
Y hay una segunda implicación más profunda: las salvaguardas han dejado de ser un truco de prompt engineering.
Antes, la seguridad de un agente dependía de escribir "por favor, no ejecutes comandos destructivos" en el prompt. Ahora es un contrato enforceable y auditable vía `permissionMode` y `allowedTools`.
Eso es precisamente lo que hace que los agentes autónomos sean aprobables dentro de organizaciones reguladas. La seguridad ya no es una súplica al modelo. Es una propiedad de la API.
<br>
El Método del Permiso por Diseño: Cómo Llevar un Agente del Demo al Producto
Todos los tutoriales te enseñan a hacer el agente funcionar. Casi ninguno te enseña a hacerlo seguro, gobernado y recuperable. Ese es el salto del demo al producto. Yo lo llamo El Método del Permiso por Diseño, y tiene cinco pasos:
Paso 1 — Instala y verifica antes de escribir código de features.
Crea un proyecto Node/TypeScript, añade `@anthropic-ai/claude-agent-sdk`, configura credenciales y ejecuta un hello-world. Confirma el requisito de servidor Node — esto no se ejecuta en el navegador, comunica vía Server-Sent Events — y examina los entry points del SDK antes de tocar nada más.
Paso 2 — Elige tu modo de ejecución con intención.
Empieza en modo local con `query()`/`streamQuery()` contra la API del modelo. Solo más tarde evalúa la gestionada Claude Agent API si quieres que Anthropic opere el runtime, los reintentos y el escalado por ti.
Paso 3 — Limita el poder del agente antes de darle herramientas.
Esto es el corazón del método:
```typescript
import { streamQuery } from '@anthropic-ai/claude-agent-sdk';
const controller = new AbortController();
const result = await streamQuery({
prompt: 'Refactoriza el módulo de facturación manteniendo la API pública.',
options: {
allowedTools: ['Bash', 'Write', 'Edit'], // Solo lectura + edición acotada
permissionMode: 'default', // Pide confirmación para lo destructivo
maxTurns: 40, // Presupuesto de ejecución duro
maxTokens: 100_000, // Presupuesto de tokens duro
},
signal: controller.signal,
});
for await (const event of result) {
switch (event.type) {
case 'init': console.log('Sesión iniciada:', event.sessionId); break;
case 'agent_message': console.log('Agente:', event.message.content); break;
case 'tool_use': console.log('Tool:', event.name, JSON.stringify(event.input)); break;
case 'result': console.log('Tarea completada'); break;
}
}
// Para cancelar un agente desbocado a mitad de ejecución:
controller.abort();
```
Tratad los permisos como parte de vuestro diseño de API, no como una idea de seguridad de último momento. El `AbortSignal` aquí no es un extra. Es la diferencia entre un agente desbocado que cuesta tokens y uno que se puede detener.
Paso 4 — Añade capacidades reales vía tools y MCP, no engordando prompts.
Nada de prompt-hacking. Extender el agente es declarativo. Un custom tool se define con schema:
```typescript
// registrar.ts
import { query } from '@anthropic-ai/claude-agent-sdk';
// Con un MCP server, el agente descubre y llama las tools del protocolo estándar
const result = await query({
prompt: 'Consulta la base de datos de clientes y resume los impagos del último trimestre.',
options: {
mcpServers: {
postgres: {
command: 'npx',
args: ['-y', '@modelcontextprotocol/server-postgres'],
env: { POSTGRES_CONNECTION_STRING: process.env.DATABASE_URL! },
},
},
permissionMode: 'default',
},
});
```
Aquí está el giro estratégico: gran parte de la "ingeniería de agentes" se convierte en curación de MCP servers. Igual que la gestión de dependencias define la mayor parte del trabajo backend tradicional, declarar MCP servers define la mayor parte del trabajo con agentes. Reutilizas el ecosistema MCP existente en lugar de escribir código de conexión a medida para cada fuente de datos.
Y MCP es lo que evita el lock-in aburrido. No escribes connectors bespoke para cada API. Declaras servers y el agente consume lo que el ecosistema ya ofrece.
Paso 5 — Productiviza el ciclo de vida de la sesión.
Este es el paso que separa el demo del producto. Necesitáis:
1. Hooks para logging y aprobación humana — wire up un hook para auditar cada tool call
2. Persistencia de checkpoints — que una tarea larga se pueda pausar, inspeccionar y continuar
3. Resume para trabajos largos — sesiones recuperables, no fire-and-forget
```typescript
import { query } from '@anthropic-ai/claude-agent-sdk';
// Simula el control de sesión: hooks que pausan la ejecución
// y checkpoints que permiten inspeccionarla y resumirla
const result = await query({
prompt: 'Migra los datos del CSV antiguo a la nueva tabla normalizada.',
options: {
allowedTools: ['Bash', 'Read', 'Write', 'Edit'],
permissionMode: 'default',
hooks: {
PreToolUse: (hookInput) => {
console.log('[AUDIT] Tool a punto de ejecutarse:', hookInput.toolName);
// Devuelve approval para controlar ejecuciones sensibles
return { behavior: hookInput.toolName === 'Bash' ? 'deny' : 'allow' };
},
Stop: async () => {
console.log('[CHECKPOINT] Guardando estado de sesión...');
// Persiste aquí el checkpoint para un futuro resume
},
},
maxTurns: 60,
},
});
for await (const message of result) {
if (message.type === 'result') {
console.log('Resultado final:', message.result);
}
}
```
Aquí es donde el SDK demuestra que no es solo "el CLI de Claude Code con gabardina". Un wrapper de subprocess o una llamada chat cruda no exponen la superficie de embedding que sí expone el SDK: checkpoints, resume, hooks, permission modes y `AbortSignal`.
<br>
Objeción 1: "¿Y el lock-in? ¿Mis tool calls y mi estado pasan por infraestructura de Anthropic?"
Distinguid los dos modos, porque son muy distintos:
Modo local: El SDK ejecuta el loop en tu servidor Node. Las llamadas al modelo van a un endpoint compatible con Anthropic — incluyendo Bedrock o Vertex si ya estáis ahí. Tus tool calls y tu estado no pasan por la infraestructura gestionada de Anthropic.
Gestionada Claude Agent API: Anthropic opera el runtime, los reintentos y el escalado. Aquí sí, tus outputs de herramientas y estado intermedio viven en un runtime del vendor. Conveniente, pero cambia la forma de tus decisiones de portabilidad multi-modelo y residencia de datos.
La respuesta honesta no es fingir que no hay trade-off. Es ser explícito sobre qué deja tu control en cada modo. Si la residencia de datos es dura en tu sector, modo local con Bedrock/Vertex. Si quieres escalar sin operar infraestructura, gestionada.
<br>
Objeción 2: "¿Por qué no OpenAI Agents SDK, LangGraph o un framework abierto multi-modelo?"
Este es un trade-off, no una victoria. El Claude Agent SDK es TypeScript-first y está lockeado al modelo de Anthropic. A cambio compras comportamiento de agente turnkey y un runtime opinado.
❌ Elegís por moda: Framework que soporta 47 modelos porque "da flexibilidad". Nunca usáis 46 de ellos. Pagáis el coste de abstracción por un caso que no vais a tener.
✅ Elegís por criterio: ¿Estás comprometido con un solo vendor y quieres el loop más endurecido disponible? Claude Agent SDK. ¿Necesitas portabilidad multi-modelo como requisito arquitectónico real — no hipotético? Evalúa LangGraph o semejantes.
La pregunta no es "cuál es mejor". Es "¿cuánto vale un loop endurecido para ti y qué estás dispuesto a ceder en portabilidad?".
<br>
Objeción 3: "Ya puedo hacer shell out al CLI de `claude` o llamar a la API con mi propio loop. ¿Qué añade un SDK?"
El CLI te da un agente, pero no te da una superficie de integración. No puedes exponer programáticamente checkpoints, hooks, `permissionMode` ni `AbortSignal` desde un subprocess wrapper.
Un raw chat call te da un modelo, pero te obliga a ti a reimplementar el loop entero — planificación, iteración, gestión de contexto, manejo de errores.
*El SDK no es el agente en otro formato. Es la superficie de embedding que ni el CLI ni una chat call te dan.* Y es un agente mantenido y versionado, no un prompt loop que forkaste en 2024 y que arrastras desde entonces.
<br>
Conclusión: La Ingeniería de Agentes se Ha Convertido en Configuración
Lo que os llevó meses construiros — el loop de plan-actúa-observa-itera — ahora es una dependencia que actualizáis con `npm install`.
El trabajo que queda es más interesante, no menos. Diseñar qué herramientas exponer. Definir los límites de permisos como parte del diseño de API. Modelar checkpoints para revisión humana. Construir harnesses de evaluación que midan a vuestro agente contra casos reales.
Las claves para llevarte hoy:
El loop es el producto. Dejad de reimplementarlo.
Los permisos no son una idea de último momento. Son tu diseño de API.
MCP es vuestra capa de integración. Curación de servers, no código bespoke.
Los checkpoints y hooks separan el demo del producto.
Sed explícitos sobre qué modo de ejecución usáis — y qué sale de vuestro control en cada uno.
En 2024, construir un agente era un problema de ingeniería que casi nadie resolvía bien. En 2026, es un problema de configuración que casi cualquiera puede ejecutar — si entiende qué configurar y por qué.
Los que sigan cableando prompts y funciones a mano dentro de dos años no estarán "construyendo agentes". Estarán pagando el peaje de una abstracción que ya nadie necesita.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF