Approvals for AI Agents: Making Agent Workflows Safe and Repeatable

By Chris Moen • Published 2026-05-15

Integrate approval gates into AI agent workflows to ensure safety and repeatability, especially for state-changing actions. Learn how to implement approvals and best practices.

Breyta workflow automation

Quick answer

Add approvals by inserting a gate that pauses the workflow, notifies approvers, and resumes only on approve or decline. Use approvals for state-changing steps, like pushing code, merging PRs, or invoking production scripts. For coding agents, keep read-only work auto-approved, and require human checks for anything that writes or modifies state.

What “approvals” mean in practice

An approval is a controlled pause with context. The system:

  • Captures the proposed change or next action.
  • Notifies the right person or group.
  • Waits for a decision.
  • On approve, continues. On decline, branches or stops.

This model is common in production systems. You add a gate that pauses work, notifies approvers, and resumes only after a decision. Good systems let you branch and escalate when needed, as described in this guide on mastering workflow approvals for production systems (see Mastering Workflow Approvals: A Guide for Production Systems on the Breyta blog).

Why approvals matter for coding agents

Agents can work fast. They can also make destructive changes. Approvals give you a safety buffer.

  • Auto-approve read-only work. Examples: grep, find, git diff, gh pr view.
  • Require approval for state changes. Examples: git push, merging PRs, applying migrations, writing to live systems.

This boundary is a proven practice. Eric J. Ma describes auto-approving read-only commands and gating anything that modifies state in his post on safe autonomous agents (see Safe ways to let your coding agent work autonomously).

Core approval patterns you can use

Use simple patterns first. Add nuance as needs grow.

  • Single approver. One person approves the gate.
  • Two-step. A reviewer approves first. A maintainer approves final action.
  • PR-centered. Agent opens a PR. Human reviewers approve. A separate gate merges.
  • Timeout and fallback. If no one decides in time, route to a fallback or cancel.
  • Quorum or role-based rules. Require a set number of approvals or a specific role.
  • Rework loop. On “request changes,” send the agent back to update and resubmit.

Teams often encode clear policies. For example, one implementation guide suggests “no agent PR merges without two human approvals” (see AI Agent Workflow Implementation Guide for Dev Teams by Augment Code).

Real examples by agent workflow type

Modern coding agents tend to fall into four types. See Real Python’s map of IDE, terminal, PR, and cloud agents (AI Coding Agents Guide: A Map of the Four Workflow Types). Here is how approvals fit each one.

  • IDE agents
  • Auto-approve local reads and analysis.
  • Gate workspace writes that change repo state.
  • Example: Approve before the agent refactors files, runs format with write, or updates configuration.
  • Terminal agents
  • Auto-approve safe reads. Gate anything with side effects.
  • Example: The agent proposes a data-migration command. You see the dry run, then approve the real run.
  • Pull request agents
  • Agent opens a PR with changes and tests.
  • Reviewers approve or request changes.
  • Merge happens only through an approval gate. The agent can rework on “changes requested,” a pattern also noted in agentic workflow discussions (see Agentic workflows for software development by QuantumBlack).
  • Cloud or VM-backed agents
  • Agent runs on a VM. It posts results to the workflow.
  • The workflow pauses for approval before applying changes anywhere sensitive.
  • Example: Overnight code-improvement job returns a diff and test results. Approvers approve to apply changes or schedule a second pass.

What teams should look for

Approvals work best when the workflow system supports real operations at scale.

  • Deterministic runs. You want clear, repeatable behavior.
  • Run history and step outputs. You need to inspect what happened and why.
  • Waits and external callbacks. Long-running work must pause cleanly and resume later.
  • Notifications. Approvers need timely, actionable prompts.
  • Versioned releases. Draft vs live separation keeps unstable changes from production.
  • Resource handling. Large artifacts should be referenced and inspectable without bloating state.
  • Scriptable CLI. Agents and humans should operate workflows through stable commands.

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, agent flows, and autonomous jobs.

What Breyta provides for approvals and agent workflows:

  • First-class approvals and waits. Flows can pause for human confirmation or wait for external systems. They resume with state intact.
  • Deterministic runtime and run history. You can inspect step-by-step outputs.
  • Versioned releases and rollout control. Draft and live are cleanly separated. You can approve a change before you promote it.
  • A CLI that is agent-first. Commands return stable JSON that agents can parse and act on.
  • Orchestration for local and remote agents. You can kick off work over SSH, pause with a wait, and resume on callback. This is a documented long-running pattern.

Breyta’s step families include wait, notify, ssh, http, llm, search, db, kv, sleep, and function steps. Triggers include manual, schedule, and webhook. This lets you coordinate classic backend work and agent-in-the-loop tasks in one place.

Examples in current Breyta usage:

  • Autonomous code improvement on a VM. The flow kicks off a detached worker over SSH, waits for a callback, then returns a review-ready payload. You add an approval gate before apply.
  • Draft-apply-review for workspace changes. The flow validates a draft fix, pauses for human approval, then releases and promotes it live once approved.
  • Content operator on a VM. It generates drafts, persists memory, requests approval, and dispatches approved posts.

These patterns show how approvals, waits, and versioning work together in practice.

Sample approval flow shapes in Breyta

You can shape approvals into the flow with simple, explicit steps.

  • PR approval before merge
  • Trigger: open PR or schedule.
  • Steps:
  • Analyze changes and tests.
  • Notify reviewers with summary and links.
  • Wait for approval.
  • If approved, merge. If declined, notify and stop. If changes requested, rework and resubmit.
  • Remote agent with safe apply
  • Trigger: manual or webhook.
  • Steps:
  • SSH to start agent on a VM.
  • Wait for a callback with a diff or plan.
  • Persist large outputs as resources and share links.
  • Approval gate with context.
  • If approved, apply changes over SSH or call APIs. Else, notify and exit.
  • Terminal policy gate
  • Trigger: manual.
  • Steps:
  • Run read-only commands and capture outputs.
  • Propose state-changing commands with a preview.
  • Approval gate listing the exact commands.
  • Execute only on approval. Record outputs and artifacts.

Breyta’s resource model helps with large artifacts. You can persist outputs and pass compact res:// refs. That keeps runs light and still inspectable.

Implementation tips that keep agents safe

Use simple policies first. Expand over time.

  • Define non-destructive vs destructive actions. Auto-approve reads. Gate writes.
  • Make each approval atomic. One action per gate. Avoid bundling unrelated changes.
  • Include a dry run or diff. Show exactly what will happen on approve.
  • Add timeouts and clear fallbacks. Do not let gates block for days.
  • Record outcomes in run history. Keep a paper trail of who approved what and when.

FAQ

Where should I put the first approval gate?

Place it right before the first state change. Examples: merging a PR, pushing code, updating infrastructure, or writing to a production database.

Do I need multiple approvals?

Start with one. Add a second approver for sensitive paths like infra changes or security fixes. Use role-based rules when needed.

How do I handle long-running agent work?

Use a wait step and an external callback. The workflow keeps state. The agent does the heavy work elsewhere. Resume when the result is ready.

How do approvals work with large artifacts?

Store large outputs as resources. Pass refs into the approval context. Let approvers view details without slowing the run.

Closing thought

Approvals make agent workflows safe, visible, and repeatable. Add a clear gate. Share the right context. Let the agent move fast on reads, and require a simple yes or no on writes. That balance is what turns demos into production workflows.