Claude Code Routines: agentes en la nube programados, subrutinas y corrutinas

Esta es la guía en profundidad. Para una visión general de cinco minutos, lee la entrada de blog complementaria.

1. Por qué importan los agentes programados

Hasta hace poco, un agente de programación con IA solo trabajaba mientras alguien lo observaba. Abrías un terminal, le dabas una tarea, aprobabas sus acciones y leías el resultado. Al cerrar la sesión, el trabajo se detenía. Ese modelo encaja con el trabajo exploratorio, pero buena parte del trabajo de ingeniería no es ni exploratorio ni urgente. Es recurrente: clasificar la cola de incidencias de la noche, comprobar que la documentación sigue coincidiendo con la API, revisar cada pull request con la misma lista de verificación, verificar un despliegue antes de que se cierre la ventana de publicación.

Los equipos que querían que un agente hiciera este trabajo de forma desatendida tenían que montar la infraestructura por su cuenta. Las opciones habituales eran un cron job en GitHub Actions, una máquina de sobra encendida en un armario o un motor de flujos de trabajo como Trigger.dev o n8n con una llamada a un agente añadida a posteriori. Todas funcionan, pero todas añaden infraestructura, credenciales, coste y mantenimiento en torno a lo que en realidad es una única instrucción: «haz esto cada noche y cuéntame qué has encontrado».

Las routines eliminan esa infraestructura. La programación, la capacidad de cómputo, el checkout del repositorio y el registro de auditoría viven dentro de Claude Code.

2. Qué es una routine

Anthropic define una routine como una configuración guardada de Claude Code. Tiene cinco partes:

• Prompt. La instrucción que Claude ejecuta en cada ejecución. Como no hay nadie presente para responder preguntas, debe ser autosuficiente y dejar claro qué significa «terminado». Aquí también eliges el modelo, que se utiliza en todas las ejecuciones.
• Repositorios. Uno o varios repositorios de GitHub. Cada uno se clona desde cero al inicio de cada ejecución, a partir de su rama por defecto salvo que el prompt indique otra cosa.
• Entorno en la nube. Controla el acceso a la red, las variables de entorno y un script de configuración opcional que instala dependencias. El resultado de la configuración se almacena en caché, así que no se vuelve a ejecutar cada vez.
• Conectores. Las integraciones MCP de tu cuenta de claude.ai, como Slack, Linear o Google Drive, en las que la routine puede leer y escribir.
• Disparadores. Uno o varios de estos: programación, API y evento de GitHub. Una misma routine puede combinar los tres.

Cada ejecución es una sesión completa de Claude Code en la nube. Puede ejecutar comandos de shell, usar las skills incluidas en el repositorio clonado y llamar a todas las herramientas de los conectores que hayas incluido. No hay selector de modo de permisos y nada espera aprobación. Esa autonomía es precisamente el objetivo, y también la razón por la que acotar el alcance es importante (consulta la sección 8).

3. Los tres tipos de disparador

3.1 Programación

El disparador más sencillo ejecuta la routine con una cadencia predefinida (cada hora, a diario, entre semana o semanalmente) o una sola vez en un momento futuro concreto. Conviene conocer algunos detalles:

• Hora local. Introduces las horas en tu propia zona horaria y Claude Code las convierte, de modo que una ejecución a las 09:00 ocurre a las 09:00 de tu reloj, esté donde esté el hardware en la nube. Algunas de las primeras guías de terceros afirmaban que las programaciones solo admitían UTC. La documentación de Anthropic dice lo contrario.
• Evita las horas en punto. Las ejecuciones programadas exactamente a la hora en punto pueden empezar con varios minutos de retraso. Elegir las 09:07 en lugar de las 09:00 ofrece una puntualidad más predecible.
• Cron personalizado. Para intervalos que no cubren las opciones predefinidas, como cada dos horas o el día uno de cada mes, elige la opción más cercana y ejecuta después /schedule update en la CLI para definir una expresión cron. El intervalo mínimo es de una hora; cualquier frecuencia mayor se rechaza.
• Ejecuciones puntuales. Describe el momento en lenguaje natural, por ejemplo /schedule in 2 weeks, open a cleanup PR that removes the feature flag. Claude confirma la marca de tiempo exacta antes de guardar. Una vez disparada, la routine se desactiva sola y se marca como Ran. Las ejecuciones puntuales no cuentan para el límite diario de ejecuciones.

3.2 API

