Orchestration
Turn one-off agent runs into repeatable, reviewable workflows.
Define a workflow as a DAG of typed nodes: sixteen types today, among them claude for a Claude Code session, http_request, assert and wait_for_approval. Validate it, then run it. Each run produces a run record you can watch live and review afterward. Start from a template or build it on the canvas. Everything is tenant-scoped behind row-level security.
trigger
manual / cron
claude · plan
claude-code
http_request · ci
POST /builds
assert · green
ctx.ci.status
wait_for_approval
human · gate
How it works
1
Define the DAG
Lay out the nodes and the edges between them: a claude node carries a prompt, an http_request node a call, an assert node a condition, a wait_for_approval node a human gate.
2
Validate
Before anything runs, the server checks the graph: no cycles, every dependency resolves.
3
Run it
Kick off the workflow manually or on a schedule. Each node runs in order, respecting its dependencies.
4
Watch the run
Follow the run record live in the canvas and run viewer, then review the completed run later.
Deep dives
Sixteen node types
The runner dispatches sixteen node types. claude runs a Claude Code session from a prompt; http_request calls an endpoint; assert checks a condition and fails the run; wait_for_approval parks the run until a person signs off. The rest cover control flow and data: branch, retry, for_each, fan_out, aggregate, transform, set_variable, delay, log, notify, sub_workflow, wait_for_event. Compose them into a DAG to chain planning, code changes, checks and gates into one run.
Timeouts per node type
A claude node carries a timeout (600 s by default); on breach the runner sends SIGTERM to the session, so a stuck Claude Code session can't hold the run open. Other types bound themselves in their own way: http_request aborts its call (30 s by default, capped at 120 s), wait_for_approval and wait_for_event give up after their timeout_s (24 h by default). A sub_workflow has no deadline of its own.
Templates & visual canvas
Start from a built-in starter template, then edit on the visual canvas. The run viewer shows each node's status as the run progresses.
Define and run a workflow
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…
Orchestration that's auditable, not opaque.
A workflow is just a DAG you can read, version, and review. Each run is recorded, so you can see exactly which node did what, no black-box automation.
Compare
| Caldyr | Shell scripts | Generic CI | |
|---|---|---|---|
| Agent-native nodes | yes | no | no |
| Pre-run DAG validation | cycles + deps checked | no | partial |
| Live run record | canvas + run viewer | logs only | logs only |
| claude node timeout → SIGTERM | per node | manual | job-level only |
| Tenant isolation | RLS-scoped | no | shared runners |
FAQ
Sixteen node types today. claude runs a Claude Code session from a prompt; http_request calls an endpoint; assert checks a condition; wait_for_approval waits for a person. The others are control flow and data plumbing: branch, retry, for_each, fan_out, aggregate, transform, set_variable, delay, log, notify, sub_workflow, wait_for_event. You wire them into a DAG and connect each node's output to the next via its dependencies.
A claude node carries a timeout — 600 s by default — and on breach the runner sends SIGTERM to the session, so a stuck Claude Code session is stopped instead of holding the whole run open. Other types bound themselves differently: http_request aborts its own call (30 s by default, capped at 120 s), wait_for_approval and wait_for_event give up after their timeout_s (24 h by default), and a sub_workflow has no deadline of its own.
No. There are starter templates to clone, and a visual canvas/editor to adjust the graph. You can also define a workflow as a definition and run it via the API.
No. Workflows and their runs are tenant-scoped and enforced with row-level security in Postgres, so they're only visible inside the company that owns them.
Ready to orchestrate your agents?
Request access in minutes, or talk to us about your workflow patterns.