DBOS Explained: Durable Execution for Agent Harnesses

An AI agent that calls ten tools, waits an hour for a human approval, then writes to three systems has a problem that has nothing to do with how smart the model is. If the process dies at step seven, what happens? Most agent frameworks answer that badly: they lose the run, or they restart it from the top and repeat work that already had side effects. DBOS is one answer to that problem, and it comes from an unusually credentialed team, so it is worth understanding what it actually does before deciding whether an agent harness needs it.

This is the reliability layer of harness engineering, the part that sits underneath the tools and prompts and decides whether a long-running agent can be trusted in production at all.

What DBOS is

DBOS is an open-source library for durable execution. You import it into an application, point it at a Postgres connection string, and annotate functions as workflows and steps. From then on, DBOS records the progress of each workflow in Postgres so the program can recover from any failure without losing state or repeating completed work. According to the DBOS documentation, there is no separate server or cluster to deploy: the durability lives in the database you already run.

The project is not a weekend experiment. DBOS grew out of joint MIT and Stanford research and was co-founded by Michael Stonebraker, the Turing Award laureate behind Postgres and Ingres, with Databricks co-founder and Apache Spark creator Matei Zaharia serving as a founding advisor. The company raised 8.5 million dollars in seed funding in 2024 and open-sourced the DBOS Transact library the same year, starting with TypeScript. Per the DBOS documentation, the Transact library now ships for Python, TypeScript, Go, and Java, and the core library is free and open source.

For agent builders specifically, DBOS provides documented integrations with popular agent frameworks including Pydantic AI, LlamaIndex, and the OpenAI Agents SDK, so durable execution can wrap an existing agent rather than forcing a rewrite.

What durable execution means for an AI agent

Durable execution is a way of running a program so that its progress survives failure. The runtime records each completed step to durable storage as the program runs. If the process crashes, is redeployed, or restarts, the program resumes from the last completed step, returning already-saved results instead of re-executing them, rather than starting over or losing the run entirely.

For an agent, the payoff is concrete. A durable agent can call an expensive model, get the result, and never pay for that call twice even if the process dies a moment later. It can pause for a day while a human approves a high-stakes action, then wake up with full context. It can retry a failed tool call without redoing the six successful ones before it. Frameworks like LangGraph, Pydantic AI, and the OpenAI Agents SDK have all added durable execution as a first-class feature in 2026, which is a good signal that this stopped being optional infrastructure for agents that touch real systems.

Why a checkpoint is not durable execution

Here is the distinction that trips people up. Many agent frameworks already save state. LangGraph has checkpointers, CrewAI has a persist decorator, Google’s ADK uses event sourcing. It is tempting to conclude that durability is a solved problem. It is not, and the gap matters.

A 2026 analysis from Diagrid, a vendor in the durable-workflow space, puts it sharply: a checkpoint is a save point, and you, the developer, are responsible for detecting when to use it. The framework snapshots state, but it does not watch for crashes, does not automatically restart a dead run, and does not coordinate to stop two workers from resuming the same workflow at once. Saving state and guaranteeing completion are different problems.

Durable execution closes that gap by making completion the runtime’s job. The runtime detects interrupted work, replays it automatically, and skips steps that already finished. That is the line between a persistence feature and an execution guarantee, and it is the line DBOS is built to sit on.

How DBOS does it: Postgres as the source of truth

DBOS treats your Postgres database as the record of truth for what has run. Per the DBOS documentation, every workflow input and every step output is durably stored in a system table, at a cost of roughly one database write per step plus a small fixed overhead per workflow.

Recovery follows from that record. When DBOS restarts, it scans for workflows still marked pending and replays each one by calling it again with its saved inputs. As the replay runs, DBOS checks before each step whether that step’s output is already recorded. If it is, the step returns the stored result instead of executing again. The replay races forward through completed steps this way until it reaches the first step with no recorded output, which is exactly where the original run failed, and continues from there.

The practical consequence for an agent: a tool call or model call that already succeeded is never repeated on recovery, because its result is in Postgres. That is what makes the recovery safe rather than merely automatic. Because the state lives in the same database an application already uses, DBOS goes one step further for transactional steps: the DBOS documentation states that when a transaction runs inside a workflow, DBOS records its outcome atomically in the same database transaction as the step’s own writes. The record that a step ran and the effect of that step cannot drift apart.

Where durable execution fits in an agent harness

