---
format: "aidr-story-markdown/v1"
id: "a1859df0b2bcdf037ae4ef062b87b1f7d6fe132d4799406a77dc19a595b2a472"
canonical_url: "https://aidr.today/a1859df0?lang=en"
title: "Obelisk 0.42: Durable Agents, Layered Sandboxes"
lang: "en"
requested_lang: "en"
available_langs: ["en","vi"]
translation_fallback: null
fallback_fields: []
published_at: "2026-10-04T14:30:55.000Z"
category: "Frameworks"
topics: ["agent","framework"]
source_urls: ["https://obeli.sk/blog/announcing-obelisk-0-42/","https://lobste.rs/s/g0q8ub/obelisk_0_42_durable_agents_layered"]
summary: "An agent's progress should survive the process that runs it. Its code should run within a policy you can review, and its failures should leave a history you can inspect. Obelisk keeps workflow progress in a database. Workflow code replays deterministically from that history, using recorded activity results before doing new work. A process can stop; the next one reconstructs where it left off. The same history lets you see what ran and debug it afterward. 0.42 builds on that foundation for agentic workloads: reviewable security boundaries for generated code, native V8 for faster JavaScript replay, Linux VM activities for tools that need them, and a workflow-agent prototype that can deploy, test, and fix applications on another Obelisk instance. The idea follows SQLite is All You Need for Durable Workflows : keep durable state close to the runtime, and let compute come and go. An agent waiting for a model, a tool, or a person can be represented by rows in the database, without a running VM per session. In 0.41 the operator's policy lived in server.toml and the application lived in deployment.toml . That left one file doing two jobs: server.toml described both the platform (listeners…"
---

# Obelisk 0\.42: Durable Agents, Layered Sandboxes

> [Open the canonical story](<https://aidr.today/a1859df0?lang=en>)

**Published:** 2026-10-04T14:30:55.000Z
**Category:** Frameworks
**Topics:** agent, framework

## Summary

An agent's progress should survive the process that runs it\. Its code should run within a policy you can review, and its failures should leave a history you can inspect\. Obelisk keeps workflow progress in a database\. Workflow code replays deterministically from that history, using recorded activity results before doing new work\. A process can stop; the next one reconstructs where it left off\. The same history lets you see what ran and debug it afterward\. 0\.42 builds on that foundation for agentic workloads: reviewable security boundaries for generated code, native V8 for faster JavaScript replay, Linux VM activities for tools that need them, and a workflow\-agent prototype that can deploy, test, and fix applications on another Obelisk instance\. The idea follows SQLite is All You Need for Durable Workflows : keep durable state close to the runtime, and let compute come and go\. An agent waiting for a model, a tool, or a person can be represented by rows in the database, without a running VM per session\. In 0\.41 the operator's policy lived in server\.toml and the application lived in deployment\.toml \. That left one file doing two jobs: server\.toml described both the platform \(listeners…

## Sources

- [Story source](<https://obeli.sk/blog/announcing-obelisk-0-42/>)
- [Discussion](<https://lobste.rs/s/g0q8ub/obelisk_0_42_durable_agents_layered>)