GitHub launched dynamic workflows in public preview on October 1, 2026, across Copilot CLI, the GitHub Copilot app, and the GitHub Copilot SDK. The feature lets developers define a process in code, combining automated operations with agents that handle analysis and judgment. Its central purpose is to make the stages, handoffs, and review points of a complex task explicit and reusable. GitHub’s announcement describes workflows that can run sequentially, in parallel, or through a mixture of both.
That matters when a task needs to follow a particular procedure each time. Developers can specify which work happens first, which tasks can proceed independently, how results move between stages, and where a person should review progress. The process is defined in code; agents still supply the judgment within it.
How dynamic workflows work
A dynamic workflow is a program inside a Copilot extension, with access to Copilot’s extensibility APIs. According to GitHub, it can run commands, use tools, call services, divide a goal into tasks, and pass structured results between stages. It can also have subagents check one another’s findings. These capabilities connect ordinary automation with agent work inside a defined process. GitHub announcement
GitHub illustrates the approach with a service-incident investigation: a workflow could collect logs and telemetry, assign separate agents to analyze different systems, and combine their findings into a timeline and root-cause report. This is an example of a possible workflow, rather than evidence of a deployed incident-response system or measured improvement.
The useful distinction is between repeating a procedure and reproducing a conclusion. Code can preserve the investigation’s stages and required handoffs. That does not, by itself, establish that an agent’s interpretation is correct. Subagent cross-checks and human review create places to examine findings; the announcement does not establish an accuracy guarantee for those findings.
How workflows differ from Autopilot and /fleet
Dynamic workflows overlap with other Copilot features in their use of agents, but they address a different question: how the process is specified. GitHub’s documentation describes Autopilot as a mode that lets Copilot continue working without requesting input after each step. The /fleet command encourages delegation to subagents and parallel coordination. Dynamic workflows execute a process defined in code. GitHub concepts documentation
| Feature | Documented role |
|---|---|
| Autopilot | Keep Copilot working through a task without asking for input after every step. |
| <code>/fleet</code> | Encourage Copilot to delegate work to subagents and coordinate them in parallel. |
| Dynamic workflows | Define the task’s process in code, including automated steps and agent work. |
Parallel execution alone is therefore not the defining capability. The stronger reason to use a workflow is that the order of operations, treatment of results, or required checks need to be explicit. GitHub says ordinary chat is usually sufficient for a quick answer or simple change. Its suggested workflow candidates include recurring processes and individual tasks that need clear stages, checks, or limits. GitHub announcement
Review points and practical uses
GitHub lists release checks as one candidate: run checks, ask an agent to assess failures, and pause so a person can review the findings before continuing. Other examples include reviewing changed pull-request files in parallel, searching a large codebase for a pattern, and moving from research to planning and implementation.
A more specific example uses code to locate unresolved review comments on merged pull requests, then asks two models whether those comments still matter. The workflow reports findings only when both models agree. This illustrates a rule encoded around agent output. Agreement determines what the workflow reports; it should not be read as independent proof that a reported finding is correct. GitHub announcement
Two interaction mechanisms also deserve distinction. A workflow can request user input if the client or application supports it. Separately, it can pause at a checkpoint for result review and resume when the user is ready. Developers should preserve the client-support qualification when designing a process that depends on asking questions. GitHub concepts documentation
Availability includes a billing exception
The October 1 announcement says dynamic workflows are available on all Copilot plans. However, the supplied GitHub concepts documentation gives a narrower eligibility statement: it excludes Copilot Pro and Copilot Pro+ subscribers on existing annual plans who remain on legacy premium request-based billing. The announcement’s broad wording and the documentation’s exception differ; the evidence does not explain the reason for that difference.
For setup, GitHub says dynamic workflows are always available in the Copilot app with no setup required. In the latest Copilot CLI, users must enable experimental features through the --experimental command-line option or /experimental on in an interactive session. The announcement also gives /update as the command for updating Copilot CLI. The feature remains in public preview and is subject to change. GitHub announcement
Developers can write the extension themselves or ask Copilot to author a workflow using its built-in guidance. The documentation also describes workflows shared by others becoming available once their extension is loaded. These are different routes to obtaining a workflow, with the extension remaining the unit that contains its definition. GitHub concepts documentation
Running an existing workflow from the terminal
GitHub’s how-to documentation supplies this command form:
copilot workflow run WORKFLOW-NAME [OPTIONS]
It runs an existing dynamic workflow. The documented options distinguish inputs, returned values, and run information:
| Option | Documented behavior |
|---|---|
| <code>–args</code> | Supply workflow inputs as JSON. |
| <code>–result-file</code> | Write the workflow’s returned value to a JSON file instead of printing it in the terminal. |
| <code>–silent</code> | Suppress progress output. |
| <code>–output-format json</code> | Receive a JSON record containing the workflow name, run ID, status, and any returned result. |
The distinction between a returned value and a run record matters for applications consuming the output: the result file holds the workflow’s returned value, while JSON output includes run information as well. These interfaces provide a documented route for consuming workflow results programmatically. GitHub how-to documentation
Permissions need separate attention in terminal automation. QATechTools, reporting GitHub’s permission behavior, says subagents inherit the grants of the session that started them. It also reports that non-interactive copilot workflow run does not display approval prompts: permissions must be granted beforehand, and requests that cannot be approved automatically are denied. Those details are attributed to secondary reporting in the supplied evidence. QATechTools
For developers evaluating the preview, the concrete capability is control over a reusable process: which steps execute, where agents contribute, how their results are passed onward, and when review occurs. The quality of the agents’ conclusions remains a separate question from whether the workflow follows its defined stages.
