Cómo crear workflows de Claude automáticos

Hay una frase que circula y resume hacia dónde se dirige la codificación agéntica: el objetivo no es un mejor "prompt", sino un flujo de trabajo que se ejecute sin que tú lo supervises. La mayoría de la gente usa Claude como usa una ventana de chat. Escribes, esperas, lees, vuelves a escribir. Eso funciona, pero limita tu producción a un agente que estás cuidando activamente. Los ingenieros que están obteniendo un verdadero provecho de Claude han construido algo diferente: flujos de trabajo que se inician según un horario o un desencadenante, realizan el trabajo, verifican sus propios resultados y solo avisan a un humano cuando algo necesita una decisión.

En resumen

Un flujo de trabajo de Claude que se ejecuta sin tu intervención necesita cinco partes: una especificación escrita precisa, ejecución sin interfaz (no interactiva), una puerta de verificación determinista que decida si pasa o falla, barandales estrictos (listas blancas de permisos, iteraciones limitadas, límites de costos, un interruptor de apagado), y una entrega que notifique a un humano o escale en caso de fallo. El modo sin interfaz de Claude Code (claude -p), el SDK de Agente de Claude, los ganchos (hooks) y un programador (cron o launchd) te proporcionan los cinco. El agente no es la parte arriesgada. Ejecutarlo sin supervisión sin una puerta y barandales sí lo es. Construye eso primero, y luego suelta las manos.

Por qué "se ejecuta sin ti" es el verdadero objetivo

El chat supervisado tiene un límite difícil: tú. Cada iteración espera a que un humano lea la salida y decida qué sigue. El modelo genera en segundos, luego permanece inactivo durante minutos mientras cambias de contexto. Eres el cuello de botella en un sistema que, de otro modo, es rápido.

Los flujos de trabajo desatendidos eliminan ese límite. El agente trabaja, un script lo verifica, los fallos se redirigen automáticamente y tú solo intervienes en los bordes. La recompensa no es solo la velocidad. Es el paralelismo. Una vez que un flujo de trabajo se ejecuta sin supervisión, escalas añadiendo flujos de trabajo, no escribiendo más rápido. Ese es el mismo salto que cubrimos en flujos de trabajo dinámicos de Claude Code, donde una sesión se ramifica en muchos agentes paralelos.

Pero "se ejecuta sin ti" aumenta las apuestas. Un agente supervisado que comete un error de edición es detectado cuando lees la diferencia. Uno desatendido lo comete, ejecuta el siguiente paso y sigue adelante. Así que la disciplina cambia de la elaboración de "prompts" al diseño de sistemas: estás construyendo una máquina que tiene que ser correcta, delimitada y observable cuando nadie la mira. El artículo de Anthropic sobre la construcción de agentes efectivos defiende el mismo argumento. El apalancamiento proviene del entorno que rodea al modelo, no de un solo mensaje más inteligente.

Las cinco partes que todo flujo de trabajo desatendido necesita

Omite cualquiera de estas y el flujo de trabajo hará lo incorrecto con confianza o nunca se detendrá.

1. Una especificación precisa. Una descripción escrita de lo que se ha hecho que el agente lee al inicio de cada ejecución. Las especificaciones vagas producen trabajo vago. "Arreglar la API" falla; "el endpoint POST /orders devuelve 201, valida el cuerpo contra el esquema, rechaza los campos faltantes con 422" tiene éxito.
2. Ejecución sin interfaz. Claude tiene que ejecutarse sin un humano al teclado. Eso significa modo no interactivo, no la interfaz de chat.
3. Una puerta de verificación. Una comprobación determinista que devuelve aprobado o reprobado con una razón concreta: pruebas, una verificación de tipo, una validación de esquema, una prueba de contrato. Esto es lo que permite que el flujo de trabajo decida que realmente ha terminado en lugar de fiarse de la palabra del modelo.
4. Barandales. Listas blancas de permisos, un recuento máximo de iteraciones, un tope de costos, registro y un interruptor de apagado. Esto evita que una ejecución confusa cause daños mientras duermes.
5. Una entrega. Cuando el flujo de trabajo termina o se rinde, avisa a alguien. Una notificación, un borrador para revisión, una alerta de fallo. El silencio no es éxito.

