Crea agentes autónomos con el SDK de Claude Code: guía práctica para desarrolladores

Voy a traducir el artículo al español latinoamericano manteniendo intacta la estructura Markdown.

Cómo crear agentes autónomos con el SDK de Claude Code: Guía práctica para desarrolladores

El SDK de Claude Code — llamado oficialmente Agent SDK — es una librería de Python y TypeScript que te permite controlar el motor agéntico completo de Claude Code de forma programática: sin terminal, sin una persona frente al teclado, solo tu aplicación llamando a una función asíncrona query() y recibiendo en streaming cada paso del trabajo del agente. Si has usado Claude Code de forma interactiva, el SDK te da ese mismo ciclo de leer archivos / editar código / ejecutar comandos como una librería componible que puedes integrar en pipelines de CI, bots de revisión de código, orquestadores multiagente o cualquier servicio backend.

Qué es el Agent SDK — y por qué existe

Claude Code es conocido como una herramienta de terminal. Escribes un prompt, el agente razona sobre tu base de código, invoca herramientas integradas (Read, Edit, Bash, Grep, entre otras) y te devuelve los resultados. Pero en el momento en que quieres automatizar ese ciclo — disparar una revisión en cada pull request, distribuir el trabajo entre múltiples subagentes especializados, o construir un producto sobre esa base — la CLI interactiva deja de ser la abstracción correcta. Necesitas una librería.

El Agent SDK llena ese vacío. Según la documentación oficial de Anthropic, expone "las mismas herramientas, el mismo ciclo de agente y la misma gestión de contexto que impulsan a Claude Code, programables en Python y TypeScript". Eso no es lenguaje de marketing — es la arquitectura literal. El SDK inicia el binario de la CLI de Claude Code como un subproceso administrado, se comunica con él vía stdio, y expone todo como un stream asíncrono de objetos de mensaje tipados que tu código puede consumir y ante los cuales puede reaccionar.

Esta distinción importa por varias razones:

Mismo motor, distinta interfaz. Cuando pasas de la CLI al SDK, no te estás moviendo a una herramienta menor o más simple. El SDK hereda todas las capacidades de la CLI — conectividad con servidores MCP, ciclo de vida de hooks, archivos de skills, memoria de CLAUDE.md, delegación a subagentes y el catálogo completo de herramientas.

El SDK ejecuta las herramientas por ti. Si usas el Anthropic Client SDK (el paquete de más bajo nivel anthropic de Python/JS) y quieres que Claude invoque herramientas, tienes que implementar tú mismo el ciclo de herramientas: llamar a la API, detectar una respuesta de uso de herramienta, ejecutar la herramienta, devolver el resultado, repetir hasta que Claude se detenga. El Agent SDK colapsa todo ese ciclo en un único async for message in query(...) — Claude decide qué herramientas invocar, las ejecuta dentro de su subproceso y sigue iterando hasta que la tarea esté hecha. Tú solo consumes el stream.

Diseñado para modo headless. Los avisos de permiso de la CLI — "¿permitir este comando bash?" — se quedan esperando la entrada humana. El SDK los reemplaza con una opción permissionMode y un conjunto de modos de permiso — por ejemplo acceptEdits para autoaprobar ediciones de archivos y bypassPermissions para ejecutar todo sin avisos en un entorno de CI en sandbox — además de un callback de aprobación programático para flujos personalizados. Los nombres exactos de los modos y su comportamiento están documentados en la referencia del SDK de Anthropic (consúltala para ver la lista vigente), pero el efecto es el mismo: tu automatización nunca se queda esperando una pulsación de tecla.

El mismo motor de Claude Code, dos interfaces: la CLI interactiva para trabajo con humano en el ciclo, el Agent SDK para automatización programática y headless donde tu aplicación controla el prompt y un modo de permiso reemplaza el diálogo de aprobación.

Instalación del SDK

Anthropic publica dos paquetes:

• TypeScript: @anthropic-ai/claude-agent-sdk (npm)
• Python: claude-agent-sdk (pip; requiere Python 3.10+)

El paquete de TypeScript incluye un binario nativo de Claude Code para tu plataforma, así que no necesitas instalar la CLI por separado. La autenticación se hace mediante una variable de entorno ANTHROPIC_API_KEY obtenida en la Consola de Anthropic. El SDK también es compatible con Amazon Bedrock, Google Vertex AI y Microsoft Azure AI Foundry — consulta la documentación de Anthropic para conocer los patrones de variables de entorno correspondientes.

