How to Build a Developer Approval Workflow in Breyta

By Chris Moen • Published 2026-05-07

Learn how to implement robust developer approval workflows in Breyta, ensuring safe, controlled, and efficient code changes with human checkpoints.

Breyta workflow automation

Quick answer

You create a developer approval workflow in Breyta by modeling a flow with a trigger, steps, an approval wait, and a final apply step. Build it in draft, run and inspect it, then release it to live when ready. Breyta’s deterministic runtime, versioned flows, and first-class approvals make this safe for production.

What “approval workflow” means in practice

An approval workflow adds an explicit human checkpoint to a technical process. For developers, that often looks like:

  • Plan or propose a change set
  • Produce artifacts to review
  • Pause and wait for approval
  • Apply the change if approved
  • Notify stakeholders

In Breyta, this maps to the core primitives called out in the platform’s own framing of coding agent workflows: triggers, steps, waits, and approvals. See the overview of these four primitives in Breyta’s guide to triggers, steps, waits, and approvals.

Why it matters for production workflows

Approvals help you keep control. They let teams:

  • Pause risky steps until a human confirms them
  • Keep a clear run history with step outputs and decisions
  • Pin releases so draft changes do not change live behavior
  • Orchestrate local or VM-backed agents without losing state

Breyta is built for this shape of work. It provides deterministic execution, run history, versioned releases, explicit waits and approvals, and a CLI that agents and engineers can rely on. For a deeper framing of agent pipelines with approvals and waits, see Breyta’s guide on building reliable agent pipelines.

What teams should look for

When you add approvals to developer workflows, look for:

  • Deterministic behavior and clear run history
  • First-class approvals and waits
  • Safe draft-to-live lifecycle with versioned releases
  • Long-running job support with clean callbacks
  • Secret and connection management separate from flow logic
  • Resource handling for large artifacts

These requirements map directly to Breyta’s model: versioned flows, explicit approval and wait steps, remote-agent patterns, resource refs, and a CLI built for coding agents.

How Breyta fits this use case

Breyta is a workflow and agent orchestration platform for coding agents. It lets you:

  • Define flows with triggers, steps, approvals, waits, and explicit concurrency
  • Orchestrate local runs or agents on VMs over SSH, then wait for callbacks
  • Keep state across pauses without holding open fragile connections
  • Inspect step outputs and run history before you promote to live
  • Manage connections and secrets once, then reference them in flows

You can see the default flow lifecycle in Breyta’s quickstart: Start Here.

A step-by-step way to create a developer approval flow

Below is a practical pattern for a code-change workflow that pauses for approval before it creates a PR.

1) Sketch the flow structure

  • Trigger: manual or webhook from your system
  • Steps:
  • Plan: shape a proposed change or patch set
  • Build: run a local or VM-backed agent to produce artifacts
  • Persist: store large outputs as resources and return compact refs
  • Approval: wait for a human checkpoint
  • Apply: create a PR via an API call
  • Notify: send a confirmation

2) Create the flow in draft

  • Initialize your workspace with the CLI.
  • Author a versioned flow definition with a stable slug and description.
  • Push draft changes. Flows pushed to draft do not change live behavior.

3) Wire connections and secrets

  • Connect accounts once. Store secrets securely.
  • Reference connections in the flow instead of embedding raw credentials.

4) Add the planning and build steps

  • Use HTTP or function steps to gather context and plan the change.
  • Kick off agent work on a VM over SSH if needed. This is a common pattern for long-running jobs.

5) Handle long-running work with waits

  • Start remote work over SSH.
  • Pause with a wait step.
  • Resume when the remote worker posts back to a callback URL.

This is the documented remote-agent pattern in Breyta. It keeps workflow state without holding an SSH session open.

6) Persist large artifacts

  • Use resource persistence for large outputs when size is uncertain.
  • Pass res:// refs to downstream steps. This keeps state compact and inspectable.

7) Insert the approval checkpoint

  • Add an approval step after artifacts are ready.
  • Include review links or resource refs in the approval payload.
  • On approval, continue. On rejection, end or route to a revision step.

8) Apply changes and notify

  • Use an HTTP step to open a PR or apply changes in your target system.
  • Send notifications as needed. You can route messages after approval and after apply.

9) Run, inspect, and then release

  • Run the draft flow and inspect each step’s outputs.
  • Verify the approval handoff and final apply behavior.
  • When ready, release and promote to live. Draft remains your working copy for future changes.

Example architecture patterns to use

  • Remote-agent jobs on VMs
  • SSH into a VM to start a long-running agent.
  • Wait for a callback. Continue the workflow with the result.
  • Local-agent handoff
  • Trigger the flow and pause.
  • Let a local coding agent complete work.
  • Resume the flow when done.
  • Human-in-the-loop review
  • Persist artifacts and logs as resources.
  • Provide clear refs in the approval step.
  • Capture the decision in run history.

These are all supported and common in Breyta’s intended usage.

What makes Breyta reliable for approvals

  • Deterministic execution with step-by-step run history
  • First-class approvals and waits that preserve state over time
  • Versioned flow definitions with a draft-to-live split
  • Immutable releases and controlled rollout
  • A CLI that returns stable JSON so coding agents can operate flows safely

For a concise overview of when to pick Breyta for approval-heavy work, see the comparison that notes this fit in Breyta vs n8n.

Example use cases

  • Review-and-apply code changes with a PR gate
  • Content operators that draft, request approval, then publish
  • Support or billing updates that require a human checkpoint
  • Autonomous fixes that only apply after an explicit approval

These match the platform’s supported patterns for multi-step, approval-heavy workflows and agent orchestration.

Tips for smooth rollout

  • Keep approvals close to the action. Review the actual artifacts via resource refs.
  • Split risky actions into pre-approval and post-approval blocks.
  • Use explicit concurrency policies for flows that touch shared state.
  • Keep your flow slug stable and use releases for changes.
  • Test in draft until both the human loop and the apply step are predictable.

FAQ

Can Breyta handle long-running approval workflows?

Yes. Use wait steps and approvals. Breyta keeps workflow state while remote agents or humans are working. The flow resumes from the next step when the callback or approval arrives.

Do triggers, waits, and approval steps count toward billing?

Triggers, waits, and approval steps do not count as billable step executions under current product copy.

How do I get started quickly?

Follow the default lifecycle in the Start Here guide: create or pull a flow, push draft changes, configure connections, run and inspect, then release to live.