Resonate: What If Async Await Survived the Crash

Last week we wrote about durable execution engines like Temporal, where a workflow replays its recorded history after a crash and picks up where it left off. It is a strong model, but it asks something of you: keep your workflow code deterministic, keep your side effects in activities, and run the engine that owns the truth.

Resonate starts from a different primitive. It takes the most familiar object in asynchronous programming, the promise, and makes it durable. A promise in Resonate is not a value living in your process memory. It is a record, identified by a string, that says a function was called, and eventually it will be completed with a result. That record survives everything.

The async complete protocol

The core idea is a protocol called async complete. Any function call in Resonate becomes two independent operations:

1. Async: someone invokes the function and gets back a durable promise keyed by an id.
2. Complete: some process, later, somewhere, resolves that promise with a result or an error.

Nothing says the process that starts a function has to be the one that finishes it. A request handler can create the promise and return the id to the client. A cron job three days later can complete it. A different language runtime can complete it. The promise just sits in the system, holding the contract open, until someone honors it.

// whoever creates it
const welcome = resonate.promise({ id: `welcome:${userId}` });
await resonate.rpc("sendWelcomeEmail", userId, { promise: welcome });

// whoever completes it, maybe days later, maybe in Python
await welcome.resolve({ sent: true });

The identifier is the coordination point. As long as two parties agree on the id string, they can hand work across processes, time, and networks without a shared queue or a shared runtime.

How it differs from the replay model

This is worth spelling out, because the two approaches solve the same problem with opposite mechanics.

In a replay based engine, the workflow is the unit of durability. The engine records every step and simulates your function's execution forward from that record. Your code runs many virtual times so it can run once in real time.

In Resonate, the promise is the unit of durability. There is no replay. If your process dies mid function, the function is simply gone, but its promise remains, and the timeout and retry rules attached to that promise decide what happens next: the call is retried, or another process picks it up, or it resolves to a fallback you specified. You compose reliability out of promises rather than replaying it out of history.

The practical consequences:

• Your code is plain async code. There is no determinism rule and no split between workflow and activity. Side effects go where they naturally belong.
• The protocol is transport agnostic and language agnostic. A Python worker can complete a promise created by a TypeScript handler, because the contract is the id and the record, not a shared runtime.
• Long waits cost nothing. A promise can sit pending for a month, and the system is not burning a process to wait for it.

Why the economics matter

Resonate's architecture is serverless native. Work only exists where code is actively executing, and the coordination layer is a lightweight state store rather than a cluster of workflow workers you keep warm. The docs make a bold claim about cost, hosted durable execution that costs tens of thousands per year running for under a hundred dollars. The exact numbers depend on your workload, but the structural reason is simple: pending promises are rows in a store, not processes on a bill.

For a small team, that difference can decide whether durable execution is something you adopt for everything or reserve for one critical flow.

And the agents

The newest pitch is also the strangest one: Resonate is built to be operated by AI agents, with CLIs over dashboards and machine readable specs. Whatever you think of the marketing, there is a real insight underneath. Durable execution systems already record everything an operator needs to know as structured facts. A system whose entire operational surface is "read and complete promises by id" is unusually legible, to a human on call or to an agent doing the paging.

When we would reach for it

The same test as last time applies, with one shift. If your problem is a long business process with many steps and you want the engine to own the whole narrative, a replay engine fits well. If your problem is coordination, functions that must outlive the process that started them, work handed between languages and services, and calls that wait days for an answer, the promise model fits with less ceremony.

And if a two second request handler is what you have, neither one is your tool. That is still just a handler.

The deeper pattern is the same one we keep returning to. Make the state of the system a fact that lives outside any single process, and failure stops being a catastrophe and becomes a Tuesday.

If you want to explore the protocol yourself, the official site is at resonatehq.io, and the documentation lives at docs.resonatehq.io.