Copilot dynamic workflows put agent orchestration into code

A program decides the process around the agent

GitHub introduced dynamic workflows in Copilot CLI, the Copilot app and the Copilot SDK on October 1. The public-preview feature defines orchestration in code within a Copilot extension. It supports sequential and parallel stages, commands, external services, structured outputs and checkpoints. The CLI requires experimental features to be enabled, while the app exposes the capability without that setup. GitHub distinguishes it from ordinary agent delegation, where a model coordinates the process dynamically.

The difference is useful for recurring work. A release review might always collect the same evidence before asking an agent to assess a failure. Encoding those stages gives the team a process it can inspect, revise and repeat. The agent still contributes judgment, but it does not have to invent the entire operational sequence each time the task runs.

Source: GitHub official changelog

Analysis: Explicit stages expose assumptions

A workflow program makes dependencies visible. It can show that an analysis stage should not begin until logs have been collected, or that publication should wait for a verified build. Those rules are easier to review than a long prompt with several loosely ordered requests. However, code can also preserve a bad assumption very efficiently. If the program treats a command’s exit status as proof of a deployed result, every run can repeat the same unsupported conclusion.

Structured handoffs need validation as well. An agent’s returned object should have an expected shape, but a valid shape does not guarantee accurate content. Check references to files, test results and external records against actual evidence. Keep the source material available to reviewers and let uncertain findings remain uncertain. Two agents agreeing on a conclusion can still share the same incomplete input; agreement is not an independent verification mechanism on its own.

Design checkpoints around meaningful decisions

A good checkpoint presents a concrete result that a person can assess: a patch, a release artifact or a documented incident timeline. Asking for approval before the work exists slows the process without improving review quality. Conversely, allowing a workflow to publish before the intended evidence is ready makes the checkpoint ineffective. Define the state required at each consequential transition and include a recovery path for an incomplete stage.

Track run identifiers and completed external operations so retrying a workflow does not repeat a release or create duplicate records. Set time and spending limits on parallel work, and capture enough execution detail to explain why a stage stopped. Dynamic workflows are promising where teams already know the process they want to repeat. Their value comes from making that process testable and observable while keeping model judgment confined to the parts where judgment actually improves the result.