pitch.workflows.do
Declare the process. Skip the babysitting.
The orchestration primitive of the estate: declare a business process once and it runs durably — retries, day-long waits, and code-to-AI-to-human escalation as primitives — behind a front door that serves today, with every gate to the rest stated in the open.
↓ scroll · arrow keys
A builder who owns a business process — charge the order, wait an hour, check for fraud, escalate to a human if the check is unsure — shops a real market, and this deck names it honestly. The self-hosted orchestration engines solve durability and hand back a cluster to operate, queues to wire, and a scheduler somebody watches. The serverless durable-execution clouds solved the rest of that — declare-and-run retries, durable sleep, event waits, no cluster, no babysitting — for the steps that stay inside code. What no counter sells is the rest of this builder's process: escalation across kinds of labor — code, then a model, then a human — as a declared primitive rather than a wiring project, and a door an agent discovers and triggers by the event it emits rather than a dashboard a developer signs up for.
The remaining tax lands hardest exactly where the estate's whole premise lives: on builders and businesses too small to staff the escalation seam — the fallback wiring, the human queue, the review dashboard. If the machine economy runs on processes — the sequences agents trigger, businesses meter, and time interrupts — then the whole process, human rungs included, has to be sold as a declaration, or the sequence stays priced like a department.
Three things in this estate are the substrate itself: the studio, the platform, and the runtime. This is deliberately not a fourth. workflows.do is the orchestration primitive the platform operates — the composed runtime that sequences the estate's other primitives into processes — wearing its own door because the builder who owns a long-running process is a different ICP from the builder holding a single function, and a brand here is one ICP and one motion.
In the estate's own registry the coordinate is exact: noun Workflow, verb orchestrate, type primitive, priority P0. The seams are short: functions.do executes the unit of work; this door sequences those units across time; the data surface holds their state; the runtime's agents trigger workflows and answer their escalations; the platform operates all of it as the one metered system its own deck describes.
export default workflow('process-order', $ => {
$.on.Order.placed(async (order, $) => {
// durable step — result cached, retried on failure
const payment = await $.do('charge', () => charge(order))
// durable sleep — zero compute while it waits
await $.sleep('wait-fulfillment', '1 hour')
// the estate's margin doctrine as a primitive:
// code first, then a model, then a human
const review = await $.cascade('fraud-check', {
code: quickRules,
generative: aiAnalysis,
human: manualReview,
})
await $.send('Order.fulfilled', { orderId: order.id })
})
})
There is nothing else to author. The engine's design — stated here as the
built architecture it is, with its public gates below, not as a live
self-serve promise: a workflow subscribes to events by noun and verb
($.on.Order.placed), and its body composes four durable primitives.
$.do runs a step whose result is cached and retried, so a replayed
workflow never re-charges a card. $.sleep parks the process for an hour
or a month at zero compute. $.waitForEvent blocks on the outside world
with a timeout instead of a polling loop. $.cascade is the estate's own
migration doctrine — Human → Agentic → Generative → Code — inverted into
a runtime verb: try code, escalate to a model, escalate to a human, in
that order and only as far as needed. Execution backends are pluggable
beneath the same declaration, and every step and event emits to a durable
log, so the process's history is a record rather than a reconstruction.
The SDK exists as built architecture in a private repository: it is not
yet published, its repository does not resolve publicly, and the SDK
has no docs of its own — the front door's View Docs links resolve to
the platform's docs at docs.platform.do, which document the workflows
service but not this SDK's primitives. This record describes the design
and claims nothing about public availability 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 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.
workflows.do serves. The front door a builder would resolve is live,
and it sells declarative TypeScript workflows with durable execution
and automatic state persistence — the core of this record's offer. The
page's own framing goes further than this record does: its hero sells
self-optimizing, AI-powered workflows, a story this record deliberately
does not claim. The page predates the record; what this claim posts is
the liveness fact.
The gateway routes this primitive as a named service today: GET https://apis.do/workflows returns a machine-readable JSON record — no
login, no signup — naming the service, its domain workflows.do, its
description Workflow Orchestration, and its status available.
platform.do serves — the operator's front door, whose own record files
this primitive among its composed runtimes under the same claim
discipline.
functions.do serves — the sibling primitive whose units of work this
door exists to sequence.
agents.do serves — the sibling runtime whose agents are the machine
callers on one side of this primitive and the escalation targets on the
other.
Ambers worn in the open — each one the exact distance between what serves and what this door intends to be.
The domain's own machine door answers with a human page today — and not
even this brand's: workflows.do/api returns the gateway's own apis.do
page, while the gateway's service record lists that address under also
as this service's own door. A machine that resolves this primitive finds
a door opening onto another brand's page written for humans. The claim
flips when the catalog serves at that address in the machine's own
language.
The estate's own role table files this domain as the runtime.workflows
binding of the constitution's runtime — with status pending, while
the sibling runtime.workers binding at agents.do is already active.
The estate does not round up its own registry: the binding is declared
here at its filed state, and this claim flips when the registry does.
Metered per run and per step 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, and no claim of costing less than any named alternative is made until a posted card exists to compare.
Primary motion is B2D: the buyer is a developer who evaluates in the docs and converts at the first durable run — the first time a workflow sleeps through a deploy and wakes up correct. No sales motion, no demo call, no procurement; the evaluation surface is the product surface, which is why the SDK-and-docs gate on the architecture slide is the deck's most important amber. Secondary is B2A: a deployed workflow is an event-addressed capability — an agent does not call it so much as emit the event it subscribed to — and the first step of that motion already serves, because the gateway returns this service's machine-readable record to a caller with no login. 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 process grain: fixed cost is operating the orchestration substrate; a waiting workflow holds zero compute, so a tenant's thousand sleeping processes cost the substrate almost nothing until the moment they advance — and blended margin improves with density.
Durable sleep is the economic design, not just the correctness design: a process that waits for a day holds state, not compute, so the cost of a tenant's portfolio of in-flight processes tracks their advances rather than their existence. Density compounds in the tenant's favor and the operator's at once — the opposite of the cluster model, where every long-running process pays rent on idle machinery. The cascade primitive carries the margin story inside the product: every step that the code rung clears without escalating is a step served at software cost. And there is no regulatory floor anywhere in this function — nothing in advancing a workflow reserves a step for a statutory person, so the implementation mix migrates all the way to Code.
Workflow counts, run volumes, cascade-mix telemetry, and the internal-versus-external split are gated. Each figure publishes with its window and base or it does not publish.
every brand the estate launches runs its processes on the estate stack this primitive sequences — demand generated by the portfolio’s own search process, structural before commercial; the usage roll publishes behind its stack#1 §A5 gate or not at all
the estate’s gateway already routes /workflows as a named service to a machine with no login — when the buyer is an agent, being discoverable and callable IS the distribution channel
zero-compute waits mean each additional in-flight process costs the substrate almost nothing until it advances — a property the serverless durable-execution tier shares, priced here at estate density: the substrate’s fixed cost is already carried by the portfolio’s own processes, so marginal sleep is close to pure contribution
cascade encodes the estate’s Human → Agentic → Generative → Code migration as a runtime primitive — competitors can copy a retry loop; copying the escalation economics means adopting the estate’s whole labor model
Serving is a liveness fact, not a tenancy claim: each posted URL below evidences that one door resolves — not that anyone occupies it.
workflows.do serves — the primitive's front door is live.
apis.do/workflows serves machine-readable JSON — the gateway's service
record for this primitive resolves for a machine with no login, status
available.
The SDK is built architecture in a private repository, with no docs of its own — the platform's docs document the workflows service, not this SDK's primitives. The most important amber for the B2D motion, because for this ICP the docs are the brand, and this deck declines to claim the SDK's own docs in present tense.
The domain's own machine door — today answering with the gateway's own
apis.do human page, listed under also in the gateway's record — is the
next gate for the B2A leg: a primitive an agent cannot read is a
promise, and this deck declines to make it in present tense.
The estate's runtime.workflows binding remains filed pending, and this
record reports its registry at face value until the registry flips.
The front door is workflows.do — it serves today.
If this was forwarded to you: workflows.do is the orchestration primitive of the startups.studio estate's infrastructure layer — the composed runtime that sequences the estate's units of work into processes that survive time. It is deliberately not one of the estate's three substrate properties, and its deck says so; it is the primitive that turns steps into sequences, sold to the builder who owns a long-running process and refuses to staff an operations practice around it. What is live is posted with a URL checked cold; what is not is pending with the gate that flips it — including the ambers it wears openly: the unpublished SDK, the machine door still serving another brand's human page, the estate's own pending registry binding, and the unposted rate card. Judge it by what is posted, and by how plainly it labels what is not.