AI Agents May Be the Workload DBOS Was Waiting For

The practical path for DBOS may not be replacing Linux. It may be becoming the durable runtime inside the isolated environments we are already building for AI agents. I have been thinking about Michael Stonebraker's DBOS idea again because AI agents make an old systems argument feel unexpectedly current. The original DBOS proposal from 2020 made a radical claim: operating system state could be represented uniformly as database tables, with operations over that state expressed as queries and transactions. The later VLDB paper on DBOS went further. Instead of composing a traditional operating system with separate cluster schedulers, distributed filesystems, IPC mechanisms, analytics systems, and high-availability machinery, the authors explored putting a distributed transactional DBMS near the bottom of the stack and implementing many OS services over it. I do not think AI agents prove that we should replace Linux with a database. I think they validate a more practical version of the same idea: The database can become the durable runtime for autonomous computation. More importantly, the agent ecosystem may have created a new insertion point where we can test this idea without asking infrastructure teams to replace their operating system at all. Agents Have an Execution-State Problem A normal web request is short: request | application | database | response An agent is different:user request | LLM | tool call | LLM | database query | wait for approval | API call | another agent | LLM | ... That workflow might run for minutes, hours, or days. Now imagine the process dies at step 47. Starting from step 1 may be wrong. Earlier steps may already have sent an email, changed a database row, opened a pull request, or charged a customer. This is why long-running agents increasingly need durable execution rather than simple retry logic. Current DBOS agent documentation makes this an explicit use case. A workflow persists its progress in a database so it can recover after process crashes, server restarts, network failures, deployments, or long pauses for human input. There is also an LLM-specific reason this matters. LLM calls are nondeterministic. result = llm(prompt) Calling that function again does not guarantee the same result. A retry can change the future path of the program. A durable runtime therefore wants something closer to:LLM(prompt) | result | checkpoint result | continue DBOS's Vercel AI SDK integration, for example, checkpoints completed model calls in Postgres. During recovery, completed calls can be replayed from those checkpoints instead of contacting the model provider again. The model output is no longer just API response data. It has become part of the execution history of the program. That is a very database-shaped problem. Agent State Is Already Scattered Across Systems A production agent can easily accumulate several state stores: Postgres -> business and application state Redis -> cache, locks, temporary coordination Vector DB -> semantic retrieval Workflow DB -> execution history Object store -> files and artifacts Tracing DB -> model and tool traces Each system exists for a reason. I am not arguing that one relational database should physically replace every specialized store. The more interesting question is: Can everything required to understand and recover an agent's computation have one authoritative transactional representation? Large artifacts can still live in object storage. Vector indexes can remain specialized. GPU memory and model KV caches can remain ephemeral. But goals, messages, tool-call results, approvals, checkpoints, permissions, budgets, execution history, and references to artifacts are structured state. That is the part that looks increasingly like an operating-system problem expressed as data. The OS Analogy Becomes Stronger With Agents An agent runtime needs concepts that look surprisingly familiar: Process -> Agent or workflow Thread -> Task or sub-agent Scheduler -> Agent scheduler IPC -> Agent messages Files -> Memory and artifacts System call -> Tool call Credentials -> Tool permissions Process tree -> Agent delegation tree Resource limits -> Token, time, and dollar budgets Checkpoint -> Workflow checkpoint Trace -> Agent provenance Crash recovery -> Agent resume The useful state of an autonomous agent might look like this: Agent 4312 goal context memory permissions messages tool calls model calls pending work completed work human approvals budget artifacts execution history Almost everything in that list can have a durable database representation. The 2025 DBOS retrospective is interesting in this context. It describes how the research project evolved, including work on provenance and a Python and TypeScript programming environment. Provenance becomes much more important when the program itself is making decisions. We now need to ask: Why did the agent take this action? Which model response caused it? What data did it see? Which tool did it invoke? Did the tool actually execute? How much did the path cost? Where can execution safely resume? Those are naturally queries over execution state. The New Insertion Point: Agent Sandboxes This is the part I find most interesting. The original DBOS vision had a difficult adoption problem. Replacing the operating-system architecture of an existing infrastructure stack is a very large commitment, no matter how compelling the research argument is. But AI infrastructure is currently creating a new execution boundary almost from scratch: the agent sandbox. A growing set of platforms now gives agents isolated environments for running code and tools. Modal Sandboxes are secure containers intended for untrusted user or agent code. Daytona provides isolated agent runtimes and uses Linux containers by default. E2B integrates persistent isolated sandboxes directly with the OpenAI Agents SDK. This creates an interesting opportunity. Instead of this: replace Linux | deploy DBOS everywhere | rewrite infrastructure we could try this: Linux host | Agent sandbox | DBOS durable runtime | Postgres | Agent + tools Linux still provides the kernel, namespaces, filesystem, networking, process isolation, and device support. The DBOS-style layer becomes the durable control plane for the agent's computation. That is a much smaller adoption step. It also gives us a clean experimental boundary. An Experiment I Would Like to Run I would build the same long-running agent in two environments. A. Conventional Agent Runtime Agent sandbox | agent framework | workflow/state infrastructure | LLM + tools B. DBOS-Backed Agent Runtime Agent sandbox | DBOS workflow runtime | Postgres | LLM + tools Then I would inject failures at random points in the same workload. Kill the process after an LLM response. Kill it during a tool chain. Restart the sandbox. Interrupt it while waiting for human approval. Crash a worker after an external API succeeds. Then compare: task completion rate successful recovery rate duplicate side effects repeated LLM calls repeated tool calls token and API cost p50 / p99 latency overhead throughput time to diagnose a failed run ability to reproduce execution I would also measure task quality, but I would not expect DBOS itself to make the model smarter. The interesting question is whether better execution semantics improve the reliability of the overall agent. There is an important caveat here. DBOS does not magically give exactly-once semantics to arbitrary external APIs. Its step documentation explicitly notes that steps execute at least once. If an external side effect succeeds and the process dies before its result is checkpointed, that step can execute again. External systems still need techniques such as idempotency keys. For database writes, however, the durability boundary can be much stronger because application state and workflow state can participate in transactional execution. This is exactly why I think the comparison would be useful. The goal is not to prove that databases remove distributed-systems failures. The goal is to see whether a database-centric execution model gives us a smaller and more understandable failure surface. DBOS May Have Moved Up One Layer The most interesting evolution of DBOS may therefore be conceptual rather than literal. The original idea was roughly: Applications | OS services | Distributed DBMS | small kernel | Hardware The practical agent version could be: Agent | Durable execution runtime | Database | Linux / sandbox / cloud | Hardware The database is no longer the operating system for the whole machine. It becomes something closer to an operating system for the computation. That distinction matters because an LLM agent does not really care about POSIX as its programming model. The abstractions it cares about are goals, context, memory, messages, tools, permissions, approvals, budgets, and persistent execution history. Those abstractions map surprisingly naturally to records, transactions, and queries. Maybe Agents Are the Workload DBOS Was Waiting For I do not know whether a DBOS-backed agent runtime would outperform conventional agent infrastructure. That is an empirical question, and I would rather benchmark it than assume the answer. But the architecture now has something the original DBOS proposal did not have: a low-friction adoption path. We are already creating new isolated runtimes specifically for agents. That means we do not have to convince a company to replace Linux across its infrastructure. We can put a database-backed durable runtime inside one class of agent sandbox, run the same workload beside a conventional implementation, inject failures, and measure the result. If the database-centric version makes recovery, provenance, reproducibility, and coordination significantly simpler without unacceptable overhead, that would be a meaningful validation of Stonebraker's original thesis, just one layer higher in the stack. Perhaps the future of DBOS is not: Database replaces the operating system. Perhaps it is: Database becomes the operating system for long-running autonomous computation. That feels like an experiment worth running.