A matter is a sequence of steps, and workflow automation is how those steps run without someone pressing a button. A step is a typed kind that maps to a governed handler verb; a trigger fires work on a schedule or in response to an event; a run is one execution of that work, with a status you can watch, cancel, retry, or resume; and a gate is the brake that holds a sensitive change until a human approves it. The pieces are ordinary kernel verbs, so the same automation an operator wires up by hand is the automation the agent drives, governed identically.
“Matters and steps” and “durable executions” are two different layers, and this feature spans both:
- The matter state machine (the kernel) is the process being automated: a matter is a sequence of typed steps on a board (a dependency graph), advanced through governed verbs. The kernel runs each verb call synchronously, with no built-in retry or wait, and it stays the source of record.
- Hatchet (an adopted, swappable durable orchestrator) is how those flows run reliably: it wraps the kernel and calls verbs, adding retry, backoff, and durable waits. Its run-state is operational only. The
run.*verbs are the governed front door to those durable runs, and the Automations view embeds Hatchet’s own dashboard.
So a matter step and a Hatchet step are different things: a matter step is a domain stage (a steptype mapped to a handler verb), while a Hatchet step is a durable task that calls kernel verbs and is written as a pure, idempotent function so a retry is safe. See Hatchet orchestration for the durable side.
What it does
A typed step-type taxonomy. A matter step is not a free-text label, it is a registered kind: a FORM, a SPAWN_MATTER, a document-generation step, a plain TASK. Each kind in the registry carries a key, a label, an optional handler verb it dispatches to, and whether it is terminal. Authoring a step type is config, not code: you register a new row and any process can reference it without a substrate change, and you archive a row to take it out of the active palette. Because the kind maps to a real handler verb, the structure of a step is the instruction for how it runs.
A workflow board you can author. A board lays a matter template out as phases (lanes) and the ordered steps inside them. From the workflow board you reorder a step within its lane, add a new step, remove one, and wire the dependencies between steps - the dependsOn edges that form the workflow’s directed graph. Every edit sends the full phase structure back through one save, so no field is lost, and the kernel re-validates on the way in: a duplicate step id, a dependency that points at a removed step, or a cycle (a depends on b depends on a) is refused as a save error rather than left to corrupt the board.
Triggers that start work on their own. A trigger is the rule that fires work on a schedule or in response to an event. You create or update a trigger, test it before you rely on it, enable or disable it, and list everything that is wired up. Triggers are how the system does things without someone clicking, and like every other capability they are named verbs behind the one front door, so a trigger is checked and recorded the same as a manual action.
Durable runs with a status you can steer. A run is one execution of an automated flow. You start a run, check its status, and list runs; when something goes wrong you retry it, resume it, or cancel it. Cancelling an in-flight run is not a guess: it fires the AbortSignal that the connector’s read honours, and re-cancelling a run that has already finished is a no-op, so the cancel is safe to call again. The staff-facing view over the automation bus (runs, failures, and triggers) is the embedded Hatchet dashboard, so the live execution picture sits inside the product rather than in a separate tool.
Approval gates as the brake. Some moves must not proceed without a human signing off. A gate proposes a change and holds it: a reviewer approves it (and the change is committed) or rejects it (and it does not proceed). An applied gate is not the end of the road - because it captures the before-state, an applied gate can be cleanly reverted, replaying the restoration through the canonical verb on one governed transaction and restoring exactly what was there before. The revert is terminal and idempotent: it stamps the restoration once, and a second revert matches nothing. Gates are how an automated or agent-driven flow can still wait for a named human decision at the points that matter.
Inbound and outbound event plumbing. An external system can drive work in through webhook.ingest, the single inbound-webhook guard, which is unauthenticated by design but hard-fenced: IP rate limiting, a raw-body HMAC signature check, a replay nonce, and a size cap stand in front of it. Work can also reach outward through webhook.send, which runs through the kernel’s egress chokepoint like every other outbound call. Together they are how a trigger or a run connects to the world outside the box.
How you use it
Author the step types your processes use. Open the workflow step types palette to see the taxonomy: each kind, its label, the handler verb it dispatches to, and whether it is terminal. Register a new kind with a key and a label when a process needs a step shape it does not yet have, and archive a kind to retire it from the active palette.
Shape a workflow on the board. Open the workflow board, pick a board, and you see its phases as lanes with each step as a card showing its title and step type. Reorder a step within its lane, add or remove a step, and set what a step depends on - the kernel rejects a cycle or a dangling reference, so an illegal dependency surfaces as a save error rather than a broken board.
Wire and test a trigger. Create or update a trigger for the schedule or event you want to react to, test it to confirm it fires as intended, then enable it. Disable it when you need to pause automation, and list the triggers to see everything that is currently wired up.
Watch and steer a run. Start a run and check its status; list runs to see what has executed. If a run stalls or fails, retry it or resume it, or cancel an in-flight one - the cancel fires the abort the connector honours. For the live picture across the automation bus, open the Automations view, which embeds the Hatchet dashboard of runs, failures, and triggers.
Hold a sensitive move for sign-off. Where a step or an automated flow proposes a sensitive change, it goes through a gate: the change waits, a reviewer sees exactly what is on the table, and it only proceeds on a real approval. If an approved change needs unwinding, revert the gate and the prior state is restored cleanly.
The kernel verbs behind it
Everything above runs through the kernel’s one front door: each call is permission-checked, scope-checked, and audited before it executes. These are the key verbs.
Runs:
run.start- begin one execution of an automated flow.run.status- read where a run has got to.run.list- see the runs that have executed.run.retry- retry a failed run (idempotent).run.resume- resume a paused or interrupted run.run.cancel- cancel an in-flight run; fires theAbortSignalthe connector read honours, and re-cancelling a terminal run is a no-op.
Triggers:
trigger.upsert- create or update a schedule or event rule.trigger.test- test a trigger before you rely on it.trigger.enable/trigger.disable- turn automation on or off.trigger.get/trigger.list- read one trigger, or see them all.
Step types and gates:
steptype.register- declare a step-type registry row that maps a step to a governed handler verb.steptype.list- read the step-type catalogue.steptype.archive- retire a step type from the active palette.gate.propose- put a sensitive change forward for human sign-off.gate.apply- approve a gate and commit the change.gate.reject- decline a gate so it does not proceed.gate.revert- cleanly undo an applied gate, restoring the before-state through the canonical verb.
Event plumbing:
webhook.ingest- the single inbound-webhook guard (HMAC, replay nonce, rate limit, size cap).webhook.send- send outbound through the kernel’s egress chokepoint.
Because they share the one front door, an automation run by a trigger and the same work run by a person obey the same rules and leave the same audit trail. See the kernel for how that single front door governs every call.