GitHub Copilot Dynamic Workflows: how to manage multiple AI agents

What exactly GitHub released

On October 1, 2026, GitHub announced Dynamic Workflows in Copilot CLI, the GitHub Copilot app, and the Copilot SDK. The feature is available on all Copilot plans but currently has public previewbeta status, so the interface and API may change.

A standard prompt describes the desired result. A Dynamic Workflow describes the process itself: which commands to execute, where to involve an agent, which parts to run in parallel, in what format to collect findings, and where to stop for human confirmation. The workflow definition lives inside a Copilot extension.

This is useful not for a one-off "fix this button," but for tasks with repeatable stages: release verification, reviewing many files, searching for deprecated APIs, incident investigation, or a "research → plan → implement → verify" route.

Standard Chat, Autopilot, Fleet, and Dynamic Workflow

The main difference is reproducibility. Agents may still produce different findings, but the route is not reinvented in every run. This is closer to a programmed pipeline with AI nodes than to a magical "swarm of agents."

How Dynamic Workflow is structured

1. Deterministic start. Code can receive a list of changed files, read configuration, or run an allowed command.
2. Task splitting. Large sets of files are broken down into independent groups that can be processed in parallel.
3. Agent work. Each agent receives a narrow task and returns the result in a specified format.
4. Verification. Another agent or standard code filters out duplicates, checks structure, and compares findings.
5. Checkpoint. A workflow can pause the process before changing code, publishing, or performing any other action.
6. Summary. Results are gathered into a single report that can be displayed in the app, written to a file, or used in a subsequent stage.

GitHub allows agents to return structured results; if the format is incorrect, Copilot can ask the agent to fix it. This makes subsequent stages less dependent on free text. A similar idea is used in Structured Outputs, but here the contract is part of a multi-stage process.

Practice: a workflow for reviewing changed files

Start not with extension code, but with a clear description. In the Copilot app, Dynamic Workflows are available without additional configuration. In Copilot CLI, first enable experimental features:

copilot --experimental

# Або всередині інтерактивної сесії:
/experimental on

Then ask Copilot to create a workflow. The prompt below intentionally limits the scope and does not allow agents to edit files automatically.

After creation, ask What dynamic workflows are available? and ensure that it is review-changed registered. Creating a workflow does not start it automatically.

How to run and repeat a workflow

In an interactive session, a natural command is enough:

Run the review-changed dynamic workflow on this repository
with an AI credit limit of 150.

Copilot runs the process in the background, so you can continue working in the app. For repeatable runs from the terminal, use a separate command:

copilot workflow run review-changed \
  --args '{"base":"main"}' \
  --allow-tool=read \
  --result-file review-results.json

Field names in --args depend on the inputs of the specific workflow. --result-file writes only the successfully returned result; progress and technical events are not mixed with JSON. If a run stops, crashes, or is interrupted, the existing result file is not overwritten.

To share a workflow with a team, its extension can be saved in .github/extensions/ the repository. For personal use across all projects — in ~/.copilot/extensions/. After an update, the team needs to pull the changes and reload extensions.

Agent, time, and AI credit limits

A Dynamic Workflow can launch many agents and quickly consume a noticeable amount of AI credits. GitHub provides four types of limits: concurrent sub-agents, total number of sub-agents, active time, and an approximate maximum number of AI credits.

Default personal values in Copilot CLI are set via /settings:

/settings workflows.defaultLimits.maxConcurrentSubagents 3
/settings workflows.defaultLimits.maxTotalSubagents 5
/settings workflows.defaultLimits.timeoutSeconds 1200
/settings workflows.defaultLimits.maxAiCredits 150

A prompt limit has higher priority than values in the workflow code and personal settings. An important nuance: AI credits are accounted for with a delay, so work already in progress might slightly exceed the specified limit. This is an approximate maximum, not a hard financial ceiling.

Permissions and security

Sub-agents use the Copilot CLI permission system and inherit the permissions of the session that launched them. In interactive work, a new access request appears as a standard confirmation. However, copilot workflow run does not show such requests: necessary permissions must be granted in advance via parameters such as --allow-tool or --allow-url, and unapproved actions will be rejected.

• Give minimal permissions. Reading is sufficient for review; do not add record, network, or shell without a specific need.
• Verify the extension as code. It can execute its own logic outside of agent queries. Do not load an unknown workflow just because of a convincing name.
• Do not pass secrets. Tokens, keys, and production configurations must not appear in prompts or results. Use our API key security guide.
• Pause before making changes. Deletion, publication, merge, deploy, and permission changes must have a separate checkpoint.
• Limit the context. A frontend agent does not need access to the entire infrastructure or private logs.

How to check if a workflow is actually useful

Run the same limited test twice: manually via standard Copilot Chat and via Dynamic Workflow. Compare the reproducibility of the process, not the beauty of the response.

In the CLI command /workflows shows active and recent runs, stage, time, number of sub-agents, and AI credits spent. A run can be paused or canceled. After a pause or a stop due to limits, it can be resumed using the saved results of completed steps; a canceled run cannot be resumed.

Common mistakes

1. Automating a one-off triviality. Creating and testing a workflow takes more time than a regular prompt.
2. Writing "check everything." Without limits, agents duplicate work, waste credits, and provide vague summaries.
3. Running ten agents at once. More parallelism does not guarantee a better result; start with two or three.
4. Allowing automatic edits. First, separate problem discovery from their fixing.
5. Trusting public preview as a stable API. Keep workflows in the repository, pin expected behavior, and check the changelog after a CLI update.
6. Running an untrusted extension. This is code with real permissions, not a passive text template.

Pre-team use checklist

• The task is repeatable and truly requires several stages.
• Deterministic commands are separated from agent work.
• Each agent has a narrow role and a structured output format.
• Maximum concurrent and total subagents are specified.
• Timeout and AI credit limits are set.
• Workflow has been tested on two to three files.
• Permissions are minimal and explicitly granted.
• Human confirmation is required before writing, merging, or deploying.
• The extension is saved in a controlled repository and reviewed as code.
• The result is verified by tests and a responsible human.

Frequently asked questions

Is a Dynamic Workflow just a Fleet with a template?

No. A Fleet lets Copilot decide how to divide the task among agents on its own. A Dynamic Workflow executes a code-defined process with specific stages, conditions, boundaries, and result handovers.

Can a workflow be run in CI?

Yes, GitHub documents programmatic execution via CLI. However, you must first set up authentication, explicitly allow the necessary tools and URLs, and use only trusted extensions.

Is this feature available on the free Copilot plan?

GitHub states that Dynamic Workflows are available on all Copilot plans. However, actual AI credits and available models depend on the plan, and the feature itself is currently in public preview.

Does this replace GitHub Actions?

No. Actions is better suited for fully deterministic checks and builds. Dynamic Workflow is appropriate where analysis, agent judgment, cross-referencing findings, or a human checkpoint is needed between commands.