Does DBOS Remember Between Runs? Steps Are Checkpointed in Postgres. The Next Run Still Starts Fresh.

Short answer: DBOS remembers a great deal inside one workflow execution, and almost nothing carries into the next one on its own. DBOS Transact checkpoints every completed step of a workflow into Postgres, so a crashed run can resume exactly where it stopped. A new run, started fresh by a schedule or a caller, is a new execution with its own inputs. It does not open the previous run's checkpoints, reasoning, or decisions before it begins.

That distinction matters because DBOS can feel like it has a long memory. A workflow can sleep for days and pick up mid-flight after restarts. Surviving an interruption inside one job is a different job from remembering yesterday's job.

What DBOS is built to remember

DBOS Transact is an open-source durable execution library, available for languages including Python and TypeScript. There is no separate orchestration server to run. The library lives inside the application, functions are marked as workflows and steps, and Postgres is the only infrastructure the durability rests on.

As a workflow runs, DBOS writes its inputs and each step's output into tables in that Postgres database. Those checkpoints are the workflow's record of itself. If the process crashes, is deployed over, or is killed, the record stays in the database, ready for a replacement process to read.

Recovery works by replay. On restart, DBOS re-executes the workflow function with its checkpointed inputs. Before each step, it checks the database: a step with a recorded output returns that output instead of running again, and real work resumes at the first step with no checkpoint.

The guarantees follow from that design. Steps run at least once, and a completed step is never re-executed. Transactions commit exactly once. Starting a workflow with an ID that already ran returns the existing result, which makes duplicate submissions safe.

Memory that belongs to one execution

Every one of those mechanisms is scoped to a single workflow execution, identified by its workflow ID.

Checkpoints answer one question: how far did this execution get, and what did its steps return? They exist so the same execution can finish, not so the next execution can learn. A completed workflow's record remains in Postgres for inspection by ID, but nothing promotes it into a later run's starting context.

Durable sleep shows the same boundary. A workflow can pause for weeks, storing its wake-up time in Postgres, and resume on schedule after any number of restarts. The workflow that wakes up is the same execution continuing, not a new run that inherited an older run's knowledge. Queues and cron schedules work the same way: each firing starts its own execution, with its own checkpoints.

What the next run does not get

A new execution receives the inputs it was started with, and nothing else automatically. It does not receive the previous run's step outputs as context. It does not receive the list of items the last run already handled, the branch the last run chose, or the reason it skipped something.

Consider a scheduled agent workflow that runs every morning: fetch new support tickets, draft replies, and escalate the ones that need a human. On Monday the workflow works out that one account is mid-dispute, so its tickets should be held rather than answered. If that finding exists only as a step output inside Monday's execution, Tuesday's execution starts without it. The tickets are still there, the dispute is still open, and the new run can draft the very replies Monday deliberately held back. DBOS executed both runs correctly. Tuesday simply began without Monday's memory.

Reading old results back is possible, because workflow outputs stay queryable in Postgres by ID. A workflow can be written to look up a previous execution and load what it returned. That is a hand-built bridge between two executions of one workflow in one codebase. It carries the values someone chose to fetch, in the shape that code expects. Decisions made in another tool, a chat with an assistant, or a second agent in a different stack never enter that bridge at all.

A checkpoint log is a record, not a memory

The Postgres tables behind DBOS are genuinely useful as a record. Workflow status, step outputs, and history can be queried with SQL, which makes debugging and auditing direct: which run failed, at which step, with what output.

Memory for a recurring agent has a different job. It has to be loaded before the agent acts, not only inspected after it acted. It has to hold decisions and the context behind them, not only step return values. And it has to be reachable from every tool taking part in the work, not only from code that shares one Postgres database and one workflow definition.

A checkpoint table covers the first job for executions of a single application. It does not cover the assistant that reviewed the output, the agent in another platform that handles the next stage, or the same workflow after the team moves it to a different orchestrator. Each starts with its own slice, unless the memory lives outside all of them.

Giving DBOS workflows one shared memory

That shared memory is what Vilix AI provides. Vilix AI is a cloud-hosted memory layer for AI tools and agents, with no infrastructure to run or maintain. Connected tools reach the same memory over MCP, the Model Context Protocol, so a DBOS workflow, an agent in another framework, and a person checking the work in chat can all start from one shared history instead of separate execution records.

Vilix AI stores full conversation history, not just extracted facts. For recurring work, the decision and the discussion behind it are both there for the next run to load, not only a status value left in a database row. Because the memory lives outside any single application, it also stays available when a workflow moves platforms, the model behind a step changes, or a new tool joins the setup.

Trying it carries little risk. There is a free plan that stays free forever, and a 7-day Pro trial that needs no credit card. Data can be exported or deleted at any time, so control stays with the owner of the memory.

How to design around the boundary

1. Use DBOS checkpoints for what they are designed for: finishing one execution reliably, however many times the process restarts.
2. Assume every new execution starts with only its inputs, and confirm it by running the same scheduled workflow twice and comparing what the second run knows.
3. Write down what tomorrow's run must know before it acts: settled decisions, items already handled, holds and exceptions, and open questions.
4. Give that knowledge a home the next run actually loads at the start and updates at the end, through a shared memory layer reachable over MCP, such as Vilix AI.

DBOS gives a workflow an unusually solid memory of itself, stored in plain Postgres tables. Scheduled agents become dependable across days when each new run is also given what every run before it learned.