Durable agents

One durable loop, reshaped — not rebuilt.

The agent loop has four things that change from task to task: the prompt, the model, the tools, and when it stops. Everything else — checkpointing, retries, resuming after a crash — is the substrate.

You fork one loop and reshape it, instead of building a new agent each time.

Tell us your stack →Open source under Apache 2.0.

Simple to build

Four things you change. Everything else, the substrate handles.

When you reshape the loop, there are really only four things you touch. Those four points are where one agent becomes different from another.

Everything else is the substrate doing its job underneath — and each tool call is itself a durable execution, so a tool that fails gets retried and a tool that waits can wait for days, with no timer state in your handler.

↻ your agent loop
01the system prompt
02the model it runs on
03the tools it can call
04when it's finished
everything else — checkpointing · retries · fan-out · resume — is the substrate

Multi-agent

One agent can call another — and a failure stays where it happened.

Real systems are rarely one agent. They’re an agent that calls another, that fans out to a few more — and that’s usually where things break: not in any single agent’s logic, but in the coordination between them.

In Resonate, every sub-agent runs in its own crash domain. If a child fails, it fails on its own — the parent stays standing and decides what to do, the same way you’d handle any error in ordinary code.

parent agent — stands
child ✓
child ✕ failed
child ✓
a child falls in its own crash domain · the parent decides what to do

Why one loop is enough

Already durable.

Every step the loop takes resolves to a durable promise — a record of what was done, written as it happens. The state that lets the work resume lives in that promise, not in the process running it.

So when the process hosting your agent cycles — a deploy, a crash, a pod rescheduled mid-run — the loop doesn’t start over. It comes back up, reads the last promise it kept, and continues from exactly there.

running
the loop · promisethe process · crashes & restarts
The loop’s progress lived in the promise,
not the process that died.

Runs on your infrastructure

It lives on your infrastructure, not behind someone’s API.

Resonate runs as a single binary on the infrastructure you already operate — no separate service to provision, scale, or babysit. It sits inside your stack, not behind an API you have to trust.

Its state lives in your own Postgres. And because that state is just rows, you can look at it directly: when an agent does something surprising, you read the promise store with plain SQL and see exactly what happened and where it stopped.

your infrastructure

▢ resonate — one binary

SELECT * FROM promises WHERE id = 'agent/run/42';

A protocol, not a product

A protocol you adopt, not a vendor you depend on.

Resonate is open source under Apache 2.0, and durable execution is a protocol — something you adopt and build on, not a vendor you hand your agents to and hope to get back.

There’s a public library of agent skills to start from, and an open Discord where people are already building. You can run it, read it, fork it, or build your own.

docs.resonatehq.io/spec ↗

the open specification — implement it in any language

Open source, no feature gatesPublic agent-skill libraryFork or build your own
Discord — agent builders, right now