Un disparador de API da a la routine su propio endpoint HTTPS. Cualquier sistema capaz de hacer una petición POST autenticada puede iniciar una ejecución: una herramienta de alertas, un pipeline de despliegue, una página de administración interna. El token se genera en la interfaz web, se muestra una sola vez, está limitado a esa routine y puede regenerarse o revocarse en cualquier momento.

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<ROUTINE_TRIGGER_ID>/fire \
  -H "Authorization: Bearer <ROUTINE_TOKEN>" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Error rate on checkout-api above 5% for 10 minutes."}'

La respuesta contiene un ID de sesión y una URL de sesión que puedes abrir para seguir la ejecución en directo. El campo opcional text transporta contexto específico de la ejecución. Los equipos atentos a la seguridad deben tener en cuenta que Claude Code envuelve este texto en un bloque <routine-fire-payload> y lo etiqueta como datos no fiables. Claude no seguirá instrucciones contenidas en él a menos que el prompt guardado de la propia routine le indique que use el payload. Si tu routine debe actuar sobre el cuerpo de una alerta, el prompt debe decirlo explícitamente, por ejemplo: «Investiga la alerta descrita en el bloque routine-fire-payload». Este diseño implica que un token filtrado permite a alguien iniciar una ejecución, pero no reescribir las instrucciones de la routine.

El endpoint está detrás de una cabecera beta con fecha. Anthropic afirma que los cambios incompatibles se publicarán con nuevas versiones de la cabecera y que las dos versiones anteriores seguirán funcionando para dar tiempo a los clientes a migrar.

3.3 Eventos de GitHub

Un disparador de GitHub inicia una nueva sesión cada vez que se produce un evento coincidente en un repositorio conectado. Requiere que la Claude GitHub App esté instalada en ese repositorio. Se admiten dos categorías de eventos:

• Pull request: abierta, cerrada, asignada, etiquetada, sincronizada y otras actualizaciones.
• Release: creada, publicada, editada o eliminada.

Los filtros acotan qué eventos cuentan. Puedes filtrar por autor, título, cuerpo, rama base, rama head, etiquetas, estado de borrador y estado de fusión, con los operadores equals, contains, starts with, is one of, is not one of y matches regex. Deben cumplirse todas las condiciones. Un error habitual: matches regex evalúa el campo completo, así que para captar cualquier título que contenga «hotfix» necesitas .*hotfix.*, no hotfix.

Cada evento genera su propia sesión independiente, de modo que dos push a la misma pull request suponen dos ejecuciones. Durante la vista previa, los eventos de GitHub también están sujetos a límites por hora por routine y por cuenta. Los eventos que superan el límite se descartan hasta que se reinicia la ventana.

4. Crear una routine paso a paso

Puedes crear routines desde tres sitios: la web en claude.ai/code/routines, la sección Routines de la pestaña Code de la app Claude Desktop o la CLI. Los tres escriben en la misma cuenta, así que una routine creada en uno aparece en los demás al instante.

4.1 En la web

1. Abre claude.ai/code/routines y elige New routine.
2. Ponle nombre y escribe el prompt. Selecciona el modelo.
3. Añade los repositorios en los que debe trabajar Claude.
4. Elige un entorno en la nube. El entorno Default tiene acceso de red Trusted, que permite los registros de paquetes habituales, las API de proveedores cloud y los dominios de desarrollo. Si la routine debe llegar a tus propios servicios, ajusta primero los dominios permitidos del entorno.
5. Selecciona uno o varios disparadores. Para un disparador de API, guarda primero la routine; la URL y el token se generan después.
6. Revisa los conectores. Todos tus conectores vinculados se incluyen por defecto, y Claude puede usar todas sus herramientas, incluidas las acciones de escritura, sin preguntar. Quita todo lo que la tarea no necesite.
7. Elige Create y luego Run now para probarla antes de confiar en la programación.

4.2 Desde la CLI

En cualquier sesión local de Claude Code, /schedule (alias /routines) crea una routine programada mediante conversación. Claude pregunta por la cadencia, los repositorios y el prompt, y después la guarda en tu cuenta.

/schedule daily PR review at 9am
/schedule tomorrow at 9am, summarise yesterday's merged PRs
/schedule list
/schedule update
/schedule run
/schedule why did my nightly review do nothing this morning?

El último ejemplo resulta especialmente útil. Claude enumera las ejecuciones recientes de la routine, lee el registro correspondiente y explica lo ocurrido, incluidos los errores de herramientas y las denegaciones de permisos. Las versiones recientes de la CLI también pueden añadir un disparador de GitHub de forma conversacional una vez instalada la GitHub App. Los tokens de API, en cambio, solo pueden crearse o revocarse en la web.

