---
title: "Workers overview"
description: "What Obol Workers is, the four things you work with, what ships today, and what does not."
---
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](/concepts/tenancy-and-identity), reaches vendors through your existing connections, and is governed by the same compiled policy.
## The four things you work with
| You see | It answers | Where it lives |
|---|---|---|
| **Worker** | what runs | a definition plus immutable published revisions |
| **Workflow** | when and how it runs | a definition plus revisions |
| **Run** | what is happening now | a run, its steps, its environment leases |
| **Results** | what you got | artifacts, validated against an output contract |
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
| Class | Status | Backend |
|---|---|---|
| Code | Available | the Obol-operated E2B fleet, a local Docker development backend, or the demo backend — whichever this deployment configured |
| Browser | Available | the same three |
| Desktop | Beta | none — allocation fails closed |
| Android | Beta | none — allocation fails closed |
| iOS | Waitlist | none — allocation fails closed |
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](/workers/environments): 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](/workers/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](/workers/schedule-a-workflow).
- **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](/receipts/evidence).
## Where to go next
Create a Worker from a template, publish it, and read its cost card.
The estimate, the hard stop, and why unknown is never zero.
Typed failure reasons, typed fixes, and the Doctor.
Every shipped route, with a request and a response.