The kernel sequences a single verb call synchronously; it has no durable retry, backoff, or wait. Hatchet is the choreography layer for the flows that need them — e-signature, human-in-the-loop, document rendering, webhooks.
The shape
Hatchet is just another verb-client, alongside the agent and the CLI. A worker runs durable workflows whose
steps call kernel verbs over the authenticated front door (POST /v/:verb with a service bearer). The kernel
stays the trust boundary and the source of record; Hatchet’s run-state is operational only.
hatchet/worker/opbox_client.py— the verb client. A non-2xx raises, so Hatchet retries and backs off; it sends anIdempotency-Keyso a retry is safe.hatchet/worker/flows.py— pure step functions (the verb calls), Hatchet-independent and unit-testable.hatchet/worker/workflows.py— the Hatchet decorators that wrap the flows with durable retry / backoff / wait.
A durable flow
An e-signature flow, for example: create an envelope → set the signer → send → durably await completion. The await step polls the envelope and raises a “not yet” until it resolves, so Hatchet backs off and retries without holding a worker.
What is reserved
Replacing that poll with an event-driven wake - an inbound provider callback that wakes a waiting flow - needs a generic inbound webhook ingress, which is a trust-boundary surface. Its design is still to be settled; until then the durable poll is the mechanism. Inbound provider callbacks themselves use the existing per-verb, HMAC-authenticated callback verbs.
Why adopt rather than build
Adopting Hatchet (an external, swappable orchestrator that calls authenticated verbs on the shared Postgres) keeps the kernel from growing a second engine of durable execution. It is consume-the-commodity in practice — the kernel stays the differentiating substrate.