Conceptos fundamentales

Entender cuatro conceptos cubre la gran mayoría del uso real del SDK.

1. La función query() y el stream de mensajes asíncrono

Toda interacción con el SDK comienza con query(). Le pasas un string prompt y un objeto options; a cambio obtienes un iterador asíncrono que emite objetos de mensaje tipados a medida que el agente trabaja. El ciclo termina cuando el agente finaliza o encuentra un error.

Los mensajes que recibes incluyen:

• AssistantMessage — el texto de razonamiento de Claude y las descripciones de las llamadas a herramientas
• ToolResultMessage — el resultado de cada ejecución de herramienta
• ResultMessage — el resultado final, con un campo subtype que indica éxito o fallo
• SystemMessage — eventos del ciclo de vida de la sesión (el subtipo init lleva el session_id)

En la mayoría del código en producción filtras por ResultMessage para extraer el resultado final y, opcionalmente, registras los bloques AssistantMessage para rastrear lo que hizo el agente.

2. Herramientas y allowedTools

El catálogo de herramientas integradas del SDK se corresponde directamente con las capacidades de Claude Code:

La opción allowedTools preaprueba un subconjunto de estas, otorgando al agente permiso para invocarlas sin ninguna verificación adicional. Un agente de auditoría de solo lectura podría listar únicamente ["Read", "Glob", "Grep"]; una automatización completa podría incluir ["Read", "Edit", "Bash", "Glob", "Grep"].

3. Modos de permiso

Los modos de permiso controlan qué ocurre cuando el agente quiere usar una herramienta que no está preaprobada en allowedTools:

• acceptEdits — autoaprueba ediciones de archivos y operaciones comunes del sistema de archivos; pide confirmación para todo lo demás. Ideal para flujos de desarrollo de confianza.
• dontAsk — deniega silenciosamente cualquier cosa que no esté en allowedTools. Ideal para agentes headless muy restringidos.
• bypassPermissions — ejecuta cualquier herramienta sin verificación. Úsalo solo dentro de un entorno en sandbox.

El SDK también expone un callback de aprobación programático para que puedas implementar lógica de aprobación totalmente personalizada, y los nombres de modo disponibles pueden ampliarse con el tiempo — consulta la referencia del SDK de Anthropic para conocer la lista vigente y oficial y el comportamiento exacto de cada uno. En CI, casi siempre usarás una configuración estrictamente acotada con denegación por defecto, o bypassPermissions dentro de un contenedor sandbox que tú mismo controles.

4. Sesiones, reanudación y contexto

Cada llamada a query() crea (o reanuda) una sesión. El session_id de la sesión llega en el primer SystemMessage con subtype === "init". Puedes capturarlo y pasarlo como resume: sessionId en una llamada posterior para retomar exactamente donde quedó la conversación — las mismas lecturas de archivos, el mismo historial de razonamiento, la misma ventana de contexto.

Así es como se construyen agentes multiturno: una llamada a query() analiza un módulo, captura el session_id, y una segunda llamada a query() (con resume) hace referencia a "eso" o "el archivo que acabas de leer" sin necesidad de volver a explicarlo. Las transcripciones de sesión se escriben en el disco local por defecto; para producción puedes acoplar un adaptador SessionStore respaldado por S3, Redis o Postgres para que las sesiones sobrevivan a reinicios de contenedores.

Patrón de construcción 1: Un bot de revisión de código para CI

Este es el caso de uso canónico de "automatización headless". En cada pull request, un job de CI hace checkout de la rama, ejecuta un agente que lee los archivos modificados y publica un comentario de revisión.

El flujo:

1. Un evento de PR dispara un workflow de GitHub Actions (o un job de GitLab CI).
2. El runner hace checkout de la rama y ejecuta tu script de revisión.
3. Tu script llama a query() con un prompt de revisión, allowedTools: ["Read", "Glob", "Grep", "Bash"], y permissionMode: "dontAsk".
4. Claude lee el diff, busca patrones, razona sobre los hallazgos.
5. El ResultMessage lleva el texto de la revisión; tu script lo publica en el PR mediante la API de GitHub.

La decisión de diseño clave es usar dontAsk con una lista de herramientas de solo lectura. El agente no puede escribir archivos ni hacer llamadas de red más allá de lo que permiten las herramientas, así que tu job de CI no puede fusionar commits accidentalmente ni llamar a APIs externas por error. Un límite maxTurns (fijado en las options) acota la profundidad del agente para que los ciclos descontrolados no consuman presupuesto.

