Context
A workflow that cannot be restarted mid-flight is a demo. Tool-calling agents are the same engine with a probabilistic step: if you cannot recover assign / condition / emit_event, you will not recover a model call that timed out after it already posted to a CRM.
Enterprise Automation Platform is the durable half of that problem.
Decision
PostgreSQL owns executions. Redis is a delivery bus, not the record. The API commits the execution and an outbox row in one transaction. The scheduler publishes. The worker atomically claims only a queued execution.
API commit → outbox row → Redis publish → leased claim → success, retry, or dead letter
Transient failures retry with bounded exponential backoff. Exhausted failures become a dead letter an operator can inspect and replay.
What I rejected
Treating Redis as source of truth, and advertising exactly-once processing. A crash can duplicate a queue message. Connector adapters still need their own idempotency keys. I would rather say that in the README than pretend a queue made the world safe.
Failure scenario
The worker dies after the broker accepted the message but before the row left queued. Restart delivers the duplicate. The claim is a no-op. Work continues from PostgreSQL, not from whatever was in memory.
Evidence
Compose stack, worker lease tests, fencing tokens, and an operator recovery path for exhausted deliveries.
Inspect: Repository · Run locally