Human-in-the-Loop Approvals in Production Workflows

By Chris Moen • Published 2026-04-09

Discover how to integrate human-in-the-loop approvals into your production workflows to enhance security, compliance, and control. Learn best practices and see practical examples.

Breyta workflow automation

Quick answer

Workflow approvals are built-in pauses where a human reviews and decides before the flow proceeds. Add a wait, notify the reviewer, capture a decision, and branch on approve or reject. Make it durable so the workflow survives crashes and time gaps.

What this means in practice

An approval is a controlled handoff. The workflow:

  • Produces a draft or action request.
  • Notifies the right person or group.
  • Waits for a decision with a clear timeout.
  • Resumes on approval, requests changes on reject, or escalates on timeout.

You can do this with signals or callbacks that resume a paused run. Durable runtimes keep the state and history intact while waiting, which mirrors how Temporal handles human signals.

Why it matters for production workflows

Approvals reduce risk and add accountability. They:

  • Catch issues before changes land in prod.
  • Enforce separation of duties and audit trails.
  • Prevent autonomous actions that users cannot undo.
  • Improve trust with stakeholders in regulated flows, similar to how human-in-the-loop controls support compliance in sectors like KYC and audit as noted by Moxo’s examples.

For critical changes, teams often require human oversight. You can see this framing in guides that stress review before deployment for safety and clarity, like the OneUptime approval walkthrough.

Patterns that work

Use a few reliable building blocks:

  • Pause and resume
  • Add an explicit wait step.
  • Resume via button, API callback, or CLI command.
  • Branch on decision
  • Approve path continues the plan.
  • Reject path loops back with comments or routes to a human editor.
  • Durable state
  • Persist draft outputs.
  • Resume even if a browser or worker restarts.
  • Notifications and reminders
  • Route to the right on-call or owner.
  • Escalate on timeout.
  • Audit trail
  • Record who approved, when, and what changed.

Durability matters. If a site or worker restarts during review, you should not lose the approval or force users to re-approve. That is the core idea behind durable human-in-the-loop flows also seen in Temporal’s signals and queries approach.

Practical examples

Content publishing

  • Draft post created automatically.
  • Reviewer gets a link with summary, preview, and diffs.
  • Approve to publish. Reject to request edits with notes.
  • Timeout escalates to an editor.

Outbound customer emails

  • LLM drafts a reply.
  • Human checks tone, facts, and links.
  • Approve to send. Reject to regenerate with constraints.
  • Keep a record of who approved.

IT change requests

  • A change ticket reaches “ready to apply.”
  • Ops lead approves or defers after checking impact.
  • Approve triggers apply step. Reject adds context and reschedules.
  • SLA timers and on-call escalations protect timelines. This matches best practices where critical systems need review, as described in the OneUptime guide.

Payments over threshold

  • System flags high-value payouts.
  • Finance reviews documents and recipient details.
  • Approve releases funds. Reject routes to investigation.
  • All fields and approver identity are logged.

Code operations with agents

  • Agent proposes a PR and a rollout plan.
  • Human verifies tests, scope, and release notes.
  • Approve to merge and deploy. Reject to iterate.
  • Long-running steps resume cleanly after human checks.

What to look for in an approval-capable runtime

Core capabilities

  • Durable waits and resumable state.
  • Clear run history with step outputs.
  • Versioned releases so drafts do not affect live runs.
  • First-class human approvals and external callbacks.

Operational needs

  • Timeouts, reminders, and escalation paths.
  • Branching on approve, reject, or no response.
  • Secret and connection management separate from logic.
  • Support for long-running and VM-backed work.

Agent fit

  • A CLI or API that an agent can call safely.
  • Stable JSON outputs for parsing.
  • Patterns for pausing, revising prompts, and resuming, which aligns with how agent workflows add checkpoints, as summarized in Breyta’s own HITL post.

How Breyta fits this use case

Breyta is a workflow and agent orchestration platform for coding agents. It gives you explicit waits, approvals, notifications, and callbacks. You can run multi-step automations, keep state across time, and resume after human input with deterministic behavior.

What you get out of the box

  • Deterministic execution with a clear run history.
  • Versioned flows with a draft vs live split.
  • Wait steps, approvals, external callbacks, and notifications.
  • Resource refs for large artifacts, so you pass compact links instead of big blobs.
  • SSH steps for VM-backed agents and a documented remote-agent pattern using a wait and callback.
  • An agent-first CLI with stable JSON for authoring, running, and inspecting flows.

Long-running agents

  • Kick work on a VM with an SSH step.
  • Pause with a wait.
  • Resume when the remote process posts back to a callback URL.
  • Continue to an approval step before applying changes. This mirrors the durable pause-and-signal model used by runtimes like Temporal, but within Breyta’s workflow layer.

Approvals and billing

  • Triggers, waits, and approval steps do not count as billable step executions in Breyta plans.

Add an approval to a Breyta flow

Basic pattern

  • Produce a draft
  • Use steps like :llm or :http.
  • Persist large output as a resource ref.
  • Notify and wait
  • Use :notify to alert reviewers.
  • Add a :wait step for approval with timeout rules.
  • Resume and branch
  • On approval, proceed to publish or apply.
  • On reject, loop back with reviewer comments for revision.
  • On timeout, escalate or close out.

Example: content approval

  • Trigger: webhook from CMS draft created.
  • Steps:
  • :llm summarizes changes.
  • :persist stores a full preview artifact as a resource.
  • :notify sends reviewer the summary and resource link.
  • :wait pauses for approve or request-changes.
  • If approve, :http publishes.
  • If reject, regenerate summary or route to an editor.
  • Result:
  • Full history, decision, and outputs logged.
  • Stable behavior across retries and long pauses.

Example: code apply with a VM-backed agent

  • Trigger: manual run by a maintainer.
  • Steps:
  • :ssh starts a remote agent that prepares a patch.
  • :wait pauses for the agent’s callback with patch details.
  • Approval step presents the patch summary and test results.
  • If approve, :ssh applies changes on the VM, then :http posts status.
  • If reject, notify and file a follow-up task.
  • Result:
  • Long-running remote work is orchestrated safely.
  • Human approval gates the apply.

Implementation tips

Make decisions obvious

  • Show a clear preview, diffs, and the intended side effects.
  • Capture comments for rework loops.

Protect your flow

  • Set timeouts with reminders and escalation routes.
  • Keep approvals atomic. One click to approve, with identity captured.

Keep artifacts inspectable

  • Persist big outputs as resources.
  • Link them in notifications for quick review.

Control rollout

  • Use draft vs live to test the approval path.
  • Promote only when the flow behaves as expected.

Where approvals shine

  • Actions that spend money or move data.
  • Public or customer-facing content.
  • Infrastructure and schema changes.
  • Legal, compliance, and policy-sensitive steps.

Approvals do not need to slow you down. They focus attention where it is most useful. Durable waits and clear run history keep the process smooth while maintaining control.