Para ver la arquitectura ilustrada de este flujo, mira el diagrama a continuación.

Un pipeline de revisión de código totalmente automatizado. El agente del SDK se ejecuta dentro de un contenedor de CI con una lista de herramientas de solo lectura; los hallazgos regresan en streaming como un ResultMessage y tu código los publica como un comentario de PR en GitHub. El agente nunca escribe archivos, nunca sale del contenedor.

Puedes extender este patrón con hooks — una funcionalidad del SDK cubierta en nuestro análisis a fondo de los hooks de Claude Code — para registrar cada llamada a herramientas en un archivo de auditoría, bloquear la lectura de rutas de archivo específicas, o emitir telemetría estructurada junto con la revisión.

Patrón de construcción 2: Cadenas de herramientas multiagente

La opción agents del SDK te permite definir subagentes con nombre, cada uno con su propio prompt de sistema, lista de herramientas y permisos. Tu agente principal les delega trabajo a través de la herramienta integrada Agent. Los mensajes de los subagentes incluyen un campo parent_tool_use_id para que puedas rastrear exactamente qué delegación produjo cada fragmento del resultado.

Un ejemplo práctico: una cadena de agentes para auditoría de seguridad donde un subagente code-scanner busca posibles vulnerabilidades usando Grep y Glob, un subagente dependency-checker ejecuta Bash para consultar los metadatos de tus paquetes, y un agente coordinador sintetiza ambos informes en una auditoría unificada. Cada subagente tiene el acceso mínimo de herramientas necesario para su rol, lo que limita el radio de impacto si un subagente alucina un comando peligroso.

Las cadenas multiagente funcionan bien para tareas que se descomponen de forma natural: un agente por cada aspecto, cada uno con una lista de herramientas acotada, orquestados por un coordinador que solo necesita Read y Agent. Para una mirada más amplia sobre cómo las arquitecturas multiagente se combinan con funcionalidades de Claude Code como la memoria de CLAUDE.md y los archivos de skills, consulta nuestra guía de harness engineering.

Patrón de construcción 3: Pipelines de automatización headless

Más allá de la revisión de código, el SDK destaca en cualquier automatización recurrente donde el agente es un paso dentro de un pipeline más grande:

Auditorías nocturnas de dependencias. Un cron job llama a query() con un prompt para verificar paquetes desactualizados, ejecutar escáneres de seguridad y producir un informe estructurado. La herramienta Bash ejecuta npm audit o pip check; Read inspecciona los archivos de lock. El ResultMessage alimenta una notificación de Slack.

Traducción e i18n al fusionar un PR. Cuando se fusiona un PR, un webhook dispara un agente que lee los archivos de strings modificados con Glob y Read, produce versiones traducidas con Write, y abre un nuevo PR mediante Bash (ejecutando gh pr create).

Detección de anomalías en logs. Se canaliza la salida reciente de logs a un prompt de query(). El agente lee archivos de contexto adicionales si es necesario, razona sobre los logs y emite un hallazgo estructurado. No se requieren escrituras de archivos; una lista de herramientas de solo lectura es suficiente.

Sincronización de documentación. Después de fusionar PRs, un agente lee los archivos fuente actualizados y reescribe las páginas de documentación correspondientes, luego confirma los cambios. permissionMode: "acceptEdits" gestiona las escrituras de archivos sin pedir confirmación.

El hilo común: query() reemplaza una integración de LLM hecha a medida. No implementas un ciclo de herramientas, no gestionas ventanas de contexto manualmente, ni analizas la salida del modelo para decidir qué ejecutar a continuación. El agente se encarga de la orquestación; tú aportas el prompt y consumes el resultado.

Un ejemplo ilustrativo trabajado: Un agente que corrige errores

El quickstart oficial demuestra este patrón con claridad (el código a continuación sigue la API documentada — verifica la sintaxis exacta en la documentación de quickstart de Anthropic):

Python ilustrativo (verifica la API exacta en la documentación oficial):

# Illustrative — confirm exact import paths and option names in official docs
import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AssistantMessage, ResultMessage

async def run_bug_fixer(file_path: str):
    async for message in query(
        prompt=f"Review {file_path} for bugs that would cause crashes. Fix any issues.",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Edit", "Glob"],
            permission_mode="acceptEdits",
        ),
    ):
        if isinstance(message, AssistantMessage):
            for block in message.content:
                if hasattr(block, "text"):
                    print(block.text)
        elif isinstance(message, ResultMessage):
            print(f"Completed: {message.subtype}")

