Workers is the part of Obol that runs an agent, rather than sitting in front of one. You describe a job, Obol proposes a Worker, you review and publish it, and runs happen in Obol-operated environments under the same workspace, policy, approvals and audit trail as everything else. It is a section of Obol, not a second product. There is no separate Workers organisation, billing profile, credential vault or policy system: a Worker runs as an existing Agent Passport, reaches vendors through your existing connections, and is governed by the same compiled policy.

​
The four things you work with

Everything else — leases, fencing tokens, attempts, passports, Cedar — is advanced configuration or invisible.

​
What ships today

Nothing here claims production isolation, and the contract cannot express one. Three backends stand behind the environment interface: the Obol-operated E2B sandbox fleet for code and browser environments, a local Docker development backend, and a deterministic demo backend for the free sandbox. isolation_claim has exactly three values — none, development_only and vendor_attested_microvm — ordered weakest first, with deliberately no production member, so a production-isolation claim stays unrepresentable rather than merely discouraged.vendor_attested_microvm is the fleet’s claim, and attested is the whole word. Four things stay open wherever it appears:
  • The microVM boundary and the compliance posture are the vendor’s assertions. Obol has not verified either one.
  • Domain-level egress is a routing control at that vendor, not a security boundary. Obol restricts outbound traffic with address rules and its own proxy instead, and never relies on domain matching.
  • Separation between tenants sharing one fleet account is undocumented by the vendor.
  • Some sandbox state can outlive the run that produced it, and no vendor retention promise currently covers it.
The fleet is decided in ADR-0104, which is Proposed rather than accepted.
A run has not been watched to complete end to end, as of 2026-09-10. The process joins exist: main() bootstraps the allocator registry, the activity surface, the hand-off assembler, and the gateway dispatch client, including ADR-0105 run-scoped keys. Remaining gaps: no Compose-profile run against live control and gateway has been watched; there is no Fly app, no Helm entry, and no production Temporal cluster; isolation_claim has no production member.Everything that does not need a run works today: templates, environments, entitlements, drafting, Workers and revisions, Workflow authoring, estimates, run history, artifacts, session profiles and the Doctor.

​
Environments, stated honestly

Never infer runnability from the status label, and never from this table. Availability is resolved per deployment rather than declared: control asserts no backend by default, so a deployment that has configured nothing reports not_configured for every class and renders no run affordance at all. Read runnable on the environment document: it is the conjunction of availability, backend readiness and your plan’s entitlement, and a class can be Available and still not runnable because no backend is configured where you are. A code Worker, when that class is runnable here, runs commands in its isolated E2B sandbox. No credential is placed in the guest; repository writes go through GitHub tools on the gateway, not git push; only public repositories; one environment class per run. See Run a coding agent.

​
What is not here

  • Triggers only start runs. A Worker can be started on a cron schedule (in its own timezone) or by a signed webhook, and a webhook can map fields of its body into the run’s declared inputs. That is all a trigger does: there is no step engine behind it, and every fire goes through the same start-run path, cost acknowledgement and plan limits as a manual start. Schedules and webhooks need a paid plan. See Schedule and trigger a Worker.
  • No price. Amounts you see are deployment configuration, labelled illustrative until measured. The plan ladder carries entitlements — runs, environment classes, concurrency, retention — and no money field at all.
  • No new evidence. Running inside an Obol-operated environment does not raise what a receipt may claim. A native route can be gateway_observed; a federated catalog route cannot, and the receipt always names the class. A screenshot is an observation of a screen, not proof of a vendor-side effect — see Evidence.

​
Where to go next

Quickstart

Create a Worker from a template, publish it, and read its cost card.

Control costs

The estimate, the hard stop, and why unknown is never zero.

Debug a failed run

Typed failure reasons, typed fixes, and the Doctor.

Workers API

Every shipped route, with a request and a response.