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.

Read more →

Obelisk 0.41: Safe Deployments for Agents

Obelisk 0.41 draws a firm line between what an operator controls and what a deployment can do. That line is what makes it safe to let an agent author, submit, and activate deployments: the operator sets secrets and outbound HTTP policy once in server.toml, and no deployment can exceed it, no matter who wrote it. Our proof of concept workflow-agent, where the workflow is the agent editing and pushing deployments, runs entirely inside these boundaries.

Read more →

Comparing Obelisk with Temporal and Restate

Obelisk, Temporal and Restate all let a function keep making progress after its process disappears. The largest architectural difference is that Obelisk is a workflow runtime: it loads and runs application components itself. Temporal and Restate are orchestrators whose application code runs in separately deployed Workers or service endpoints. That difference shapes which mistakes each system can prevent and what exactly gets deployed.

I implemented the same small workflow with all three. The goal is to compare their Rust APIs, determinism boundaries, activity isolation, secrets and deployment models.

Read more →

Obelisk 0.40: Secured API Access and Structured Child Failures

Obelisk 0.40 tightens two defaults that used to be wide open and improves how workflows see failed children. The API port now rejects requests without a token, host exec activities have to be enabled before they will run, and an awaited child failure now tells you whether it was a business error or a platform failure such as a timeout or cancellation.

Read more →