Human review matters when a run needs a person’s decision or missing information before it can continue. Otherwise, it is a blocker.
Pause where it matters
Put review where a run needs a decision or input before it can proceed.
In Runlane, a run can request either:
- an approval; or
- input from a person.
The request can include a prompt, details, choices, structured fields, or a file requirement. The run pauses and moves into a review state instead of carrying on.
Approval or input
An approval asks a reviewer to accept or reject a proposed next step.
An input request asks for something the agent cannot safely infer: a choice, a piece of text, or a required file.
Keeping those separate prevents a common failure mode: using “approve” as a vague substitute for every kind of collaboration.
The reviewer should be able to see what is being requested, respond in the requested form, and understand whether the run is waiting, approved, rejected, cancelled, or timed out.
| If the run needs | Use | The reviewer provides |
|---|---|---|
| A decision on the next step | Approval | An approval or rejection |
| Information the agent cannot infer | Input | A choice, text, or required file |
Record the decision
A reviewer’s answer should not disappear into a chat transcript.
Runlane persists the review and its audit event before attempting to signal the waiting run. If the decision was saved but the worker could not resume, the system keeps that distinction visible.
The result is an operating record that a retry can use instead of asking someone to make the same call again.
Treat timeouts as outcomes
Human review can fail operationally too. A request may remain unanswered, be cancelled, or time out.
Those outcomes should be recorded as clearly as an approval or rejection. Otherwise a scheduled process can appear healthy while it is actually waiting forever for a person who never saw the request.
A review is complete only when the team can answer:
- What was requested?
- Who responded?
- What did they decide or provide?
- Did the run resume?
- If it did not, did it fail, stop, or time out?
Skip needless gates
A team should not add a human gate merely because the work involves an agent.
Use review when a person can materially change the outcome: approve a consequential next action, supply missing context, resolve an exception, or decide that the evidence is insufficient.
Do not use it for routine work where no decision is needed. That trains reviewers to click through requests without reading them.
The right review point is close to the decision, specific about what is needed, and easy to audit afterwards.
For a practical example of those review points in an operating procedure, see From SOP to Runbook: turn defined steps into real work.
You can also see the pattern applied to a real decision brief in the Customer Escalation Brief Runbook.
Keep humans accountable
Human review makes the boundaries of the work explicit.
The agent can gather evidence, organise information, and prepare a recommendation. The operator can provide the judgment, permission, or context the process actually requires. The run then records both parts of the work.
The next person can see the actual decision instead of a final “looks good” message.
To put clear review points, ownership, and run evidence around a recurring process, compare plans or talk to us.