# The Four Primitives of Coding Agent Workflows: Triggers, Steps, Waits, and Approvals

## Quick answer

Coding agent workflows use four primitives to run work end to end: Triggers start the run; Steps perform actions; Waits pause the flow until an event or callback arrives; Approvals create human checkpoints before the flow continues.

## What this means in practice

- ### Triggers
  - Start runs from a manual button, a schedule, or an external event.
  - Common sources: cron, webhooks, repo events, app actions.
  - Example across the ecosystem: in GitHub Agentic Workflows, a pull_request event can expose both branches to the agent for work ([triggers reference](https://github.github.io/gh-aw/reference/triggers/)).
- ### Steps
  - The units of work your agent or system performs.
  - Typical actions: call APIs, query data, run a model, send a notification, SSH into a VM, sleep, or run a function.
  - Steps can branch, loop, or call reusable functions.
- ### Waits
  - Pause the workflow while keeping state intact.
  - Resume on a callback, a timer, or a signal from another system.
  - Useful for long jobs, human reviews, or external processing.
- ### Approvals
  - Require a human decision before moving on.
  - Gate risky operations like publishing, changing code, or billing updates.
  - Keep auditability and control in production. For a deeper overview of approval design, see this guide on workflow approvals in production systems ([Breyta blog](/content/blog/workflow-approvals-production-systems/index.html)).

## Why it matters for production workflows

- ### Reliability
  - Deterministic execution and clear run history reduce flakiness.
  - Explicit waits and approvals prevent unsafe changes.
- ### Long-running work
  - Many agent tasks exceed serverless limits.
  - Waits let the flow hand off work and resume later without holding a connection open.
- ### State and inspectability
  - You need to see every step, payload, and output.
  - You also need to persist large artifacts without bloating state.
- ### Control and rollout
  - Versioning and approvals protect live systems.
  - Draft vs live keeps iteration safe.
- ### Fit for coding agents
  - Agents need a scriptable interface.
  - The workflow layer should be stable, parseable, and friendly to CLI-driven automation. Some platforms in this space highlight real-time observability and [human-in-the-loop pauses for agents](/content/blog/human-in-the-loop-ai-agent-workflows/index.html) ([example overview](https://www.mindstudio.ai/blog/what-is-trigger-dev-agentic-workflow-platform/)).

## What teams should look for

- ### Triggers
  - Manual, schedule, and webhook support.
  - Event-driven resumes for long jobs.
- ### Steps and orchestration
  - Deterministic behavior and retries.
  - Rich step families for HTTP, data, model calls, SSH, and notifications.
- ### Waits and approvals
  - First-class primitives for pauses and human gates.
  - Clear notification and callback paths.
- ### State and artifacts
  - Resource references for large outputs.
  - Signed access to media or files when needed.
- ### Observability
  - Full run history with step outputs.
  - Inspectable drafts and live runs.
- ### Versioning and rollout
  - Draft vs live targets.
  - Immutable releases and approvals before promotion.
- ### Security and credentials
  - Connection management separate from logic.
  - Users connect accounts once. Secrets remain secure.
- ### Agent-first operation
  - Stable CLI output for agents to parse.
  - Scriptable flows, runs, and resources.

## How Breyta fits

Breyta is a workflow and agent orchestration platform for coding agents. It helps teams build, run, and publish reliable workflows, agent runs, and autonomous jobs with a strong focus on runtime control.

- ### Flows and lifecycle
  - A Breyta flow is a versioned EDN definition with a stable slug, triggers, deterministic orchestration in `:flow`, optional `:functions` and `:templates`, optional `:requires`, and an explicit concurrency policy.
  - Canonical lifecycle:
    - Pull or create the flow.
    - Push draft changes.
    - Configure bindings and connections.
    - Run and inspect draft behavior.
    - Release and promote to live when approved.
  - Draft is for fast iteration. Live is the stable runtime. Pushing changes updates draft only.
- ### Triggers and steps
  - Trigger types: manual, schedule, webhook/event.
  - Documented step families include:
    - `:http`, `:llm`, `:search`, `:db`
    - `:wait`, `:function`, `:notify`, `:kv`
    - `:sleep`, `:ssh`
  - This is not only AI flows. Breyta coordinates real backend work and agent-in-the-loop tasks.
- ### Waits, approvals, and human checkpoints
  - Wait steps, approvals, external callbacks, and notifications are first-class.
  - Flows can pause for human confirmation or external systems, then resume with state intact.
  - This enables safe review-and-apply patterns in production.
- ### Long-running agent patterns
  - **Remote-agent pattern**:
    - Kick off remote work over SSH.
    - Pause with a `:wait` step.
    - Resume when the remote worker posts to a callback URL.
  - **Local-agent pattern**:
    - Trigger a flow.
    - Use `:wait` while a local runner does the work.
    - Resume when the local run completes.
  - These patterns keep long jobs reliable without one fragile long-lived connection.
- ### Resources and large outputs
  - Use `:persist` when output size is uncertain.
  - Return compact `res://...` references.
  - Inspect artifacts with CLI resource commands.
  - Large outputs stay inspectable without bloating workflow state.
- ### CLI and agent-first operation
  - The Breyta CLI is a primary interface.
  - Commands return stable JSON and are designed for coding agents to parse.
  - `breyta init` and `breyta skills install` help agents learn and operate flows.
- ### Versioning, rollout, and control
  - Versioned flows, active releases, and a draft vs live split.
  - Immutable releases. Runs are pinned to a resolved release at start time.
  - Safer than ad hoc scripts and unreviewed agent changes.
- ### Supported use cases
  - Local coding-agent execution.
  - Agent-driven workflows on VMs over SSH.
  - Autonomous code improvement with human approval.
  - Content operators that generate drafts and wait for approval.
  - Internal tools, support automation, billing sync, transcription.
  - Example workspace flows:
    - `local-codex-agent-mvp`. Run a Codex CLI locally with waits.
    - `autonomous-code-improvement-agent-codex-cli-vm`. Kick off a detached VM worker, wait for callback, return a PR payload.
    - `content-operator-vm`. Draft social content on a VM, persist memory, request approval, dispatch approved posts.
- ### Packaging and reuse
  - Reusable templates and published apps.
  - Installable targets for stable live behavior.
- ### Costs and counting
  - Pricing is based on monthly step executions.
  - Triggers, waits, and approvals do not count as billable step executions.
  - Plans include unlimited users, workflows, steps per flow, and concurrent executions. Run history retention varies by plan.

## Putting it together

- Triggers start the workflow at the right moment.
- Steps do the work across APIs, models, data, and infrastructure.
- Waits keep state while long tasks run elsewhere.
- Approvals make changes safe and reviewable.

Breyta brings these parts together with deterministic runs, strong versioning, and an agent-first CLI. It is built to turn agent ideas into production workflows that you can run, inspect, pause, approve, and release with confidence.

### FAQ
- #### What is the difference between a wait and an approval?
  - A wait pauses until an external signal or time. An approval pauses until a human decision. Both keep state intact.
- #### How do long-running agent jobs avoid timeouts in Breyta?
  - Use the remote-agent pattern. Start work over SSH, pause with `:wait`, then resume on a callback. The flow holds state while the agent does the heavy work.
- #### Do waits and approvals count as billable steps in Breyta?
  - No. Triggers, waits, and approval steps do not count as billable step executions.