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

By Chris Moen • Published 2026-03-26

Explore the four fundamental primitives—triggers, steps, waits, and approvals—that power robust and reliable coding agent workflows, enabling deterministic execution and human oversight.

Breyta workflow automation

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).
  • ### 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).

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 (example overview).

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.