The problem: most workflow engines (Temporal, Airflow, Prefect) require heavy infrastructure, custom DSLs, or replay-based execution that forces determinism constraints on your code. Replay means re-executing your entire workflow history on every recovery — and you can't freely call external APIs or use arbitrary libraries without careful wrapping.

Sayiir takes a different approach: continuation-based execution.

- On crash recovery, it resumes from the last checkpoint — not from the beginning. No replay overhead. - No determinism constraints. Your tasks can call any API, use any library. No purity rules, no sandboxing. - No DSL. Workflows are composed with native language constructs — a workflow! macro in Rust, a fluent builder in Python/TypeScript. - Pluggable persistence. PostgreSQL backend is stable, codec layer supports JSON or zero-copy binary (rkyv).

Architecture: the core is a graph-based execution engine in pure Rust (hexagonal architecture). Python bindings via PyO3/maturin, Node.js via NAPI-RS. Everything is stable — core, Python, Node.js, and Postgres backend.

I chose continuation-driven over replay-driven because replay engines pay a growing cost as workflow history lengthens, and they push complexity onto developers (determinism rules, versioning). Continuations checkpoint state at each step boundary, so recovery is O(1) — just deserialize and go.

Try it live in the playground: https://docs.sayiir.dev/playground/

Docs: https://docs.sayiir.dev crates.io: https://crates.io/crates/sayiir-runtime Discord: https://discord.gg/A2jWBFZsNK

MIT licensed. Looking for contributors, early adopters, and feedback. Happy to answer any questions about the architecture or tradeoffs.