asyncio.run(run_bug_fixer("src/utils.py"))

TypeScript ilustrativo (verifica la API exacta en la documentación oficial):

// Illustrative — confirm exact import paths and option names in official docs
import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt: "Review src/utils.ts for crash-causing bugs and fix them.",
  options: {
    allowedTools: ["Read", "Edit", "Glob"],
    permissionMode: "acceptEdits",
  },
})) {
  if (message.type === "assistant" && message.message?.content) {
    for (const block of message.message.content) {
      if ("text" in block) console.log(block.text);
    }
  }
  if (message.type === "result") console.log("Done:", message.subtype);
}

Qué ocurre cuando esto se ejecuta: Claude lee utils.py (o .ts) usando la herramienta Read, razona sobre el código, identifica casos límite, y luego invoca Edit para insertar manejo defensivo. Ves el razonamiento y las llamadas a herramientas pasar en streaming como objetos AssistantMessage; el ResultMessage final indica que terminó. Todo el ciclo del agente — incluyendo volver a leer el archivo para verificar la edición — está gestionado por el SDK.

Esto es lo que hace al SDK distinto de llamar directamente a la API de modelos de Anthropic: no implementas la capa de ejecución de herramientas. Claude decide cuándo invocar Read, la invoca, recibe de vuelta el contenido del archivo y continúa razonando. El ciclo es autónomo.

Permisos, sandboxing y seguridad en producción

Ejecutar agentes autónomos en producción exige pensar cuidadosamente qué pueden tocar. El SDK ofrece varios controles en capas.

El acotamiento de herramientas es la primera línea de defensa. Si un agente no necesita Bash, no lo incluyas en allowedTools. Un agente con solo ["Read", "Glob", "Grep"] no puede modificar archivos, ejecutar comandos de shell ni hacer llamadas de red, sin importar lo que diga su prompt.

Los modos de permiso ofrecen una segunda barrera. dontAsk garantiza que cualquier cosa fuera de allowedTools sea denegada silenciosamente en lugar de generar un aviso. Esto es crítico en entornos headless — un aviso que se queda esperando la entrada del usuario detendrá tu pipeline.

La opción cwd limita el acceso del agente al sistema de archivos a un directorio específico. En entornos multiinquilino, pasa un directorio de trabajo por sesión para que los agentes de distintos inquilinos no puedan leer los archivos de otros.

El aislamiento entre inquilinos requiere pasos adicionales: fijar settingSources: [] para que ninguna configuración del sistema de archivos se filtre entre inquilinos; fijar CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 para evitar que se cargue la memoria automática; apuntar CLAUDE_CONFIG_DIR a una ruta por inquilino. Todo esto está documentado en detalle en la guía de hosting de Anthropic.

El sandboxing en contenedores es la capa exterior. Para agentes en producción que necesiten acceso a Bash, ejecuta el SDK dentro de un contenedor con la salida de red restringida a los dominios que explícitamente permitas. Proveedores como Modal, E2B, Cloudflare Sandboxes, Fly Machines y Vercel Sandbox se mencionan en la documentación de Anthropic como opciones para despliegues del SDK en sandbox.

maxTurns limita la cantidad de idas y vueltas de uso de herramientas, acotando tanto el costo como los ciclos descontrolados. Ajústalo según la complejidad esperada de tu tarea — una revisión simple de lectura de archivos podría necesitar entre 5 y 10 turnos; una refactorización compleja de varios archivos podría necesitar entre 30 y 50.

Para equipos que construyen hooks y flujos de permisos en producción, nuestra guía de hooks de Claude Code cubre en detalle el ciclo de vida de los hooks PreToolUse y PostToolUse, incluyendo cómo escribir callbacks de hooks que bloqueen, transformen o registren llamadas a herramientas antes de que se ejecuten.

MCP: Conectando el agente a sistemas externos

El SDK es totalmente compatible con el Model Context Protocol (MCP), que te permite conectar tu agente a cualquier sistema externo que exponga un servidor MCP: bases de datos, automatización de navegador, Jira, Slack, GitHub y cientos de servidores creados por la comunidad.

Configuras los servidores MCP en la opción mcpServers — cada entrada especifica un comando a ejecutar y argumentos opcionales. El SDK inicia esos servidores como subprocesos, y el agente puede invocar sus herramientas de la misma forma en que invoca las herramientas integradas. Así es como le das a un agente de revisión de código acceso a tu sistema de tickets, o conectas un agente de documentación a la base de conocimiento de tu empresa.

