Skip to content

CONCEPT Cited by 1 source

Async agent workflow

Definition

Async agent workflow is a development-iteration shape where agents pick work from a queue (issues, tickets, tasks) and surface results as asynchronous artifacts (PRs, draft documents, deploy previews) — without a human in every loop of the inner cycle. The human sets boundaries (what to work on, approval gates); the agent works on its own schedule, including across the human's offline time.

Canonical wiki statement

Fly.io, 2025-06-20, on Phoenix.new:

We're at a massive step-change in developer workflows.

Agents can do real work, today, with or without a human present. Buckle up: the future of development, at least in the common case, probably looks less like cracking open a shell and finding a file to edit, and more like popping into a CI environment with agents working away around the clock.

Local development isn't going away. But there's going to be a shift in where the majority of our iterations take place. I'm already using Phoenix.new to triage phoenix-core Github issues and pick problems to solve. I close my laptop, grab a cup of coffee, and wait for a PR to arrive — Phoenix.new knows how PRs work, too.

(Source: sources/2025-06-20-flyio-phoenixnew-remote-ai-runtime-for-phoenix)

The load-bearing framing is "the future of development … looks less like cracking open a shell and finding a file to edit, and more like popping into a CI environment with agents working away around the clock."

How it relates to Robot Experience

This concept is the coding-agent specialisation of the 2025-04-08 Robot Experience (RX) thesis ("our best customers are now robots"): platforms should be designed assuming the primary tenant is an agent, not a human at a terminal. Async agent workflow is what that looks like for coding agents specifically — human shapes the agent's boundaries (what repo, what issue filters, what approval gates), agent iterates autonomously.

Preconditions

  • An ephemeral environment the agent owns. Without a cloud IDE the agent operates in, there's no natural substrate for autonomous iteration — laptop-based agents require the human to be at the laptop. Phoenix.new's per-session Fly Machine is the substrate that makes this workflow executable.
  • A structured work queue. Issues / tickets / TODO list — something the agent can read, pick, and associate output with. gh gives the GitHub-issue-tracker version of this for free.
  • A result artifact shape the human reviews async. Pull requests are the natural shape: the agent opens a PR, the human reviews it when convenient, the PR becomes the human-in-the-loop gate.
  • Approval gating. Depending on risk, the human may want to approve individual changes (low-risk edits → auto-merge; higher-risk → review required; highest-risk → never auto-apply). See concepts/ai-agent-guardrails.

What it's not

  • Not no-human-in-the-loop. The human is still the arbiter of what gets merged, what repos the agent can touch, what the boundaries of authority are. The asynchrony is in the inner iteration cycle, not the outer approval cycle.
  • Not fully-autonomous code generation. The agent isn't designing features or prioritising roadmap — it's executing on human-chosen tasks.
  • Not a replacement for interactive dev. The post says explicitly: "Local development isn't going away." The claim is about where the majority of iterations take place, not that interactive dev disappears.

Contrast with adjacent shapes

  • Classic CI. CI runs triggered builds on pushes; CI doesn't pick work. Async agent workflow is agentic CI — the agent fetches work rather than being fed it.
  • Background Copilot / Cursor agents. These run with a human in the loop (the editor) but asynchronously within a session. Async agent workflow goes one step further: the human isn't in the session at all.
  • Devin-style autonomous engineer. Same async workflow shape; different product packaging and different target scope.

Caveats

  • The post's evidence is n=1 (McCord triaging phoenix-core issues). No aggregate PR-merge rate, regression-rate, or time-to-first-useful-PR.
  • The "agents working around the clock" framing is forward-looking; most 2025 deployments of async agent workflows are still human-supervised with tight review loops.
  • Approval / guardrail posture is unsolved at the architecture level — every product handles which PRs the agent can auto-merge differently.
  • Cost scales with wall-clock time, not work completed. An agent that loops unproductively for 8 hours bills 8 hours.
  • Trust-boundary question: an async agent that can open PRs can also edit CI config, modify sensitive files, alter permission settings. Guardrails at the repo level (branch protection, CODEOWNERS) are load-bearing.

Seen in

Last updated · 200 distilled / 1,178 read