Staff the work. Skip the org.
The execution grain of the estate — the unit a function ships as, a workflow advances through, an agent runs as, and a human answers as. The layer the pack's own decks describe and never name, with a public repo you can read cold today and every distance to the rest stated in the open.
A builder whose system needs real work done — code for the bulk of it, a model where code runs out, a human where the judgment or the statute lives — buys executors at three different counters, in three different grammars. The serverless platforms sell code execution to a human with a console. The agent frameworks sell model orchestration to a developer with a runtime. The staffing products sell people to a manager with a dashboard. Each kind of worker arrives with its own contract, its own interface, and its own operational surface, and every seam between kinds is an integration the builder writes, owns, and staffs.
The deeper cost is what the seams prevent: re-staffing. The same unit of work should move from human to model to code as each kind clears it — that migration is the whole margin story of software eating labor — but when every kind lives on a different stack, moving a unit of work means re-plumbing a system instead of re-addressing a worker. The builder who should be running a fleet is running an org.
Three things in this estate are the substrate itself: the studio, the platform, and the runtime. This is deliberately not a fourth. workers.do is the execution grain under the pack — and the estate's own records prove the position from both sides, checked in the repo on 2026-07-30 and re-checked 2026-07-31.
From above: the pack's built decks each describe this layer without
naming it. The functions record runs on "shared runtimes kept warm";
the workflows record executes on "pluggable execution backends"; the
platform record runs "runtime, functions, data, and identity operated
as one system." Zero mentions of workers.do across all four records.
From beside: thirty-two sibling records estate-wide file
https://workers.do in their G3 stacks — the labor doors as "human
labor pool — the Worker interface," the porch records as "the porch is
a worker." A door thirty-two sibling records point at had no record of
its own. This is that record.
In the estate's own registry the coordinate is exact: noun Worker, verb work, type primitive, subcategory execution, priority P0. And the name is a double meaning by design, filed in the dedicated repo's own words: the serverless workers everything ships as, and the working workers — AI and human — that do the work. At this grain they are the same noun: a worker is whatever accepts work and answers for it.
// the repo's core grammar: workers addressed by name,
// work dispatched in natural language or typed units
import { ralph, quinn } from 'agents.do'
const code = await ralph`build the intake endpoint`
await quinn`test ${code} thoroughly`
Stated as the built architecture it is — the design lives in the public
monorepo at github.com/dot-do/workers, with its public gates below,
never as an installable claim. The design has three load-bearing
properties. One interface per worker, many transports: every worker
in the monorepo exposes REST, Workers RPC, CapnWeb, MCP, and HATEOAS
from a single definition — a worker is addressable by a human's HTTP
call, a sibling worker's RPC, and an agent's MCP session without three
implementations. Kinds behind the interface, not in it: the repo's
trees — agents/, humans/, teams/, roles/ — file AI workers with
identity, human workers reached over channels, and groups of both as the
same addressable shape, so escalating a unit of work from code to model
to human is an address change, not an integration project. The worker
is also the deployment unit: the whole estate ships as serverless
workers, so the grain that staffs the work is the grain that runs it.
The monorepo is public and resolves cold — but its root package is
filed private, no workers.do package exists on the public npm registry
(checked 2026-07-30, re-checked 2026-07-31), and the design has no docs
surface of its own.
This record describes built architecture and claims nothing installable
until the package and its docs post — and no benchmark or reliability
figure appears here until one publishes with its method and window.
Concreteness over adjectives: each door below was checked cold on 2026-07-30, re-checked 2026-07-31, and carries its own state and its own evidence URL — never one URL evidencing several domains. Serving is a liveness fact, not a tenancy claim: nothing here asserts external tenancy, metered billing in production, or a usage roll. Those publish behind their own gates.
workers.do answers 200 — with a hosting "Coming Soon — Domain
workers.do is not yet provisioned" placeholder, marked noindex. That is
the apex's actual behavior, posted as the live fact it is; the door's
own surface is the first amber on the bindings slide, not a claim here.
The gateway routes this primitive as a named service today: GET https://apis.do/workers returns a machine-readable JSON record — no
login, no signup — naming the service, its domain workers.do, its
category compute, and its status available.
The dedicated repository is public and resolves cold. The monorepo carries the deployable workers, the multi-transport RPC framework, and the agents/humans/teams trees this record describes.
platform.do serves — the operator's front door, whose own record
composes its system at exactly this grain.
functions.do serves — the sibling primitive whose units of logic
workers execute.
agents.do serves — the sibling runtime; its agents are the agentic
kind of worker, and the naming seam between its door and this one is
stated honestly on the next slide.
Five ambers, worn in the open — each the exact distance between what serves and what this door intends to be. (The figures gate on the economics slide is the estate's standing stack#1 §A5 disclosure rule, carried by every record in the portfolio — an estate gate, not a sixth product amber.)
The front door is not this record's yet: the apex answers 200 with a
hosting provisioning placeholder, while the estate's registry files the
coordinate implemented. The books lead the door, and this record
reports both at face value rather than letting either round the other
up. The claim flips when the apex serves the worker surface itself.
The estate's role table binds runtime.workers — the one runtime role
named for this door's own noun — to the sibling runtime at agents.do,
status active, while the pack's other primitive bindings point at
their namesake doors as pending. This record claims no binding it does
not hold: the reconciliation (the binding re-points here, or the
coordinate re-files) is queued in the program doc's decision queue, and
this claim flips when the registry rules one way.
The domain's own machine door answers with a hosting console's SPA shell
today — while the gateway's service record lists that exact address
under also as this service's own door. A machine that resolves this
primitive finds a pointer to a door that is not yet open. The claim
flips when the catalog serves at that address in the machine's own
language.
Restated from the architecture slide as a bindings fact: the public repo is the record that resolves; nothing installable is claimed until the package and docs post.
Metered per worker and per unit of work dispatched is the intended model, and the rate card IS the pricing surface: it binds when it posts at the contract surface — verbs, protocol, rate card, guarantees — not before, and never as prose in a deck. No figure is published or implied until then.
Primary motion is B2D: the buyer is a developer who evaluates in
code — and this record says plainly that today the evaluation surface is
the public repository, not a product funnel. The first conversion event
this door can honestly offer is a cold read of dot-do/workers; the
self-serve loop arrives with the apex and the package, behind their
stated gates. Secondary is B2A: the gateway already returns this
service's machine-readable record to a caller with no login, and a
worker is by construction an addressable capability — but purchase and
settlement for the machine motion gate on the contract surface, exactly
as the sibling records state for theirs.
Layer-1 economics at the worker grain: fixed cost is the substrate the estate already runs; each additional worker is a deployable unit served at near-zero marginal cost — and each unit of work re-staffed from a costlier kind of worker to a cheaper one is margin captured at the grain where the estate's doctrine says it lives.
The one-grain design is the economic design. When every kind of worker answers the same interface, re-staffing is continuous rather than a migration project: the code kind clears more of the distribution every quarter, and each unit it clears is served at software cost. The primitive's own function has no regulatory floor — nothing in deploying or dispatching a worker reserves a step for a statutory person. Where a statute does name a person, the human kind of worker answers — and that kind's economics, fees, and posted terms live at the estate's labor doors, which file this door as their Worker interface; they are never this primitive's revenue to claim.
Worker counts, dispatch volumes, kind-mix telemetry, and the internal-versus-external split are gated. Each figure publishes with its window and base or it does not publish.
everything the estate ships already executes as workers — the grain is occupied before it is sold, and the usage roll publishes behind its stack#1 §A5 gate or not at all
thirty-two sibling records file this door in their stacks today (re-counted 2026-07-31) — the labor doors as their Worker interface, the porches as workers; the anchor position exists in the estate’s own canon before any external tenant arrives
the estate’s gateway already routes /workers as a named service to a machine with no login — when the buyer is an agent, being discoverable and callable IS the distribution channel
code, model, and human workers behind one addressable shape — competitors can copy a serverless runtime or an agent framework; copying the re-staffing economics means adopting the estate’s whole labor model
The claim ledger lives on the "What serves today" and bindings slides — one posted chip per live door, one amber per gate, each stated once. This slide is the evidence in kind: what a caller actually receives at this primitive's two doors, retrieved cold on 2026-07-30 and again on 2026-07-31 with no login and no signup.
The gateway's service record. GET https://apis.do/workers returns
this envelope (abridged — the gateway's own api self-description
block, the caller-context block, and the gateway's home/api/events
links are omitted; the service block is verbatim):
{
"service": {
"name": "workers",
"domain": "workers.do",
"url": "https://workers.do",
"description": "Workers Service",
"category": "compute",
"status": "available"
},
"links": {
"self": "https://apis.do/workers",
"also": "https://workers.do/api",
"category": "https://apis.do/categories/compute"
}
}
What the apex serves. GET https://workers.do answers 200 with a
hosting placeholder — its own words, as served:
<h1>Coming Soon</h1>
<p>Domain <code>workers.do</code> is not yet provisioned.</p>
<footer>Startup Builder</footer>
The distance between those two responses is this deck's headline amber, shown as bytes rather than restated as a chip: the estate's gateway already files the door available and points machine callers at it; the door itself is not yet open. The gates on the bindings slide name exactly what flips it.
The record that resolves today is the public repo —
github.com/dot-do/workers.
If this was forwarded to you: workers.do is the execution grain of the startups.studio estate's infrastructure layer — the deployable unit a function ships as, a workflow advances through, an agent runs as, and a human answers as. It is deliberately not one of the estate's three substrate properties, and its deck says so; it is the noun the pack's own decks describe and never name, and the door thirty-two sibling records already point at. What is live is posted with a URL checked cold — the gateway record and the public repo; what is not is pending with the gate that flips it — including the five ambers it wears openly: the placeholder apex, the machine catalog not yet open, the runtime.workers naming seam with the sibling runtime, the unpublished package, and the unposted rate card. Judge it by what is posted, and by how plainly it labels what is not.