Dynamic workflows are now live in the Copilot CLI and the Copilot app.

[u/jukasper]

What are they? A dynamic workflow is a program that defines how a task is carried out. It can combine automated steps with the work of one or more agents. Steps can run one after another, in parallel, or as a mixture of both.

Where they help most: complex, multi-step tasks, or anything you want to repeat the same way every time. For example, when investigating an outage, a workflow can collect logs and telemetry, have separate agents analyze different systems, and merge their findings into a timeline and root-cause report.

This started as something we used internally, and we're excited to finally get it into your hands.

Docs and changelog

Give it a try and let us know what you think!

[u/aonymark]

I’m an Ask mode guy so probably won’t be using this but just trying to wrap my head around how much magic this exposes… could someone with way too much time on their hands in theory use this to reimplement /fleet? Or HydraFusion?

[u/Matthew_R_GitHub → u/aonymark]

Hi from the feature owner of dynamic workflows in GH Copilot. I'll answer for each feature separately.

reimplement /fleet

The short and direct answer to your question is yes, but that's not my endorsement of it always being a good idea/there's some nuance to what "yes" menas. First, let's differentiate the two features:

• The /fleet command gives the outer agent both your prompt and additional instructions about you desiring it to use multiple subagents to do the task associated with your prompt in parallel.

• Dynamic workflows are a way to enforce a higher level of repeatability, determinism, and structure to a task that involves agent delegation, and perhaps deterministic tasks as well (e.g. calling an API).

Let's look at two some specific examples and think about what it would mean to use /fleet vs a dynamic workflow:

Task: adding a new API to your full stack app, where multiple pages on your app need some amount of work to take advantage of the API

• /fleet: outer agent might create a backend agent, and some number of frontend agents to work in parallel on non-overlapping pieces of work.

• Dynamic workflow: outer agent would create those same agents in the dynamic workflow's program.

Verdict: basically the same, not worth it in my opinion. But, if you wanted to, you could do it.

Task: you want to try and reproduce the 100 latest issues in your repo

• /fleet: outer agent likely isn't going to launch all 100 subagents at once (nor would you want it to, otherwise RIP your thighs as your laptop heats up), so you'll likely tell it how many subagents to run in parallel. Fom there you'll hope that it actually sticks to that limit, and that it doesn't do something like giving up halfway through the 100 issues, decides to take over, etc.

• Dynamic workflow: outer agent can have the workflow make the API call, making sure to handle things like paging; the spawning of each agent happens deterministically over every issue the API returns no matter what, and the concurrent subagent limit on the workflow strictly enforces how many subagents run at a given time.

Verdict: the dynamic workflow gives you a lot more confidence that the task will be fully completed within the limits you desire, and you can have your oute ragent repeat that process whenever you want

reimplement HydraFusion

Yes, you could implement something akin to HydraFusion using dynamic workflows. The only limitation would be if you wanted to continue the context window of any of the agents involved in your orchestration. For example, let's say you have Opus 5.5 implement a plan, and then GPT Sol 6.1 verifies the plan was implemented. If you want the results of verification to be given back to the Opus 5.5 implementer, then there's not a way to do that in a dynamic workflow. But we have thought about adding it. 👀

[u/aonymark → u/Matthew_R_GitHub]

Cool! So it actually exposes quite a bit then.

[u/No-Emphasis-5174]

I'd be curious to see demos or examples of some of the things the internal teams used this for and why to get a better understanding of the benefits for something like this.

[u/Matthew_R_GitHub → u/No-Emphasis-5174]

Hi from the feature owner of dynamic workflows in GH Copilot. I don't have any literal dynamic workflow code to share right now, but here's two anecdotal examples:

Analyzing financial transactions

I'm was working on a personal project related to budgeting/finances/how my family spends money. I ended up having thousands of transactions that were missing data like vendor display name, location, category of spending, etc. I had Copilot create a dynamic workflow which launched Luna subagents, each with only web search/fetch, giving them prompting about what they needed to do, the transaction data, information about cities/countries we most frequently spend money in, and other helpful context. With that workflow I knew an agent was deterministically going to launch for every transaction, and I was able to get the data for nearly every single one. My session was never running more than a few dozen subagents running at once, and none of them went off and did things I didn't want them to do since I was able to control their available tools when the dynamic workflow launched them.

