Orquestación
Se convierten ejecuciones puntuales de agentes en flujos de trabajo repetibles y revisables.
Defina un flujo de trabajo como un DAG de nodos con tipo: hoy hay dieciséis tipos, entre ellos claude (una sesión de Claude Code), http_request, assert y wait_for_approval. Valídelo y luego ejecútelo. Cada ejecución produce un registro que puede observar en vivo y revisar después. Empiece desde una plantilla o constrúyalo en el lienzo. Todo está acotado por inquilino tras la seguridad a nivel de fila.
trigger
manual / cron
claude · plan
claude-code
http_request · ci
POST /builds
assert · green
ctx.ci.status
wait_for_approval
human · gate
Cómo funciona
1
Definir el DAG
Se disponen los nodos y las aristas entre ellos: un nodo claude lleva un prompt, un http_request una llamada, un assert una condición y un wait_for_approval una pausa a la espera de una persona.
2
Validar
El servidor comprueba el grafo (sin ciclos, cada dependencia se resuelve) antes de que se ejecute nada.
3
Ejecutarlo
Se inicia el flujo de trabajo manualmente o de forma programada. Cada nodo se ejecuta en orden, respetando sus dependencias.
4
Observar la ejecución
Se sigue el registro de la ejecución en vivo en el lienzo y el visor de ejecución, y se revisa la ejecución completada más tarde.
Análisis a fondo
Dieciséis tipos de nodo
El ejecutor despacha dieciséis tipos de nodo. claude corre una sesión de Claude Code a partir de un prompt; http_request llama a un endpoint; assert comprueba una condición y hace fallar la ejecución; wait_for_approval detiene la ejecución hasta que una persona la aprueba. El resto cubre control de flujo y datos: branch, retry, for_each, fan_out, aggregate, transform, set_variable, delay, log, notify, sub_workflow, wait_for_event. Se combinan en un DAG para encadenar planificación, cambios de código, comprobaciones y controles en una sola ejecución.
Tiempos de espera por tipo de nodo
Un nodo claude lleva un tiempo de espera (600 s por defecto); al superarse, el runner envía SIGTERM a la sesión, de modo que una sesión de Claude Code atascada no mantiene la ejecución abierta. Los demás tipos se acotan a su manera: http_request aborta su llamada (30 s por defecto, con un tope de 120 s), y wait_for_approval y wait_for_event se rinden al agotar su timeout_s (24 h por defecto). Un sub_workflow no tiene plazo propio.
Plantillas y lienzo visual
Se puede empezar desde una plantilla de inicio integrada y luego editar en el lienzo visual. El visor de ejecución muestra el estado de cada nodo a medida que avanza la ejecución.
Definir y ejecutar un flujo de trabajo
api · define and run a workflow
# A workflow is a JSON definition — start, nodes, edges.
$ curl -X POST https://app.acme.internal/api/fleet/workflows \
-H "authorization: Bearer $TOKEN" \
-d '{"name": "ci-triage", "definition": {
"start": "plan",
"nodes": [{"id": "plan", "type": "claude",
"prompt": "triage the failing build", "timeout_s": 900},
{"id": "check", "type": "assert", "expr": "ctx.plan.output"}],
"edges": [{"from": "plan", "to": "check"}]}}'
✓ graph validated on write — cycles and edges to unknown nodes rejected
$ curl -X POST https://app.acme.internal/api/fleet/workflows/WF_ID/run \
-H "authorization: Bearer $TOKEN"
{"run_id": "3c8a…"}
# Same two steps in the UI: the canvas at #/workflows,
# then the live run at #/workflow-runs/3c8a…
Orquestación auditable, no opaca.
Un flujo de trabajo es solo un DAG que puede leer, versionar y revisar. Cada ejecución queda registrada, así que se ve exactamente qué hizo cada nodo: nada de automatización de caja negra.
Comparativa
| Caldyr | Scripts de shell | CI genérico | |
|---|---|---|---|
| Nodos nativos de agente | sí | no | no |
| Validación del DAG antes de ejecutar | ciclos + deps comprobados | no | parcial |
| Registro de ejecución en vivo | lienzo + visor de ejecución | solo registros | solo registros |
| Tiempo de espera de nodo claude → SIGTERM | por nodo | manual | solo a nivel de tarea |
| Aislamiento por inquilino | acotado por RLS | no | ejecutores compartidos |
Preguntas frecuentes
Hoy hay dieciséis tipos de nodo. claude ejecuta una sesión de Claude Code a partir de un prompt; http_request llama a un endpoint; assert comprueba una condición; wait_for_approval espera a una persona. Los demás son control de flujo y transporte de datos: branch, retry, for_each, fan_out, aggregate, transform, set_variable, delay, log, notify, sub_workflow, wait_for_event. Se conectan en un DAG y se enlaza la salida de cada nodo con el siguiente a través de sus dependencias.
Un nodo claude lleva un tiempo de espera —600 s por defecto— y, al superarse, el runner envía SIGTERM a la sesión, de modo que una sesión de Claude Code atascada se detiene en lugar de mantener abierta toda la ejecución. Los demás tipos se acotan de otra forma: http_request aborta su propia llamada (30 s por defecto, con un tope de 120 s), wait_for_approval y wait_for_event se rinden al agotar su timeout_s (24 h por defecto), y un sub_workflow no tiene plazo propio.
No. Hay plantillas de inicio para clonar y un lienzo/editor visual para ajustar el grafo. También puede definir un flujo de trabajo como una definición y ejecutarlo vía la API.
No. Los flujos de trabajo y sus ejecuciones están acotados por inquilino y se aplican con seguridad a nivel de fila en Postgres, así que solo son visibles dentro de la empresa que los posee.
¿Listo para orquestar sus agentes?
Solicite acceso en minutos, o hable con nosotros sobre sus patrones de flujo de trabajo.