To add to the above - with Waymark, the durability of highly concurrent workflows specifically is where we shine - because under the hood we just have a state machine that we durable persist when it emits side-effects.

What this means is when you have an async fn that you spawn in a loop where each iteration also spawns a ton of async fns which in turn call actions - there's no separate bookkeeping to do parallel to the execution itself. No replays (unlike other tools like Temporal), meaning the thing just goes, as-is, and when it crashes it can load the state and resume from where it left off - without the need to match the state of the interpreter to the persisted state of execution graph. We just store the real, actual runtime state.

Yep, that’s exactly it. imo the main value add for agents:

- Each LLM call and tool call becomes a checkpoint. Without durable execution you're pretty much stuck doing db saves/restores if you detect that this agent might have a previous context window. Agent frameworks are fundamentally just harnesses around the underlying model: you `while loop` until some server gives you some payload back, you add that to your context window list, and you keep going until it terminates. Durable execution moves that loop into the workflow body itself (a quick example here https://www.waymark.sh/python/tutorials/building-a-from-scra...).

- Long waits. Sometimes you do want your agent to wait for an arbitrary amount of time (ie. wait for this compilation job to finish - look again in 5mins, or maybe 5 hours). Durable execution makes sure that sleep timer will wake up regardless of what happens in the system state.

- Easier monitorability. Instead of having to sift through interleaved logs to figure out what was going on, you can see every large function call with a clean input/output contract. Useful especially in tracing down raised Exceptions and the data flow that it took to get there. Good for agents and regular code alike.

Of course, if your system is largely idempotent or your agents are mostly classifiers that are working in short internals - a simple db save/restore can work perfectly well too.

Durable execution and orchestration are essential in some specialised uses, such as regulatory reporting for financial institutions, or other snapshot based data pipelines. The transition is happening, and temporal and conductor are the usual tools there, but good tools are not always behind good solutions to put it lightly.

I like this one, as in the context of workloads like these, going with anything more complex than a Postgres is overkill.