Skip to content

GitHub ships code-defined dynamic workflows for Copilot CLI, app, and SDK

· by Pondero Newsdesk

The short version

GitHub's October 1 changelog introduced dynamic workflows, a way to codify a reusable multi-agent process with parallel steps, checkpoints, and pause-and-resume review across Copilot CLI, the Copilot app, and the Copilot SDK.

GitHub ships code-defined dynamic workflows for Copilot CLI, app, and SDK

GitHub's October 1 changelog introduced a way to write down a multi-agent process once and have Copilot run the exact same steps every time, instead of re-prompting an agent from scratch on each run, per GitHub's changelog.

What shipped

The capability landed in public preview across three surfaces at once: Copilot CLI, the Copilot app, and the Copilot SDK, per GitHub's changelog. A dynamic workflow is a program, written in code, that mixes automated steps with agent judgment calls; the code decides when steps run in sequence, when they run in parallel, and how results from one stage feed the next. GitHub's own example is incident triage: a workflow pulls logs and telemetry, hands separate agents to analyze different systems at once, then merges their structured output into a timeline and root-cause report, running that same sequence on every incident rather than a fresh ad hoc investigation each time.

The workflow program lives inside a Copilot extension, so it gets the same extensibility APIs extensions already have. GitHub drew an explicit line against its existing /fleet command: /fleet has Copilot itself decide how to split and coordinate subagents on the fly, while a dynamic workflow runs a process a developer (or Copilot, prompted to write one) fixed in code ahead of time, per the changelog. Workflows can call tools and other services, split a goal into parallel tasks, pass structured results between stages, have one subagent verify another's findings, prompt a human for input, and pause at a checkpoint until a person resumes it.

A fixed, auditable process beats a fresh agent run every time

The practical gap this closes is repeatability. A chat prompt or a /fleet run improvises its plan each time, which is fine for one-off questions but hard to trust for a process that has to behave the same way on the tenth run as the first. GitHub's own suggested uses lean into that: sweeping a large codebase for a missing-test pattern across every directory, running release checks and pausing for a human to review failures before continuing, or checking unresolved PR review comments by asking two separate models and only flagging the comment when both agree. Each of those is a repeatable procedure with a built-in review gate, not a single improvised chat turn, which matters most for teams that need an audit trail or a stop-and-check point before an agent's output ships.

What to watch next

GitHub shipped this in public preview and flagged it as subject to change, so the authoring workflow, the checkpoint UI, and the SDK surface could all shift before general availability. It landed the same week as a separate Copilot code-review update, and GitHub has not said whether the two will converge into one review pipeline. Whether a dynamic workflow can wrap the code-review API directly is the next thing to confirm once GitHub publishes more usage examples.

Sources