Los tres del medio son donde la mayoría de las configuraciones son débiles. Construyamos cada uno con las herramientas que Claude te ofrece.

Los bloques de construcción de Claude

Modo sin interfaz (claude -p)

El modo de impresión de Claude Code ejecuta un "prompt" de forma no interactiva y sale. Esta es la base de todo flujo de trabajo desatendido. Le asignas una tarea, restringes sus herramientas, capturas la salida y sigues adelante.

claude -p "Implementa el endpoint de pedidos según spec.md, luego ejecuta la suite de pruebas" \
  --allowedTools "Edit,Write,Bash" \
  --output-format json \
  >> run.log 2>&1

El flag --allowedTools importa más de lo que parece. En la interfaz de chat apruebas cada acción manualmente. Sin interfaz, no hay nadie que apruebe, por lo que la lista blanca es tu único control sobre lo que el agente puede tocar. Comienza de forma restringida y amplía solo cuando confíes en la ejecución. El conjunto completo de flags se encuentra en la documentación de Claude Code.

El SDK de Agente de Claude

Cuando un comando de shell no es suficiente, el SDK de Agente de Claude te permite controlar Claude programáticamente desde Python o TypeScript. Obtienes el bucle en el código: envías una tarea, transmites el resultado, inspeccionas las llamadas a herramientas, decides si continuar. Así es como envuelves el flujo de control real alrededor del agente.

import { query } from "@anthropic-ai/claude-agent-sdk";

const MAX_ITERATIONS = 8;
let feedback = "";

for (let attempt = 0; attempt < MAX_ITERATIONS; attempt++) {
  for await (const msg of query({
    prompt: `${task}\n\nPrevious failures:\n${feedback}`,
    options: { allowedTools: ["Edit", "Write", "Bash"] },
  })) {
    // transmite/registra mensajes mientras el agente trabaja
  }

  const gate = runVerification();      // tu comprobación determinista
  if (gate.passed) break;              // listo
  feedback = gate.failures;            // el siguiente prompt se escribe solo
}

Las firmas exactas se encuentran en la documentación, pero la forma es lo importante: un bucle que vuelve a ejecutar el agente con el último fallo como el siguiente "prompt". Si estás decidiendo entre crear tu propio bucle o una opción alojada, nuestra comparación de agentes gestionados vs el SDK de Agente desglosa cuándo cada uno tiene sentido.

Ganchos para barandales deterministas

Los ganchos ejecutan tus propios comandos en puntos fijos del ciclo de vida de Claude, sin que intervenga ningún modelo. Son la forma en que aplicas reglas que el agente no puede sortear con la palabra. ¿Quieres que la suite de pruebas se ejecute después de cada edición de archivo? Un gancho PostToolUse lo hace de forma determinista.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm test --silent" }]
      }
    ]
  }
}

Dado que un gancho es código simple, no una solicitud al modelo, siempre se activa. Esa es la propiedad que deseas para los barandales en una ejecución desatendida. El agente no puede decidir omitirlo.

Un programador para activar las ejecuciones

Un flujo de trabajo que se ejecuta sin ti necesita algo que lo inicie sin ti. En un servidor es `cron`; en una Mac es `launchd`. De cualquier manera, estás lanzando el comando sin interfaz según un horario.

# todos los días laborables a las 7 am: ejecuta el flujo de trabajo de mantenimiento, registra todo
0 7 * * 1-5  cd /srv/api && claude -p "$(cat tasks/nightly-maintenance.md)" \
  --allowedTools "Edit,Bash" >> logs/run-$(date +\%F).log 2>&1

Esa es la columna vertebral de una configuración autónoma: un programador lanza Claude sin interfaz, el agente trabaja según una especificación, los ganchos y una puerta lo mantienen honesto, y los registros te dicen lo que sucedió.

Diseña el bucle, no el "prompt"

