Waymark: a Postgres-only durable workflow engine for agent loops

Waymark, an open-source library for durable background jobs, was introduced on Hacker News on 5 November 2026. Its README says it lets tasks withstand server restarts, task crashes and long-running jobs, runs on Postgres with no other infrastructure, and supports Python first. The thread drew 79 points. It matters to AI teams because the author argues the same mechanism suits agent loops that call models and tools over minutes or days.

What it does

You write a workflow as an ordinary async Python class and the units of distributed work as functions marked as actions. The README's example fetches users, filters out inactive accounts and fans out emails in parallel. A separate process, the executor, runs the work against your Postgres database; nothing executes inline in your web server.

The README lists per-call retry policies and timeouts, branches and loops, parallel fan-out with asyncio.gather, durable sleeps that survive restarts "for a second or for a day", cron and interval schedules, and a built-in web page showing each workflow instance and its timeline.

How it differs from replay engines

The README contrasts Waymark with replay-based engines such as Temporal and Vercel Workflow. Those re-execute workflow code from the start on each step and return cached results for finished activities, which forces the code to be deterministic: no random numbers, no current-time calls, no side effects in workflow logic.

Waymark instead parses the workflow's run method into an intermediate form, lowers it to bytecode for a durable virtual machine, and snapshots that machine's state to Postgres as it goes. The README says the original definition is never re-run during recovery, and that code using unsupported patterns fails at compile time. It lists a few patterns that still slip past the compiler as known issues.

The agent angle, from the thread

A commenter asked whether durability helps agentic workloads where concurrency makes it painful to pick up where you left off. The project's author replied that it does: each LLM call and tool call becomes a checkpoint, and without durable execution you are left saving and restoring context from a database. The author said durable execution moves the agent's loop into the workflow body, and that long waits are another use. The README also links a separate wrapper around pydantic-ai for declaring agents. I have not tested any of this.

Limits and pushback

The README is direct about scope. It says do not use Waymark in production applications yet, because the spec is changing quickly. It says to avoid it for jobs needing acknowledgement in under 100 milliseconds, or for more than about 10,000 actions coordinated concurrently, and that Postgres is a hard dependency.

Commenters raised four objections. One said the documentation is too async-heavy and shows no synchronous usage; the author replied that sync code can be wrapped today, with some awkwardness. One worried that coupling to the user's Python code could break with newer Python versions or third-party packages. One asked for SQLite instead of Postgres; the authors said they are heavily reliant on Postgres. One asked what happens to a workflow sleeping for three days when its code is redeployed; the answer was that each running instance is pinned to the bytecode it started with, and that upgrading in-flight workflows is not built yet.

What to do with it

If you run agents that make many model and tool calls, ask what happens to a half-finished run when a worker restarts, and whether a retry repeats a paid model call or an email. Waymark is a way to see one answer, but only as a side-project trial for now. The pinned-version behaviour matters most for multi-day agent waits, so check that your own tooling has a rule for it.