One platform for every workflow.

The deploy that watches itself

jobs:
  build:
    steps:
      - { name: compile, run: make release }
  deploy:
    depends_on: [build]
    steps:
      - { name: ship, run: ./deploy.sh staging }
  soak:
    depends_on: [deploy]
    wait_for_event: { event: alerts.fired, timeout: 14d }
  rollback:
    depends_on: [soak]
    if: ${{ !steps.soak.output.timed_out }}
    steps:
      - { name: undo, run: ./deploy.sh staging --rollback }
  promote:
    depends_on: [soak]
    if: ${{ steps.soak.output.timed_out }}
    approval:
      prompt: "Promote to production?"

One run owns the commit's whole life: it builds on the merge, deploys to staging, then waits two weeks for an alert that hopefully never comes. If one fires, the run rolls the deploy back; if the fortnight passes quietly, it gates production behind a human who answers when they get to it. The wait resolves once, to whichever arrived first, so a late alert can't unpick a decision already taken. Nothing holds an agent while any of this happens, and the whole decision trail is the run's own timeline. Most CI systems cap how long a job may run; workflow engines that can wait that long don't check out your repo or run your build.

The approval that waits three days

jobs:
  plan:
    steps:
      - { name: plan, run: terraform plan -out=tf.plan }
  review:
    depends_on: [plan]
    outputs:
      decision: decision
    approval:
      prompt: "Apply this plan to production?"
      fields:
        - { name: decision, type: select, options: [apply, discard] }
  apply:
    depends_on: [review]
    if: ${{ steps.review.output.decision == 'apply' }}
    steps:
      - { name: apply, run: terraform apply tf.plan }

The run parks on review holding no agent and no machine. Someone approves it on Monday, and what they picked in the form decides whether apply runs at all. Automation platforms handle the waiting but can't run your toolchain; build systems run the toolchain but can't wait.

The business event that runs real code

Publish a graph with a webhook trigger and it mints its own inbound URL and signing secret. The delivery becomes the run's input, and the run is an ordinary pipeline with your repo, your tools and your secrets:

jobs:
  provision:
    retry:
      attempts: 3
      backoff: 30s
    steps:
      - { name: provision, run: ./scripts/provision-tenant.sh "$CRYO_INPUT" }
  smoke:
    depends_on: [provision]
    steps:
      - { name: smoke, run: ./scripts/smoke-test.sh }

A signup in your payment provider ends up applying terraform, with retries and an audit trail, and nothing in between had to be glued together. Usually this shape needs one tool to catch the event and a second one to do anything real with it.

The agent loop that survives the process

#!/usr/bin/env bash
set -e

turn=1
while [ "$turn" -le 20 ]; do
  reply="$(cryo step "model-$turn" -- ./ask-model.sh "$goal")"
  [ "$reply" = "done" ] && break
  cryo step "tool-$turn" -- ./run-tool.sh "$reply"
  turn=$((turn + 1))
done

Every turn is a checkpoint. Kill the process mid-loop and the turns already taken return their recorded answers instead of being paid for twice, and the tool call they made doesn't run again. Put an approval gate inside the loop and the run parks there until a human answers. The model is wherever you point it - a hosted API, or an endpoint on your own hardware with no credential at all.