Copilot dynamic workflows: fan out Sume jobs, wait once

A Copilot dynamic workflow can fan out several Sume generations in parallel, but it should not wait on them one by one: submit each paid create with its own idempotency_key, then settle the whole wave with a single jobs_wait that takes up to 20 job_ids. That keeps every wait under Sume's 55-second slice and avoids N separate polls.

GitHub announced dynamic workflows on 1 October 2026 in Dynamic workflows in Copilot CLI and the Copilot app (read 2026-10-02). It is a public preview and "subject to change". The Sume side below comes from Jobs and results and MCP tools and gates.

What did GitHub actually ship?

The changelog describes a dynamic workflow as a program that defines how a task is carried out. It mixes automated steps with the work of one or more agents, and steps can run one after another, in parallel, or both. Workflows can run commands, use tools or call other services, pass structured results between stages, ask you for input and pause at a checkpoint.

It is available in Copilot CLI, the GitHub Copilot app and the Copilot SDK. In the app it needs no setup. In the CLI you start it with the --experimental flag or /experimental on. The page does not mention MCP at all, so this post does not claim a workflow step can call an MCP tool. What it does say is that steps can use tools and call other services, and Sume is reachable both ways: as a remote MCP server in a client that has it configured (see Copilot CLI MCP server) and over the REST API.

Which Sume calls belong in a parallel step?

Parallel steps suit independent work of the same shape: one image per scene, one voiceover per line. Sume's docs say the same about its own programmatic calling: when a turn needs three or more independent calls of the same shape, batch them rather than looping serially.

Two rules from the docs matter more once steps run concurrently. First, every write or paid tool needs an idempotency_key, and it is transport dedup, not human approval. If a step is retried, reuse the exact key so you do not create a second job. Second, a reused key with a different payload returns 409 idempotency_conflict, so derive keys from the scene, not from a timestamp.

• Give each parallel branch its own stable key, such as the workflow run label plus the scene number.
• Run the first branch with dry_run: true and read the estimate before the fan-out; spend is wallet admission, and max_spend_usd is enforced only when you pass it.
• Never share one key across branches that have different prompts.

How do I settle the whole wave with one wait?

After the branches have submitted, collect the job ids and make one batch wait. jobs_wait accepts job_ids (1 to 20) with wait_for set to all or any. Pass include_results: true and each completed id comes back with its result, so the wave needs no separate read. Anything that does not fit is listed in results_omitted.job_ids; read those with a batch jobs_result.

{
  "job_ids": ["job_a", "job_b", "job_c"],
  "wait_for": "all",
  "include_results": true,
  "timeout_seconds": 50
}

What happens when the wait slice runs out?

Each remote MCP call holds at most 55 seconds (default 50). A longer timeout_seconds is clamped, and the response says so in wait_slice_clamped. When a slice ends with jobs still running you get wait_slice_expired; the right move is to call jobs_wait again on the same ids. A checkpoint step in a workflow is a natural place for that loop: pause, re-issue the wait, resume.

Never resubmit the paid create because a wait timed out. The jobs keep running and keep billing, and a resubmit with a new key would pay twice. A 524, 522, 523 or 525 on the wait is a transport failure, not a job outcome.

What does Sume not do here?

Sume's docs describe MCP waiting as bounded slices the client repeats, not a push into the workflow. If your workflow runs somewhere with a public URL, webhooks are the push option. Sume Image 1.0 and Video 1.0 are REST-only and are not on hosted MCP, per the MCP overview. Because dynamic workflows are in preview, check the GitHub page again before you build anything you cannot change.