The recurring lesson of 2026 is that the harness around a model, not the model itself, decides whether an agent is useful. That is the thesis of this site’s harness engineering coverage and of the broader argument that the harness beats the model. Most of that work is about context, tools, and loops. Durable execution is the layer below all of it: the part that decides whether a run that takes hours can survive the things that happen over hours.

Three agent failure modes map directly onto what durable execution fixes:

• Long-running runs that outlive their process. An agent working through a multi-step task across an hour will meet a deploy, a timeout, or a crash. Without durability the run is lost. With it, the run resumes from its last completed step. This is the same problem Anthropic describes in its engineering writing on long-running agents, which the harness engineering guide covers from the context-management side.
• Human-in-the-loop pauses. An agent that must wait for approval before a costly or irreversible action needs to suspend for minutes or days and then continue with full state. Durable execution turns that wait into a normal, resumable step rather than a held-open process.
• Expensive, non-idempotent steps. Every repeated model call is money, and every repeated write to an external system is a potential duplicate order or double-sent email. Recording step results means a recovered run does not pay twice or act twice. That directly attacks the retry and idle overhead that drives the cost of running an agent in production.

What this looks like in code: a durable research agent

Here is the whole idea in plain terms. Think of a workflow as a to-do list, and each step as an item on it. When a step finishes, DBOS puts a checkmark next to it and saves the result in Postgres. If the power goes out mid-run, DBOS reads the list on restart, sees which items are already checked, skips straight past them using the saved results, and picks up at the first unchecked item. The expensive work behind a checked item, an LLM call or a paid API call, never runs a second time.

In DBOS for Python, that is two decorators. You mark the orchestration function with @DBOS.workflow() and each unit of real work with @DBOS.step(). Consider a small research agent that picks a search query, runs a web search, then summarizes the results, with two of those three steps being paid model or API calls.

from dbos import DBOS

@DBOS.step()
def choose_search_query(topic: str) -> str:
    # A paid LLM call: decide what to search for.
    return llm(f"Give one web search query to research: {topic}")

@DBOS.step()
def web_search(query: str) -> list[str]:
    # A paid tool call to an external search API.
    return search_api(query)

@DBOS.step()
def summarize(topic: str, results: list[str]) -> str:
    # A second, expensive LLM call.
    return llm(f"Summarize these results about {topic}: {results}")

@DBOS.workflow()
def research_agent(topic: str) -> str:
    query = choose_search_query(topic)  # step 1, checkpointed to Postgres
    results = web_search(query)         # step 2, checkpointed to Postgres
    return summarize(topic, results)    # step 3, checkpointed to Postgres

Here llm() and search_api() are your own functions; DBOS does not care what a step does, only that it records the outcome once the step returns. Now suppose the process is killed right after web_search returns, before summarize runs. Without durability you would restart research_agent from the top and pay for the first LLM call and the search again. With DBOS, the restarted workflow replays, finds saved results for steps 1 and 2, returns them instantly without re-executing, and runs only summarize. The agent finishes the job having paid for each expensive call exactly once. That is the difference the DBOS documentation means when it says a workflow recovers “from its last completed step.”

DBOS vs Temporal: when each wins

The reference point for durable execution is Temporal, the incumbent. The honest comparison is not “which is better” but “which boundary is your workflow inside.” DBOS is a library that lives in your app and uses your database. Temporal is a separate service, self-hosted or as Temporal Cloud, that your app talks to over the network.

The rule of thumb: reach for DBOS when the workflow fits inside your database boundary and the team is small, because there is nothing extra to run. Reach for Temporal when the workflow spans many services, when tenants need hard isolation, or when a dedicated cluster earns its keep in visibility and maturity. For an agent harness owned by one team on one Postgres instance, the DBOS model removes an entire piece of infrastructure, which is usually the point.

What durable execution costs

This is where the two models diverge in a way that matters to a budget. The DBOS Transact library is free and open source, so self-hosting on Postgres you already run costs nothing beyond that database. Paid tiers cover the managed retention and observability of checkpoints, where a checkpoint is a recorded workflow, step, or transaction.

The DBOS pricing page lists the managed tiers:

Tier	Price	Seats	Apps	Included	Overage
Transact (open source)	Free	n/a	Unlimited (self-hosted)	n/a	n/a
Pro	99 dollars/mo	2	3	1M checkpoints/mo	50 dollars per million
Teams	499 dollars/mo	10	10	10M checkpoints/mo	40 dollars per million
Enterprise	Custom	Custom	Custom	Custom	Custom

