Approvals and verifier gates

A repeating process needs places where it stops for judgment, and a workflow carries a few: a human approval that waits for a person to approve or reject, an ask-human node that stops for a person's answer, and a verifier gate that checks an agent's output before the work moves on. All are part of the same control story the rest of Task Machine runs on — discuss to decide, inbox to approve, tasks to steer — applied inside a process that runs again and again. Each one executes inside a workflow run: this page describes how it gates a running workflow.

A human approval node is where a person decides

A human approval node is a deliberate pause built into the graph. You write the request a reviewer will see and choose who may decide it — a specific member, a role, a project's editors, or anyone holding a required permission — so the run holds at that point until a permitted person approves or rejects. This is the gate where autonomy stops and your judgment enters: an agent can carry a process most of the way, but an approval node is where it must wait for you before anything irreversible continues.

When a run reaches an approval node it pauses: the run opens an approval request against its backing task, routes it to a person the scope authorizes, and moves to a paused state until a decision comes back. Approval resumes the run down its approved route. A rejection takes a separate rejected route when the node was wired with one — so a workflow can branch into rework or a fallback instead of stopping — and otherwise fails the run with the reviewer's reason. The request surfaces in your inbox and on the task timeline and notifies the reviewer by email, the same places every other decision lands, and the run view shows it on the waiting node with Approve and Reject right there — so you can clear a paused run from wherever you happen to be watching it, and staying in control of a workflow is the same habit as staying in control of any task. The bundled Daily Standup template ends on exactly this kind of node — the agent gathers and drafts, then hands the standup to an approval step where you review and steer the day.

An ask-human node stops for an answer, not a decision

Not every human pause is a yes or no. An ask-human node stops the run to ask a person a plain question — which direction to take, a missing detail, a judgment call the agent should not make alone — and carries their answer forward into the rest of the run. Where an approval gate ends in approve or reject, an ask-human node ends in whatever the person writes back.

It works the same way an approval does: when the run reaches the node it opens a question against the backing task, routes it to a chosen member or, when none is named, to whoever started the run, and pauses until the answer arrives. The question lands in the reviewer's inbox and on the task timeline and notifies by email; answering it resumes the run with the answer available to the steps that follow. This is the lighter half of staying in control of a process — a workflow can stop to gather a person's input, not only to wait for their sign-off.

A verifier gate checks an agent's output against its requirements

A verifier gate is the automated counterpart to a human approval: instead of waiting for a person, it has a second agent check the first agent's work. An agent or artifact node can name a verifier agent and a set of outcome requirements — a plain description of what a good result looks like — and when the node finishes, the run asks the verifier to read the output against those requirements and return one of three verdicts: PASS, FAIL, or UNCERTAIN. A pass lets the run continue to the next node. A fail stops the run at that node rather than letting unverified work through. An uncertain result routes a task question to the workflow starter, pauses the run, and continues only after the human answer is recorded.

A verifier result is recorded in full — the verdict, the reasoning behind it, the structured issues it found, and the working directory it checked — so a gate that passes or fails work leaves evidence, not just a flag. This is what keeps repeated agent work honest at scale: every run carries proof that its output was measured against what it was supposed to produce. Where an approval bounds a process with a person's judgment, a verifier bounds it with stated requirements, and a workflow can use both.

How the gates fit the run

Every gate runs inside the workflow run and writes to the same papertrail every other step does. A human approval or an ask-human question pauses the run and lands in your inbox; a verifier runs as agent work and records its verdict on the node it checked. None is a separate system to watch — they are points on the run's timeline where judgment, human or stated, decides whether the work moves on.

One edge is worth naming. Verifier gates do not retry automatically today; they pass, fail, or pause for human review when the verifier is uncertain. Runtime failures and timeouts do retry on their own with a standard bound, but the richer retry policies you author in the builder — attempt counts and backoff — are carried with a published version and not yet interpreted by a run. Budgets and retries covers that other half of staying in control: bounding how much repeated work can spend and how often it retries.