Refund workflow
Twelve nodes, three human gates. Small refunds go through automatically; mid-size route to a supervisor; large ones pause for finance. The graph IS the policy.
Workflows
Your operation, written down and running.
Versioned graphs. Replayable from any point. Resumable when a human steps in. The shape your process takes when it stops living in a wiki.
What it is
A workflow is where your operation actually lives — not in a runbook nobody reads, not in someone’s head, but as a graph that runs every time it is triggered.
Every workflow is versioned. You can compare v3 to v7. You can roll back. You can fork. You can pause one mid-run and inspect what it has in flight, then resume it tomorrow with the same state.
And because the graph is explicit, the auditor doesn’t need a diagram from your engineer. The workflow itself is the diagram.
What you get
- Versioned and diffable — compare two versions of a process
- Resumable from any point, even across days
- Native HITL gates pause the graph for human approval
- Every run reconstructible, replayable, exportable
What this looks like in practice
Incident triage
The workflow listens to alerts, enriches them with knowledge, classifies severity, then auto-resolves, opens a ticket, or pages someone — depending on the rule.
Client onboarding across a week
Kicks off when a contract is signed, pauses for KYC, resumes when documents come in, hands off to provisioning, ends with a welcome email. One graph, many days.