Aquí está la mentalidad que lo une todo. Deja de preguntar "¿qué debería decirle a Claude?". Empieza a preguntar "¿qué bucle haría que Claude se lo dijera a sí mismo?". El agente es un generador rápido sin un sentido fiable de si tiene razón. El bucle proporciona ese sentido a través de la puerta. Profundizamos en esto en deja de "prompting" a tu agente de codificación, construye el bucle en su lugar, y es la idea fundamental para el trabajo desatendido: la confianza del modelo deja de importar, solo el veredicto de la puerta lo hace.

Esta es también la razón por la que una especificación clara supera a un "prompt" inteligente. La misma especificación impulsa cada iteración y sirve como documentación. Un archivo design.md o AGENTS.md que captura la intención, las limitaciones y la definición de "terminado" le da al agente un objetivo estable en cada ejecución, en lugar de que tú tengas que reexplicar el contexto cada vez.

Un ejemplo práctico: mantenimiento desatendido de API

Hagámoslo concreto. Digamos que quieres un flujo de trabajo que mantenga un conjunto de endpoints de API sincronizados con su especificación OpenAPI, que se ejecute todas las mañanas y que nunca envíe un endpoint roto. Esta es la forma.

1. Especificación. El contrato reside en un archivo OpenAPI; el comportamiento reside en los casos de prueba. El agente lee ambos al inicio de la ejecución.
2. Disparador. Un trabajo cron a las 7 am activa Claude sin interfaz con la tarea de mantenimiento.
3. Generar. El agente reconcilia la implementación con la especificación: añade endpoints faltantes, corrige formas de respuesta que no coinciden, ajusta la validación.
4. Puerta. El flujo de trabajo ejecuta la suite de pruebas de la API contra el servicio en ejecución. Aserciones de estado, validación de esquema JSON en cada respuesta, comprobaciones de contrato contra la especificación. Los fallos vuelven estructurados: "Se esperaba 422 en la falta de customer_id, se obtuvo 500". "El campo de respuesta total es una cadena, el esquema dice número".
5. Bucle o escalada. ¿Puerta roja? El fallo estructurado se convierte en el siguiente "prompt" y el agente corrige la brecha específica, hasta el límite de iteraciones. ¿Verde? Abre un borrador de PR. ¿Sin más intentos? Archiva una alerta con el último fallo y se detiene.
6. Entrega. Un humano recibe un PR limpio para revisar o un informe de fallo preciso. Nunca un commit silencioso.

La puerta del paso 4 es lo que hace que todo el proceso sea seguro para ejecutarse sin supervisión. Sin ella, el agente edita el código y reporta el éxito basándose en su propia lectura, que es exactamente como los puntos finales rotos llegan a producción. Aquí es donde Apidog encaja en un flujo de trabajo autónomo: el diseño de la API, el esquema, el servidor de simulación y las pruebas automatizadas residen en un solo espacio de trabajo, de modo que la puerta y la especificación se mantienen sincronizadas por defecto. Apuntas la ejecución a un escenario de prueba de Apidog y el agente obtiene un aprobado/fallo validado por esquema en cada iteración. El servidor de simulación reemplaza las dependencias que no están activas, de modo que una ejecución a las 3 de la mañana no se bloquea esperando a un tercero inestable. Los equipos que conectan el acceso del agente a los puntos finales a través del depurador de agentes de IA de Apidog le permiten acceder e inspeccionar los puntos finales de la misma manera que lo haría un tester humano. Descarga Apidog si prefieres construir la puerta visualmente en lugar de codificarla manualmente.

Barandales que hacen seguras las ejecuciones desatendidas

Esta es la parte que separa un flujo de trabajo en el que confías durante la noche de uno que te despierta a las 3 de la mañana. Un agente sin supervisión necesita límites estrictos, no buenas intenciones.

