Skip to main content
Ask a person when the next decision needs their judgement. Use it before publishing a report, applying a migration or sending a payment. The run records the question and waits for an answer. A yes lets it continue. A no can return the work with the person’s notes. When the decision can be made by models, ask a panel.

Shape

The step

approval asks one question through the run’s callbacks client, and target names the step a no goes to:
examples/approval.ts (excerpt)
The question is about what came before: by default the request’s input is the outcomes of the steps this one depends on, so a changed attempt upstream is a new question, and the same question about the same thing is the same request. Give input to say otherwise, or bind the approval to the exact files it approved with proof acceptance. A no needs a home and a budget. With target, the refusal goes to that step as a revision request with the note as its one finding. The approval step must list that target in acceptsKickbackTo, and the graph’s maxKickbacks must allow it, or the run fails with the note instead. Without a target, a refusal fails the step with the note as its summary:
examples/approval.ts (excerpt)
Nobody answering is a pause, not a failure. Without answer, the step posts the request and returns paused with the request as its data. A router claims the request and submits { approved, note? }. Run the job again with the same client and the step finds the answer in the client’s history. run takes that client as callbacks: the in-memory one that lives for the run, the default, or the stored client over a directory, which lets a paused run find its answer after a restart. Use one approval label per workflow; two steps with the same label ask the same question and supersede each other. A question that is neither pending nor answered fails the step plainly instead of waiting for nothing.

What the run did

The writer here is a function that leaves the header row out once, and the person answers from the file itself, so it runs offline. Run it with npx tsx approval.ts:
Output
The person said no to the first attempt and yes to the second. implement ran twice: the refusal went there as a revision request with the note as its finding, the writer ran again with the note in hand, and the question was asked again about the new attempt. In a real team the answer arrives through the callbacks client, from a surface in a browser or a host.
examples/approval.ts

Next steps

  • Feature delivery: a person approves the exact bytes as the last of seven steps, before the change lands.
  • Callback gates: the client, the routers and the stored history the step is built on.
  • Runtime: approval, pipeline and maxKickbacks.