Skip to content
CodeBook

Approvals and people

Human stations, the agent-after-approval worker type, and where to put a person so the line still holds.

A person is a worker type. That is the whole design: approval is a station in the workflow — the factory's quality control — rather than a mode bolted onto the end of one. And a gate is enforced by the system: nothing an agent writes can move a card past a person who has not said yes.

Human stations

Set the worker to A person and choose who. The card waits there for them. They need write access to the workflow, so you cannot make somebody responsible for a station they cannot see.

Everything else about the station works as usual: it can notify by email on arrival, and it routes on pass and fail like any other — so a person rejecting work sends the card back with their reasons, exactly as QA does.

An agent, after approval

Set the worker to An agent, after approval. The agent's run is prepared and then held until the person you named decides.

Under Runs the job shows as awaiting approval with approve and reject buttons. Approving lets it proceed; rejecting stops it, and the decision is recorded against the job.

Use this where the action is expensive or irreversible: a deployment station, a publication station, anything that touches production or a customer.

Where to put people

At the end. A Human review station before Done means nothing reaches Done without somebody looking. This is the single most valuable person-shaped station in a delivery workflow, and nearly every template ends with one.

At the escalation. Every station's when it is blocked or out of retries should lead somewhere a person is waiting. A loop that has exhausted its retries has, by definition, failed to solve itself.

Before anything irreversible. Robotics simulation ships with Human hardware approval for exactly this reason.

Where handoffs arrive. A workflow that receives cards from other workflows should still end with a person.

What a person owes the line

When you reject work, write why in the discussion. The engineer's next run reads that thread — a rejection with no reason is a card that comes back unchanged.

This is the same contract the agents are held to. Their skills require evidence and a verdict; a human station that returns "no" with nothing attached is the weakest link in a loop that otherwise carries its reasoning forward.

Notifications

Approval and escalation stations are where Notify by email earns its place. A card waiting for a person who does not know it is waiting is the failure mode automation introduces most often. See Notifications.

Needs you: everything waiting for a person, in one list

You should not have to open every board to find what is waiting for you. The workspace Home page shows Needs you: across every factory in the workspace that you can open, longest-waiting first.

It lists Which is
A question for a person The manager or CodeBook asked something on a card, and nobody has answered.
Waiting for approval A run that waits for a person's approval before it goes on.
At a person's station A card in a column a person works.
Waiting for a person's review A run drawn for a human review of the work.
A command needs a yes An agent asked to run a command on your runner that needs approval.
A pull request to merge Finished work CodeBook left for a person to merge — a protected path, a risk score at or above your line, a refusal at the host — with why.

Each line opens its card. When the list is empty, everything in the workspace is working without you.