Si /schedule no se reconoce, la causa casi siempre es la autenticación. Las routines requieren iniciar sesión con una suscripción de claude.ai. Una clave de API de Console, una variable de entorno ANTHROPIC_API_KEY o un inicio de sesión de un proveedor cloud como Amazon Bedrock ocultarán el comando. En los planes Team y Enterprise, un Owner también puede desactivar las routines para toda la organización.

5. Escribir prompts que resistan ejecuciones desatendidas

El prompt de una routine se parece más a un runbook que a un mensaje de chat. No hay nadie para aclarar ambigüedades, así que unas instrucciones vagas producen resultados vagos o, peor aún, acciones ejecutadas con aplomo que no pretendías. Compara:

Un buen prompt de routine especifica:

• Alcance: qué repositorios, qué franja temporal y qué elementos.
• Acciones permitidas: qué puede cambiar Claude y, no menos importante, qué no debe tocar.
• Resultado: el destino y el formato exactos, como un PR en borrador, un canal de Slack o un comentario en el gestor de incidencias.
• Condiciones de parada: qué hacer cuando no haya nada que hacer y cuándo darse por vencido.
• Gestión del payload: en los disparadores de API, si se debe usar el texto de activación y cómo.

Cuenta con ajustar una routine nueva dos o tres veces durante su primera semana. Lee las transcripciones, no solo la insignia de estado. Anthropic deja claro que un estado verde solo significa que la sesión se inició y terminó sin un error de infraestructura. No significa que la tarea tuviera éxito.

6. Subrutinas: estructurar el trabajo dentro de una ejecución

Anthropic no ofrece ninguna funcionalidad llamada «sub-routines». En Workstation usamos el término subrutinas (sub-routines) para un patrón de diseño que hace mucho más fiables las ejecuciones largas y desatendidas: el prompt de la routine actúa como orquestador y delega cada paso bien definido en un subagente o en una skill incluida en el repositorio.

Esto funciona gracias a dos componentes de Claude Code que viajan con tu repositorio:

• Subagentes: archivos Markdown con front matter YAML en .claude/agents/. Cada uno tiene su propio prompt de sistema, su lista de herramientas permitidas y un modelo opcional, y se ejecuta en su propia ventana de contexto. Al llamante solo le llega un resumen. Los subagentes pueden ejecutarse en paralelo y, por defecto, pueden delegar a su vez hasta tres niveles de profundidad.
• Skills: en .claude/skills/ empaquetan procedimientos reutilizables, como tu estilo de notas de versión o tu lista de verificación de revisión de seguridad, que Claude carga cuando son relevantes. Las routines usan las skills incluidas en el repositorio clonado.

Una routine de mantenimiento nocturno construida así podría tener este aspecto:

# Routine prompt (orchestrator)
1. Use the issue-triager subagent to label and assign issues opened since the last run.
2. Pick the single highest-priority bug labelled "good-first-fix".
3. Use the bug-fixer subagent to implement a fix on a claude/ branch.
4. Use the test-runner subagent to run the test suite; if it fails twice, stop and report.
5. Open ONE draft PR, using the release-notes skill for the description.
6. Post a three-line summary to #eng-nightly.

# .claude/agents/issue-triager.md
---
name: issue-triager
description: Labels and assigns new issues. Never edits code.
tools: Read, Grep, Glob
model: haiku
---
You triage GitHub issues. Apply area labels from CODEOWNERS and
assign the owning team. Return a table of issue, label and owner.

Las ventajas son prácticas. Cada ayudante ve solo lo que necesita, así que el contexto del orquestador se mantiene reducido y centrado durante una ejecución larga. Los permisos de herramientas son más restringidos en cada paso: el clasificador anterior no puede editar archivos en absoluto. Los modelos más baratos pueden encargarse de los pasos mecánicos. Y como los subagentes y las skills viven en el control de versiones, los cambios en el comportamiento de la routine pasan por la revisión de código como cualquier otro cambio.

7. Corrutinas: routines que cooperan

De nuevo, «co-routines» es un término nuestro, no una funcionalidad de Anthropic. Llamamos corrutinas (co-routines) a varias routines independientes que se pasan el trabajo unas a otras, como una cadena de producción que pasa una pieza de una estación a la siguiente. Las routines no pueden llamarse entre sí directamente ni comparten memoria. En su lugar, una routine produce un artefacto duradero que el disparador de otra routine vigila.