El modelo de permisos también se aplica a las llamadas a herramientas MCP — allowedTools puede incluir nombres de herramientas MCP, y permissionMode gobierna qué ocurre con las herramientas que no están listadas.

Trampas y errores comunes

Las sesiones son locales al subproceso por defecto. Las transcripciones de sesión viven en el disco local del host bajo ~/.claude/projects/. En despliegues en contenedores o con escalado horizontal, esto significa que el estado de la sesión se pierde al reiniciar o al reasignar de nodo. Usa un adaptador SessionStore para cualquier sesión que necesites reanudar entre contenedores.

El modelo de subprocesos tiene implicaciones de memoria. Cada sesión en ejecución es un subproceso separado. Ejecutar cincuenta sesiones concurrentes significa cincuenta procesos de Claude Code. La guía oficial sugiere aproximadamente 1 GiB de RAM por agente como punto de partida, pero el uso real de memoria depende de la duración de la sesión y de la actividad de las herramientas. Dimensiona tus contenedores en consecuencia y fija maxTurns para limitar la profundidad de la sesión.

Los grandes despliegues de subagentes en paralelo alcanzan límites de tasa. Si tu orquestador delega a veinte subagentes simultáneamente, es probable que alcances los límites de tasa de la API de Anthropic. Divide los despliegues amplios en lotes y agrega una pequeña demora entre cada envío.

bypassPermissions requiere un sandbox real. Este modo omite todas las verificaciones de permiso. Está diseñado para entornos totalmente controlados, como contenedores de CI donde tú controlas todo el contexto de ejecución. Usarlo en la máquina de un desarrollador — donde el agente tiene acceso a claves SSH, credenciales de nube y rutas de sistema de archivos arbitrarias — es un riesgo de seguridad.

El SDK de TypeScript incluye el binario de Claude Code; el de Python no lo necesita por separado. Pero ambos SDK están fijados a una versión específica de la CLI. Cuando actualizas el paquete del SDK, actualizas la CLI subyacente. Revisa el changelog antes de actualizaciones menores — los cambios de comportamiento incompatibles se anuncian ahí.

El texto de los prompts y las entradas de herramientas no se incluyen en las exportaciones OTEL por defecto. Este es un comportamiento de privacidad intencional. Si necesitas trazabilidad a nivel de prompt para depuración, debes activarla explícitamente mediante variables de entorno documentadas en la guía de observabilidad de Anthropic.

Las versiones antiguas del SDK pueden no ser compatibles con modelos nuevos. La documentación de Anthropic señala que los modelos recientes pueden requerir una versión reciente del SDK debido a cambios en la API del parámetro de thinking, así que un SDK desactualizado puede fallar con un modelo nuevo. Revisa siempre el changelog y fija una versión confiable al adoptar modelos nuevos.

El SDK frente a la CLI: ¿Cuál necesitas?

Para la mayoría de los desarrolladores, la respuesta es ambos — y eso es intencional.

La CLI interactiva es la herramienta adecuada para el desarrollo del día a día: explorar una base de código desconocida, resolver un bug complejo de forma interactiva, o ejecutar una refactorización puntual. El SDK es la herramienta adecuada para todo lo que necesite ejecutarse sin una persona presente: CI, tareas programadas, funcionalidades de aplicación y pipelines multiagente.

El SDK y la CLI no son productos que compiten entre sí. Los flujos de trabajo que desarrollas de forma interactiva con la CLI se trasladan directamente a la automatización con el SDK — las mismas herramientas, los mismos conceptos de permisos, el mismo sistema de memoria de CLAUDE.md y skills. Un flujo de revisión que prototipas hoy con claude en tu terminal se convierte mañana en un bot de CI impulsado por el SDK.

Para equipos que usan la versión web de Claude Code (cubierta en nuestra guía de Claude Code en la web), el SDK abre la puerta a combinar sesiones web con orquestación programática — inicia una tarea de larga duración desde la web, y luego engánchate a ella de forma programática desde tu backend.

Preguntas frecuentes

¿Qué es exactamente el SDK de Claude Code (Agent SDK)? Es una librería de Python (claude-agent-sdk) y TypeScript (@anthropic-ai/claude-agent-sdk) que expone el motor agéntico completo de Claude Code — herramientas, permisos, gestión de sesiones, subagentes, MCP — como una API asíncrona programable. Llamas a query(), pasas un prompt y options, y recibes en streaming el trabajo del agente como objetos de mensaje tipados.