For comparison, Temporal Cloud bills by Action, its unit for a workflow operation, starting at an Essentials plan of 100 dollars per month for 1 million Actions, with usage above that billed at 50 dollars per million and volume discounts at scale. New accounts get 1,000 dollars in starting credits.

Should you add durable execution to your harness?

Not every agent needs this. A short, read-only agent that summarizes a document and returns text can fail and simply be re-run, and the machinery buys nothing. The decision turns on three questions:

1. Does a run take long enough to meet a failure? Multi-minute or multi-hour agents will hit deploys, timeouts, and crashes. Short synchronous ones will not.
2. Does the agent have side effects that must not repeat? Payments, emails, external writes, and expensive model calls all make “restart from the top” unacceptable. Pure computation does not.
3. Does it wait on humans or slow external systems? Approvals and long polls need a run that can suspend and resume, which is durable execution by another name.

If two or more of those are true, durable execution stops being optional. Whether that means DBOS or Temporal comes down to the boundary question above. If the answer is “one team, one Postgres, no appetite to run a cluster,” DBOS is the lighter path, and the free library means the only real cost of trying it is engineering time.

Bottom line

DBOS is durable execution delivered as a library on top of Postgres, from the team that built Postgres. For an AI agent harness, it turns a fragile long-running process into one that survives crashes, deploys, and human delays and resumes without repeating work or spending twice. The concept matters more than the vendor: a checkpoint is not durable execution, and any agent with real side effects and real runtime needs the execution guarantee, not just a save point. DBOS is the low-overhead way to get it when the workflow lives inside a single database. For pricing on the broader AI tooling stack this sits within, see the AI pricing guide.

Frequently asked questions

What is durable execution?

Durable execution is a way of running a program so its progress survives failure. The runtime records each completed step to durable storage, so after a crash, restart, or deploy the program resumes from the last completed step instead of starting over or losing the run.

Is DBOS open source?

Yes. The DBOS Transact library is open source and free to self-host on your own Postgres database. Paid tiers starting at 99 dollars per month cover managed retention and observability of workflow checkpoints, and DBOS Enterprise offers custom self-hosted options.

What is the difference between DBOS and Temporal?

DBOS is a library that runs inside your application and stores workflow state in your existing Postgres database, so there is no separate service to operate. Temporal is a dedicated workflow service, self-hosted or as Temporal Cloud, better suited to workflows that span many services or need hard multi-tenant isolation.

Do I need durable execution for my AI agent?

You need it when an agent run is long enough to meet a crash or deploy, when it has side effects that must not repeat such as payments or external writes, or when it waits on human approvals. A short, read-only agent that can simply be re-run does not need it.

Which languages does DBOS support?

The DBOS Transact library ships for Python, TypeScript, Go, and Java, and provides documented integrations with agent frameworks including Pydantic AI, LlamaIndex, and the OpenAI Agents SDK.

Sources

DBOS, Inc. (2026). DBOS Documentation. DBOS documentation. https://docs.dbos.dev/

DBOS, Inc. (2026). Transactions. DBOS documentation. https://docs.dbos.dev/python/tutorials/transaction-tutorial

DBOS, Inc. (2026). Python Programming Guide. DBOS documentation. https://docs.dbos.dev/python/programming-guide

DBOS, Inc. (2026). Pricing. DBOS. https://www.dbos.dev/pricing

DBOS, Inc. (2026). About DBOS. DBOS. https://www.dbos.dev/about

Wikipedia contributors (2026). DBOS. Wikipedia. https://en.wikipedia.org/wiki/DBOS

PR Newswire (2024). Technology pioneer Mike Stonebraker raises $8.5M to launch DBOS. PR Newswire (press release). https://www.prnewswire.com/news-releases/technology-pioneer-mike-stonebraker-raises-8-5m-to-launch-dbos-and-radically-transform-cloud-computing-302086000.html

Pydantic (2026). Durable Execution with DBOS. Pydantic AI documentation. https://ai.pydantic.dev/durable_execution/dbos/

Diagrid (2026). Why checkpoints are not durable execution. Diagrid blog (vendor analysis). https://www.diagrid.io/blog/checkpoints-are-not-durable-execution-why-langgraph-crewai-google-adk-and-others-fall-short-for-production-agent-workflows

Temporal Technologies (2026). Pricing. Temporal. https://www.temporal.io/pricing

Temporal Technologies (2026). Temporal SDKs. Temporal documentation. https://docs.temporal.io/encyclopedia/temporal-sdks