Una cadena típica:

1. Routine A (programación) clasifica el backlog las noches entre semana y abre un PR en borrador desde una rama claude/fix-….
2. Routine B (GitHub, pull_request.opened) está filtrada a ramas head que empiezan por claude/. Aplica la lista de verificación de revisión del equipo y etiqueta el PR.
3. Una persona revisa y fusiona. Este es el punto de aprobación.
4. Routine C (GitHub, pull_request.closed, merged = true) actualiza la documentación o porta el cambio a un SDK hermano y abre un PR de seguimiento.
5. Routine D (API) la llama el pipeline de despliegue tras la publicación. Ejecuta comprobaciones de humo y publica un veredicto de go o no-go. Si es no-go, abre una incidencia en el gestor, que la Routine A recoge la noche siguiente.

Los canales de traspaso, del más al menos estructurado:

• Eventos de GitHub: nativos, filtrables y totalmente auditables.
• Etiquetas y convenciones de nombres de ramas: enrutan el trabajo sin escribir código de integración.
• Llamadas a la API: desde la CI, la monitorización o herramientas internas, con el payload tratado como contexto no fiable.
• Un gestor de incidencias o artefacto compartido: una incidencia de Linear o una página de estado que lee la siguiente ejecución programada.

Diseña las corrutinas con cuidado. Usa filtros para que una routine nunca se dispare con su propia salida, por ejemplo excluyendo los autores o las ramas que crea. Mantén una fusión humana entre cualquier routine que escriba código y cualquier routine que lo despliegue. Recuerda que cada etapa consume el mismo límite diario de ejecuciones a nivel de cuenta y los mismos límites de eventos de GitHub. Si te ves construyendo lógica de ramificación, reintentos y distribución en paralelo entre muchas routines, has superado este patrón y un motor de flujos de trabajo dedicado es la mejor herramienta.

8. Seguridad y gobernanza

• Las routines actúan como tú. Las routines pertenecen a una cuenta individual de claude.ai y no se comparten con los compañeros. Los commits y las pull requests llevan tu identidad de GitHub, y las acciones de los conectores usan tus cuentas vinculadas. Trata una routine como un token de acceso personal con cerebro.
• Protección de ramas. Claude hace push a ramas con el prefijo claude/ por defecto. Se niega a hacer push a ramas protegidas, a ramas con un PR abierto de otra persona y a ramas que contengan commits de otras personas.
• Mínimo privilegio. Quita los conectores innecesarios. Mantén el acceso de red en Trusted salvo que se necesite un dominio concreto; las peticiones bloqueadas fallan con 403 y x-deny-reason: host_not_allowed. En los planes Pro y Max, guarda las claves de API como API credentials del entorno en lugar de variables normales, que son visibles para cualquiera que use el entorno.
• Entradas no fiables. Los payloads de la API y el texto de Run now llegan etiquetados como no fiables. El contenido obtenido durante una ejecución, como el cuerpo de las incidencias y las páginas web, mantiene el tratamiento normal frente a la inyección de prompts. Escribe prompts que indiquen a Claude en qué confiar.
• Estado de la conexión. Si la conexión con GitHub caduca, las ejecuciones se omiten durante un máximo de 72 horas y después la routine se desactiva sola hasta que vuelvas a conectarla.
• Control de la organización. Los Owners de Team y Enterprise pueden desactivar las routines para todos los miembros desde la configuración de administración.

9. Planes, uso y límites

Las routines consumen uso de la suscripción del mismo modo que las sesiones interactivas. El límite diario se aplica además de ese uso. Tu asignación actual se muestra en claude.ai/code/routines y puede cambiar durante la vista previa. Con los créditos de uso activados, las ejecuciones que superan el límite continúan como excedente medido; sin ellos, las ejecuciones adicionales se rechazan hasta que se reinicia la ventana. Las ejecuciones programadas puntuales no cuentan para el límite. Mientras una suscripción está en pausa, sus routines quedan en espera.

10. Routines frente a otras opciones de programación

10.1 Dentro de Claude Code

Las tareas de /loop están ligadas a la sesión y caducan a los siete días. Son ideales para vigilar una compilación o una pull request mientras trabajas, pero no sustituyen a una routine.

10.2 Fuera de Claude Code