¿Necesito tener Claude Code instalado para usar el SDK? Para el SDK de TypeScript, no — el paquete incluye un binario nativo de Claude Code. Para el SDK de Python, el paquete claude-agent-sdk gestiona la dependencia. Sí necesitas una clave de API de Anthropic desde la Consola de Anthropic.

¿Puedo usar el SDK con modelos distintos de Claude en la API de Anthropic? Sí. El SDK es compatible con Amazon Bedrock, Google Vertex AI, Microsoft Azure AI Foundry y Claude Platform en AWS mediante variables de entorno. También puedes enrutar las solicitudes a través de un proxy personalizado configurando ANTHROPIC_BASE_URL.

¿Cómo uso el SDK en un workflow de GitHub Actions? Agrega tu ANTHROPIC_API_KEY como secreto de GitHub Actions, haz checkout de la rama del PR en tu workflow, instala el paquete del SDK y ejecuta tu script de agente. Usa permissionMode: "dontAsk" con una lista allowedTools de solo lectura para que el agente no pueda modificar archivos en tu entorno de CI. La documentación de Anthropic también cubre una integración dedicada con GitHub Actions que automatiza la revisión de PR y el triage de issues sin necesidad de escribir código del SDK.

¿Cuál es la diferencia entre el Agent SDK y Managed Agents? El Agent SDK es una librería que ejecuta el ciclo del agente dentro de tu propio proceso e infraestructura. Managed Agents es una API REST hospedada donde Anthropic ejecuta el agente y el sandbox — tú envías eventos y recibes los resultados en streaming. El SDK es mejor para prototipado local y agentes que trabajan directamente sobre tu sistema de archivos; Managed Agents es mejor para producción cuando no quieres operar infraestructura de contenedores.

¿Cómo limito lo que el agente puede acceder? Usa allowedTools para restringir qué herramientas están disponibles, permissionMode: "dontAsk" para denegar todo lo que esté fuera de esa lista, y cwd para acotar el acceso al sistema de archivos a un directorio específico. Para despliegues multiinquilino, fija además settingSources: [] y CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

¿El SDK admite salida en streaming? Sí — el iterador asíncrono de query() transmite mensajes en tiempo real. Si no necesitas salida en vivo (para tareas en segundo plano o pipelines de CI donde solo te importa el resultado final), la documentación de Anthropic describe un modo de un solo turno que recopila todos los mensajes antes de devolver el resultado. Consulta Streaming vs. single-turn mode en la documentación oficial.

¿Puedo ejecutar varios agentes en paralelo? Sí. Cada llamada a query() genera un subproceso independiente. Puedes ejecutar N sesiones concurrentes — pero cada una es un proceso separado, así que aprovisiona la memoria en consecuencia y ten en cuenta los límites de tasa de la API. Para despliegues concurrentes de subagentes desde un mismo orquestador, agrupa tus envíos por lotes para evitar alcanzar los límites de tasa.

¿Qué ocurre si la sesión falla a mitad de la tarea? Por defecto, las transcripciones de sesión son locales al contenedor y se pierden al reiniciar. Para sobrevivir a los reinicios, configura un adaptador SessionStore (S3, Redis o Postgres) y pásalo en las options. Luego puedes reanudar la sesión por session_id en un contenedor nuevo.

Ejecutar agentes sin una configuración local

La propuesta de valor del SDK es la automatización — pero poner esa automatización en marcha requiere infraestructura real: un runtime de Python o Node, una clave de API, una estrategia de contenedores, una decisión de sandboxing, y tiempo dedicado al modelado de permisos antes de tu primer despliegue en producción.

Para los desarrolladores que quieren iterar sobre ideas de agentes sin esa sobrecarga de configuración, Happycapy ejecuta agentes al estilo de Claude Code directamente en el navegador. No hay instalación local, ni gestión de subprocesos, ni aprovisionamiento de contenedores. Tú aportas un prompt, Happycapy se encarga del entorno de ejecución — con acceso a más de 150 modelos y un sandbox seguro en la nube. Es una vía rápida para prototipar el comportamiento del agente que luego llevarás a producción con el SDK.

Comienza gratis en happycapy.ai

Guías relacionadas

• Claude Code Hooks: The Power-User Guide to Automating Your Agent
• How Claude Code Review Actually Works: Diffs, Hooks, and What the Agent Catches
• Claude Code Web: How to Run Claude Code in Your Browser (No Install)
• What Is Harness Engineering? Building Reliable AI Agent Harnesses (2026)