• Listas blancas de permisos restringidas. Sin interfaz, la lista blanca es tu única puerta de entrada a lo que el agente puede hacer. Concede las herramientas mínimas que la tarea necesita. Nunca des a una ejecución desatendida comandos de shell ilimitados o destructivos sin un sandbox.
• Iteraciones limitadas. Limita el bucle. Una ejecución que no puede alcanzar una puerta verde en N intentos debe detenerse y escalar, no seguir funcionando indefinidamente.
• Un techo de costos. Los bucles desatendidos queman tokens sin que un humano se dé cuenta. Establece un límite de gasto y registra el gasto por ejecución. Un bucle que no converge debería activar el límite y detenerse. Nuestras notas sobre la reducción de los costos de tokens del agente se aplican directamente aquí.
• Protege la puerta. Mantén los archivos de prueba y la especificación fuera del conjunto de archivos que el agente puede editar. Si puede reescribir la prueba para que pase, has construido una máquina para falsificar el progreso.
• Un sandbox. Ejecuta el trabajo desatendido en un espacio de trabajo o contenedor aislado, no en la rama principal. Un "worktree" de git o una rama desechable contienen el radio de explosión de una mala ejecución.
• Registro y un interruptor de apagado. Captura cada ejecución en un registro que realmente leas, y mantén una forma de detener un trabajo a mitad de vuelo. No puedes depurar lo que no registraste.
• Aprobación humana en los bordes. "Sin ti" no significa "sin nadie, nunca". Pon a una persona al principio (aprueba la tarea) o al final (aprueba el PR), simplemente no en el bucle interno. Los patrones de cableado y los modos de fallo aquí se alinean con los patrones de cableado y trampas de las herramientas del flujo de trabajo agéntico.

La mayoría de estos se resumen en una regla: un agente desatendido debe ser capaz de hacer su trabajo y nada más. Restringe las herramientas, delimita el bucle, aísla el espacio de trabajo y haz que cada ejecución sea observable.

Errores comunes

Algunos patrones hunden rápidamente los flujos de trabajo autónomos.

• Sin puerta, solo sensaciones. Si la única comprobación es "¿agente, terminaste?", no tienes un flujo de trabajo, tienes un chatbot sin supervisión. La puerta debe ser externa al agente.
• Una tarea gigantesca. Una ejecución a la que se le dice que "mantenga todo el servicio" rara vez converge. Descompone en tareas del tamaño de un punto final, cada una con su propia puerta. Las ejecuciones pequeñas terminan; las grandes se agitan.
• Permisos de amplio alcance. Otorgar todas las herramientas porque es conveniente convierte un pequeño error en un gran incidente cuando nadie está mirando. Limita estrictamente la lista blanca.
• Éxito silencioso o fallo silencioso. Un flujo de trabajo que se compromete sin avisar a nadie, o muere sin una alerta, es peor que ningún flujo de trabajo. Siempre haz una entrega.
• Confiar en el autoinforme del modelo. El agente dirá que ha terminado. La puerta decide si lo ha hecho. Construye para la brecha entre "parece hecho" y "está hecho", porque desatendido, nadie está allí para detectarlo.

Haz esto bien y un flujo de trabajo de Claude hará el trabajo verificado y limitado de un día antes de que hayas tomado café. Hazlo mal y habrás automatizado la producción de código confiado y sin probar. La diferencia es la puerta y los barandales, no el modelo. Si quieres la arquitectura más profunda, nuestro desglose del diseño del arnés del agente cubre cómo encajan las piezas a escala.

La conclusión

Construir flujos de trabajo de Claude que se ejecuten sin tu intervención tiene menos que ver con Claude y más con el sistema que lo envuelve. Cinco partes soportan el peso: una especificación precisa, ejecución sin interfaz, una puerta de verificación determinista, barandales estrictos y una entrega limpia. Si lo haces bien, el modelo se convierte en un trabajador rápido dentro de una máquina que es correcta, delimitada y observable cuando no estás mirando.

Empieza con un flujo de trabajo. Escribe una especificación estricta, ejecútala sin interfaz contra una puerta de verificación rápida, permite las herramientas mediante lista blanca, limita las iteraciones, aísla el espacio de trabajo y haz que te notifique al finalizar o fallar. Para cualquier cosa que toque APIs, tu suite de pruebas es la puerta que hace seguras las ejecuciones desatendidas, y Apidog te ofrece el diseño, la simulación y las pruebas automatizadas en un solo espacio de trabajo para construirla. Descárgala, conecta la puerta y deja que el flujo de trabajo haga sus ciclos mientras tú haces otra cosa.