Obelisk 0.42: Durable Agents, Layered Sandboxes

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, database, resource limits) and what a particular app was allowed to do. 0.42 splits it: