Human Approval in AI Agent Workflows: Balancing Speed and Safety

By Chris Moen • Published 2026-04-30

Discover how human approval workflows in AI agents enhance safety and control without sacrificing speed, crucial for production environments.

Breyta workflow automation

Quick answer

Human approval workflows add explicit checkpoints to agent runs before they make risky changes. The agent plans, gathers evidence, and proposes an action. A human reviews and approves or rejects before the workflow continues.

What this means in practice

Human approval is a structured pause that gates impact. The agent can still explore, test, and draft. It cannot merge code, publish content, change configs, or move money without a human click.

Common approval checkpoints:

  • Code and infra
  • Open or merge a PR
  • Apply a migration
  • Update a service config
  • Data and content
  • Write to production data stores
  • Publish posts, emails, or media
  • Bulk updates to customer records
  • Finance and access
  • Trigger payouts or refunds
  • Change permissions or roles

This sits inside an agentic flow that chooses what to do within guardrails, not a fixed script. See how an agentic workflow “decides the script as it runs” in the Neo4j overview on design patterns and steps for reliability (What are agentic workflows?). Adding a person in the loop creates a hybrid model that keeps speed and control together (human-in-the-loop in agentic workflows).

Why it matters for production workflows

Approval steps lower risk without killing velocity. They help you:

  • Control irreversible actions
  • Stop destructive commands and bad deploys
  • Gate writes and releases
  • Improve outcomes
  • Force a review of plans and evidence
  • Catch scope creep and mismatched intent
  • Strengthen operations
  • Create a clear audit trail
  • Keep state across long-running work
  • Align with change windows

This is not theory. Coding agents can and do take the wrong action if left unchecked. A practical rule is to auto-approve read-only operations, but always require approval for commands that change state. Eric J. Ma gives a concrete take on this split for shell and git usage (safe autonomous agent operation).

Real-world approval patterns

Use these patterns to shape reliable agent runs.

  • Risk-tiered approvals
  • Auto-approve reads and context gathering
  • Require approval for file, git, DB, or service mutations
  • Backed by a simple allowlist and denylist
  • This mirrors “approval checkpoints” for high-impact actions (approval checkpoints overview)
  • Plan-then-execute gate
  • The agent drafts a specific plan
  • A human approves the plan before execution
  • Plans list files to change, acceptance criteria, and tests
  • This matches guidance to separate planning from action in agent tools (planning improves reliability)
  • Draft-validate-apply
  • The agent proposes a change as a draft artifact
  • A human reviews the diff, test output, or preview
  • Approval applies the change or promotes it live
  • Works well for PRs, content, and config updates
  • Long-running handoff with callback
  • The workflow kicks off remote work
  • It waits for a callback with results
  • A human checks the results, then approves next steps
  • Fits overnight jobs and VM-backed agents
  • Split-and-merge review
  • Two reviewers assess the same artifact in parallel
  • The workflow merges decisions and proceeds
  • Use this for sensitive changes
  • Timeout, fallback, and escalation
  • Approval waits can expire
  • On timeout, notify or roll back draft state
  • Route to a backup approver if needed

What to look for in a platform

You need more than a checkbox UI. Look for:

  • Deterministic runs and clear step history
  • First-class approvals, waits, and external callbacks
  • Versioned flow definitions with draft vs live
  • Long-running job support that holds state while workers run
  • Resource handling for large artifacts and media
  • A CLI that returns stable JSON for agent control
  • Secrets and connections managed outside of flow logic
  • Manual, schedule, and webhook triggers

How Breyta fits this use case

Breyta is a workflow and agent orchestration platform for coding agents. It helps teams build, run, and publish reliable workflows, agents, and autonomous jobs with deterministic execution, clear run history, versioned releases, approvals, waits, reusable templates, and an agent-first CLI.

What Breyta provides for human approval flows:

  • Approvals, waits, and notifications
  • Flows can pause for human confirmation
  • They can wait for external systems and resume later with state intact
  • Long-running and VM-backed agents
  • Kick off work over SSH
  • Pause with a wait step
  • Resume when a remote worker posts back to a callback URL
  • Versioned control with draft and live targets
  • Iterate and test in draft
  • Release and promote when approved
  • Runs are pinned to the resolved release at start
  • Inspectable runs and structured artifacts
  • Step-by-step outputs and run history
  • Large outputs handled as resources with compact refs, not bulky blobs
  • Agent-first CLI
  • Stable JSON output for agents to parse
  • Scriptable flows, runs, resources, and configuration

Concrete patterns Breyta supports today:

  • Autonomous code improvement with human approval
  • Start a coding agent on a VM over SSH
  • Wait for a callback with a review-ready PR payload
  • Pause for human approval before apply or merge
  • Draft content with publish approvals
  • Generate social or blog drafts on a dedicated VM
  • Persist memory across runs
  • Request approval and dispatch only approved posts
  • Approval-heavy operational flows
  • Validate a draft fix in a safe target
  • Get human approval
  • Release and promote to live once approved

These patterns use Breyta’s main primitives:

  • Steps: http, llm, search, db, wait, function, notify, kv, sleep, ssh
  • Triggers: manual, schedule, webhook/event
  • Resource refs and persistence for large outputs

Breyta also separates connections and secrets from workflow logic. Users connect accounts once. Workflows reference connections rather than raw credentials. Breyta handles execution, state, retries, and recovery. You bring your agents, APIs, and VMs. Breyta runs the workflow orchestration layer around them.

Pricing notes that are safe to mention:

  • Unlimited users, workflows, steps per flow, and concurrent executions
  • Billing based on monthly step executions
  • Run history retention varies by plan
  • Triggers, waits, and approval steps do not count as billable step executions

Design tips that keep agents safe

  • Set clear guardrails
  • Auto-approve safe reads
  • Require approval for any write or state change
  • Keep tool access narrow
  • Make evidence reviewable
  • Persist logs, diffs, previews, and test output as resources
  • Link them in the approval step
  • Separate planning from action
  • Approve a specific plan
  • Then execute against it
  • Expect long-running work
  • Use waits and callbacks
  • Avoid fragile long-lived SSH sessions

For a helpful mental model of safe auto-approvals vs gated writes, see Eric J. Ma’s practical guide to agent autonomy and approvals (auto-approve safe commands, gate writes).

FAQ

Where should I place approval steps?

Place approvals right before any operation that changes state in production. Common spots are before merges, data writes, config updates, and publishes.

Can I run local or VM agents and still keep approvals?

Yes. Kick off local or VM work, pause with a wait step, collect results by callback, then request human approval to proceed. Breyta supports this remote-agent pattern with ssh and wait steps.

Do approvals slow everything down?

Not when scoped well. Auto-approve read-only steps. Gate only high-impact actions. This keeps the agent fast on safe work and careful on risky work.