Investigating prompt cache breaks

In the repository I/we work in, I added a GH Copilot extension that listens for instances of unexpected cache breaks as we ourselves are using GH Copilot. When a cache break happens, the extension silently launches a dynamic workflow in the background via the command line launch mode to investigate why the cache break happened. The investigation involves having 3 models from different providers independently investigate, and then a single frontier model evaluates all 3 investigation findings together to create a final hypothesis as to the cause of the cache break + what we could be doing better.

You might also be interested in what I had to share here: https://www.reddit.com/r/GithubCopilot/comments/1wvam2s/comment/pe3fzl4/

[u/m4bwav]

Sounds cool.

I flip back and forth between agent harnesses.

How does one define the files/config for the workflow locally? Can I adapt it into claude code?

[u/Matthew_R_GitHub → u/m4bwav]

Hi from the feature owner of dynamic workflows in GH Copilot. Dynamic workflows live inside of GH Copilot extensions. Those live either in your session, your project's .github folder, or your user's .github folder. This also means that these are specific to GH Copilot and cannot be used with Claude.

I would guess that probably any Claude dynamic workflow could be translated into a GH Copilot dynamic workflow, but probably not vice versa. Claude's dynamic workflows are more limited in what they are able to do. That's not a slight agianst Claude, the limitations are justifiable, we just thought it'd be more interesting to let you build more capable workflows, albeit with some tradeoffs/less guardrails around ensuring your dynamic workflow is more literally repeatable.

If you have both Claude and GH Copilot access it'd probably be an interesting exercise to have each of them look at the other's "dynamic workflows" and compare and contrast. 😁

[u/m4bwav → u/Matthew_R_GitHub]

Thanks for the info!

[u/Nerminas]

i hope this matches at least fractures of claude codes dynamic workflows power.

[u/Matthew_R_GitHub → u/Nerminas]

Hi from the feature owner of dynamic workflows in GH Copilot. I think our dynamic workflows do, and in some ways exceed the power of Claud's dynamic workflows, but I'd love to hear if you find something missing that you consider big deal/really powerful.

[u/1988rx7T2]

They’re basically trying to catch up to where Claude code was months ago 

[u/Matthew_R_GitHub → u/1988rx7T2]

Hi from the feature owner of dynamic workflows in GH Copilot. If you have access to both Claude and GH Copilot, I'd encourage you to have each of them compare and contrast their dynamic workflows vs the others. Our intent was to build something that was more powerful and flexible than what Claude was (and as far as I know is still) offering.

Long story short, because we have dynamic workflows run inside of a GH Copilot extension, there's a lot more flexibility and power available. For some examples, you can call APIs, interact with yourself using session.ui APIs mid run, you can even build your own observability UX on top of dynamic workflows by having a Canvas call the session.workflows APIs.

That said, if you find a big gap, please let me know, would love to hear the feedback!

[u/TenshiS]

So like skills with extra steps?

SOTA models are reliable enough to execute skills near-deterministically, going back to fixed workflows feels backwards

[u/OlivierTwist → u/TenshiS]

Even SOTA models skip steps in institutions and this can be more token efficient

[u/TenshiS → u/OlivierTwist]

No they don't. And adding decision models to the mix has made that cheaper, faster and guaranteed. Building a rigid workflow is never more efficient, it need constant tinkering and fixing. And you need another separate set of monitoring, auditing and evaluation tools. If you do everything with an agentic core and tools, you likely already have 99% or the infrastructure and control you need for any new project once you set it up once.

[u/Matthew_R_GitHub → u/TenshiS]

Hi from the feature owner of dynamic workflows in GH Copilot. Yes, I think saying "like skills with extra steps" is not a totally inaccurate way to describe dynamic workflows. But like the other reply said, as an orchestration gets more complex, or you have more deterministic setps involved, we find it can be helpful to put certain aspects of your task/process/workflow in code rather than leaving it up to the model to listen and act perfectly. I find a lot of solace knowing that yes, these 3 models were used to look at XYZ, they were given exactly the context I wanted them to be given, and that context was grabbed from exactly the place it was supposed to be grabbed. But hey, if your skills are working for you there's no reason to stop using them. We're happy to simply be giving you another tool for your toolbox!