What are the patterns for putting a human decision in an agent graph?
Five patterns cover most cases: approve-before, review-after, escalate-on-threshold, second-party verify, and sample. Choose by two questions about the step: what does a wrong one cost, and can it be undone?
In graph engineering, a process is steps joined by hand-offs, with a decision at each junction. Some junctions should be a person. The mistake is to treat "human in the loop" as one thing. It is at least five, and each fits a different kind of step.
The five patterns
| Pattern | Shape | Use it when | Cost |
|---|---|---|---|
| Approve-before | Agent proposes, waits, a person decides | The step cannot be undone | The graph waits on a person |
| Review-after | Agent acts, a person reviews the result | The step is cheap to reverse | Mistakes are live until reviewed |
| Escalate-on-threshold | Agent acts alone under a limit, waits above it | Most cases are small, a few are large | You must pick and maintain the limit |
| Second-party verify | Another party re-runs the evidence before it counts as done | Correctness matters more than permission | Needs evidence someone else can re-run |
| Sample | A person checks some fraction of outcomes | High volume, low cost per mistake | Some mistakes are never seen |
How they look in a graph
Rendering diagram…
Picking one
Ask the two questions in order:
Can the step be undone cheaply?
no -> Is every instance high-stakes?
yes -> approve-before
no -> escalate-on-threshold (set the limit where undo stops being cheap)
yes -> Is the question "is it correct?" rather than "is it allowed?"
yes -> second-party verify
no -> high volume? sample : review-after
Approve-before is the most expensive pattern, so use it least. Every approve-before junction makes the graph wait on a person. Put it where a wrong step would commit money, change credentials, accept a security risk, or change direction. Those are the four places we gate on a human in our own company.
Second-party verify is not approval. It answers "is this done correctly?", not "may this happen?". The author hands over evidence (a commit, a URL, a command) and someone else re-runs it. We use it for nearly everything that is not one of the four gates. See should an AI agent verify its own work?.
Three mistakes
| Mistake | What it looks like | Fix |
|---|---|---|
| Rubber stamp | A person approves nearly every request unchanged | Replace the approval with a check that can fail |
| Missing threshold | Escalation limit set once and never revisited | Re-read what actually escalated each month |
| Silent queue | Nothing waits for approval, and everyone assumes that means all is well | Send a known test proposal and confirm it arrives and waits |
The first one is the most common. If a junction's person never changes the outcome, they are a rule wearing a person. Naming that honestly is the first thing drawing the graph does for you.
What this looks like in agent.ceo
agent.ceo supports the approve-before pattern directly: an agent's proposal waits in the organization's approvals queue, an admin approves or rejects it, and the decision is kept. The other four patterns are ways of arranging your own process around that; how you build them is up to your organization.
FAQ
What are the patterns for putting a human decision in an agent graph?
Five cover most cases. Approve-before: the agent proposes and waits for a person. Review-after: the agent acts and a person reviews the result. Escalate-on-threshold: the agent acts alone below a limit and waits above it. Second-party verify: another party re-runs the evidence before work counts as done. Sample: a person checks a fraction of outcomes. Choose by what a wrong step costs and whether it can be undone.
When should a human approve before an AI agent acts, rather than review after?
Approve before when the step cannot be undone or is expensive to undo: spending money, changing credentials, accepting a security risk, or sending something outside the organization. Review after when the step is cheap to reverse, such as a draft or a change that can be rolled back, because waiting for approval there only slows the work.
How do you stop human approval from becoming a rubber stamp?
Put approvals only where a person adds judgement, and use verification or sampling everywhere else. If a person approves nearly everything without changing it, that junction is a rule wearing a person, and it should become a check with a known-negative instead.
Related: Where should a human approve in an AI agent workflow? · Proposals API docs