• GitHub Actions es barato, vive junto al código y ofrece control total sobre el runner. El precio es YAML, gestión de secretos y mantenimiento de runners. Elige Actions para pasos de compilación deterministas y routines para el trabajo que requiere criterio.
• Los motores de flujos de trabajo como Trigger.dev gestionan reintentos, distribución en paralelo y orquestaciones de larga duración, pero la orquestación la escribes tú en código. Úsalos cuando el propio flujo de trabajo sea el producto.
• Las plataformas de integración como n8n y Zapier destacan moviendo datos entre herramientas SaaS. Las routines destacan razonando sobre código, registros y documentos. Ambas se combinan bien: un flujo de n8n puede llamar al endpoint de API de una routine.

11. Casos de uso que funcionan bien

• Depuración del backlog: etiquetado nocturno, asignación de responsables y un resumen por la mañana.
• Clasificación de alertas: la monitorización llama al disparador de API y Claude correlaciona la traza de la pila con los commits recientes y abre una corrección en borrador.
• Revisión de código a medida: tu propia lista de verificación en cada PR listo para revisión.
• Verificación de despliegues: comprobaciones de humo y análisis de registros tras cada publicación, con un veredicto final de go o no-go.
• Desfase de la documentación: un análisis semanal de los PR fusionados y PR de actualización para la documentación que hace referencia a API modificadas.
• Portabilidad de librerías: replicar los cambios fusionados de un SDK en su equivalente en otro lenguaje.
• Higiene de dependencias: una revisión semanal de paquetes obsoletos con un único PR de actualización probado.

Las routines son menos adecuadas para trabajo con frecuencia inferior a una hora, para tareas que necesitan una decisión humana a mitad de ejecución y para flujos de trabajo complejos con múltiples ramas y reintentos.

12. Cómo lo ha recibido la comunidad

La reacción ha sido dispar, aunque mayoritariamente positiva. InfoQ citó a ingenieros entusiasmados con la posibilidad de conectar la IA directamente a paneles de observabilidad y flujos de CI mediante webhooks. Otros se mostraron escépticos. Recordaron funciones de programación anteriores de Claude que solo se ejecutaban en la máquina del propio usuario y defendieron que la fiabilidad, la disponibilidad y los límites de cuota merecen atención antes que las funciones nuevas. Nuestra experiencia es que las routines están bien diseñadas en materia de seguridad, sobre todo en el tratamiento de payloads no fiables y la protección de ramas. Los principales riesgos operativos son unos conectores demasiado amplios y unos prompts poco específicos.

13. Cómo lo usa Workstation

En Workstation gestionamos automatización agéntica para clientes en DevOps, operaciones financieras y flujos de atención al cliente. Las routines encajan bien con nuestro enfoque: infraestructura determinista para la fontanería, IA para el criterio y una aprobación humana antes de que nada llegue a producción. Si quieres ayuda para diseñar cadenas de routines, bibliotecas de subagentes o la gobernanza que las rodea, habla con nuestro equipo.

14. Conclusiones clave

• Una routine es un prompt guardado, con repositorios, entorno, conectores y disparadores, que se ejecuta de forma autónoma en la nube.
• Los disparadores pueden ser una programación (mínimo una hora, hora local), una llamada a la API (token bearer, payload no fiable) o un evento de pull request o release de GitHub.
• Disponible en Pro, Max, Team y Enterprise, con límites diarios de ejecuciones además del uso normal. La funcionalidad sigue en vista previa de investigación.
• Usa subrutinas (subagentes y skills) para que una ejecución larga se mantenga centrada y con el mínimo privilegio.
• Usa corrutinas (routines que se pasan el trabajo mediante PR, etiquetas y llamadas a la API) para pipelines de varias etapas, con una fusión humana en medio.
• Acota estrictamente los conectores y el acceso de red, escribe los prompts como runbooks y lee las transcripciones.

Fuentes y lecturas adicionales

• Anthropic: Introducing routines in Claude Code (14 de abril de 2026)
• Documentación de Claude Code: Automate work with routines
• Documentación de Claude Code: Run prompts on a schedule (/loop)
• Documentación de Claude Code: Subagents
• Documentación de Claude Platform: Trigger a routine through the API
• InfoQ: Anthropic Introduces Routines for Claude Code Automation
• MindStudio: Claude Code Routines: How to Run Scheduled AI Agents Without a Server
• Tahir en Medium: What is Claude Code Routines?

Las routines están en vista previa de investigación. El comportamiento, los límites y la API pueden cambiar. Los datos de esta guía reflejan la documentación publicada por Anthropic a fecha de 25 de septiembre de 2026.