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

  • 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

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.