How to add human approval to an AI agent

To add human approval to an AI agent, insert an approval gate before any high-stakes action. The run pauses at the gate as a durable checkpoint, a reviewer approves or rejects it from a queue, and the agent resumes only once approved — so a person authorizes the step without anyone holding a live process open.

Autonomy is the whole appeal of an agent, right up to the moment it does something you can't take back. The pattern that keeps agents useful and safe is human in the loop AI agents: the model plans and acts on its own, but a person signs off on the handful of steps that actually matter. This post covers where to put that gate, why it has to be durable, and how to give non-engineers a place to approve or reject without reading a stack trace.

Why production agents need a human in the loop

Most agent steps are cheap and reversible — reading a document, calling a search tool, drafting text. A few are neither. Sending money, emailing a customer, deleting records, issuing a refund, merging a change: these are the actions where a wrong decision has a cost you can't undo by retrying. An agent that is right ninety-nine times out of a hundred still can't be trusted to fire those steps unsupervised, because the one exception is the one that reaches a real person or a real ledger.

The goal is not to babysit the whole run. It is to draw a line around the irreversible actions and require a human decision only there. Everything before the line stays fully autonomous; the agent does its research, its reasoning, and its drafting on its own. The line is where an AI agent approval workflow begins — a deliberate, auditable pause in front of consequence.

What an approval gate is

An approval gate is a node in the agent's graph that blocks its branch until a decision arrives. When the run reaches the gate, it stops advancing down that path. It does not poll, it does not spin, and it does not fall through to a default — it simply waits. The step immediately after the gate only runs if the decision is approve; a reject sends the run down a different path entirely.

Think of the human approval gateas a valve on a single branch rather than a pause on the entire agent. Other branches that don't depend on the gated action can keep running; only the work downstream of the gate is held. That framing matters, because it means adding approval to an agent is a local change — you drop a gate in front of the risky node, and the rest of the graph is untouched.

The gate must be durable

Here is the part that quietly breaks most homegrown attempts. A person may approve in thirty seconds, or after lunch, or on Monday. You cannot hold a live process open for that long — a setTimeout or a blocked request thread is hostage to the next deploy, the next crash, or the next idle timeout. If the run lives only in memory while it waits, the wait itself is the failure mode.

A durable gate solves this by making the paused run a checkpoint instead of a held process. State is written after every node, so the moment the run reaches the gate its full context is already persisted. The process is then free to exit. When the decision finally arrives — minutes or days later — the run is restored from that checkpoint and continues. Runs paused at approval gates survive restarts indefinitely; a reviewer who takes the weekend costs you nothing but the wait.

This is also what makes approval safe across a deploy. On restart, interrupted runs resume from their last checkpoint, so a run parked at a gate when you ship new code is still there afterward, at the same position, with the same state. The person on the other end never sees the seam.

Approvals as a queue non-engineers can use

A gate is only half the design. The other half is where the human actually makes the call — and that person is usually not the engineer who built the agent. It might be an operations lead, a support manager, or a compliance reviewer. They need to see what is waiting, understand what they are authorizing, and act, all without touching code or reading logs.

The right shape for this is a queue. Paused runs collect in one place; a reviewer opens the queue, sees each pending decision with the context it needs, and clears them one by one. In Ballast, approvals happen in a queue that requires no technical context, so the people who own the business risk are the people who clear the gate. The visual builder lets operators assemble workflows from agents, tools, conditions, and approval gates on a canvas, and engineers drop to configuration and custom tools where the logic needs it — so building the workflow and running the workflow don't demand the same skill set.

Approve, reject, and why rejection paths matter

Every gate has two exits, and it's tempting to only design the happy one. When a reviewer clicks approve, the run resumes and the gated action fires — straightforward. The question that decides whether your AI agent approval workflow is actually production-grade is what happens when they click reject.

Rejection is not an error, and it should not look like one. It is a valid outcome of the workflow, and the graph should have somewhere for it to go. A reviewer might reject and route the task back to the agent for another attempt, hand it to a person, log the refusal and end the run cleanly, or notify the requester. What a rejection must never do is leave the run stuck or, worse, let the gated action leak through anyway.

• Approve resumes the branch and lets the high-stakes node run, with the decision recorded against the run.
• Reject takes an explicit alternate path — retry, escalate, or stop — so the run always ends in a defined state.
• Either way, the decision, the reviewer, and the timing belong in the audit log, because "who approved this" is a question you will eventually be asked.

Building it yourself vs. a runtime

You can build an approval gate on top of an agent framework. Frameworks like LangGraph or CrewAI give you the primitives to define a graph and pause a branch. What they don't hand you is the persistent system underneath: a place to store paused runs that outlives the process, a way to resume exactly where you left off, a queue a non-engineer can use, and an audit trail of every decision. Those are the parts that turn a pause into a real human approval gate, and they're the parts you end up writing yourself.

That's the line between a framework and a runtime. Frameworks give primitives; a runtime gives a production system — checkpointed state, approval gates, per-step cost, and an audit log. The pause is easy. The durability, the queue, and the accountability around the pause are the work, and they're the reason a "quick add human approval" task turns into a quarter of infrastructure.

How Ballast does human-in-the-loop

Ballast is a durable runtime for production AI agents, and human-in-the-loop is a first-class primitive, not a bolt-on. You place an approval gate in front of any high-stakes node on the canvas. When a run reaches it, the run pauses as a checkpoint — and because state is written after every node, that checkpoint survives restarts indefinitely. There is no live process to keep warm while a person deliberates.

The reviewer works from a queue that needs no technical context: they see what is pending, they approve or reject, and the run resumes the instant a human approves — picking up at the next node with full state intact. A rejection follows its own path in the graph. Every decision is cost-attributed and written to the audit log alongside the rest of the run, so approval isn't a black box bolted to the side of your agent — it's part of the same governed execution. See the human-in-the-loop guide for the full setup.

Where to go next

• Follow the human-in-the-loop guide to add an approval gate to a run step by step.
• See approval gates alongside the rest of the run model on the product page.
• Ready to try it? Start free and put a human in the loop on your first agent.