Skip to main content
For a job too big for one pass, your coworker plans the work, then runs a team of temporary helpers side by side.

A narrated tour, so turn your sound on. Ivy, a support coworker, groups 200 tickets by theme with a team of helpers, then keeps the run to use again.

What it does

Some jobs aren’t hard, they’re just big. Two hundred support tickets to group by theme. Twenty companies to research before Thursday. A year of meeting notes to boil down. Your coworker starts by writing a plan: the phases the job breaks into. Then it hands the work to temporary helpers. Each one takes a slice, works on it alone, and reports back. Your coworker pulls their reports into one answer, and the helpers are gone when the job is done. These run-only helpers aren’t your coworker’s custom helpers, the named specialists you set up yourself. A run can put those to work too.

When you’d use it

  • “Go through all 200 support tickets and group them by theme.”
  • “Research the 20 companies on our shortlist and fill in the same profile for each.”
  • “Summarise a year of meeting notes, month by month, into one page of decisions.”
  • “Score these 12 supplier quotes against our spec, and have each score double-checked.”
  • “Keep searching review sites for complaints about our app until a round turns up nothing new.”
The common thread: the same kind of work, many times over, where one pass would take all afternoon.

Turning it on

Open your coworker, choose Capabilities, and find Dynamic workflows under Collaboration. Turn it on. The row describes a team of temporary helpers for large jobs, working side by side, in stages, or checking each other. It also says the capability is powerful on big jobs, and costly.
It needs Code and files. Switch Dynamic workflows on without it and nothing happens. The row tells you so directly:
Needs “Code and files” turned on above to do anything.
The Dynamic workflows row switched on, with an orange line underneath saying Code and files must be turned on too

The warning sits on the row itself, so the switch never reads as on while nothing happens.

It starts off, and only you can turn it on. No coworker can switch it on for itself or for another coworker. A run puts a whole team to work, so it costs more than an ordinary task. Turn it on for coworkers that handle big jobs, and leave it off elsewhere.

What it looks like

Each run gets its own card in the conversation. Here’s the one from Ivy, a support coworker, partway through grouping 200 tickets by theme.
The ticket-themes run card: Read finished, Check rows showing their latest steps, a stop icon on a working row, a note reading 9 themes in 8 of 8 batches, and a line confirming Slack was approved for this run

Ivy's ticket-themes run partway through. All eight Read helpers are done, and the Check helpers are working through the themes.

1

The plan comes first

Before any helper starts, the card lists the phases the job breaks into, each marked pending. Ivy’s are Read, Check and Report. If that isn’t what you meant, stop the task and say what you want instead.
2

Helpers fill in live

A row appears as each helper starts, showing its latest three steps. A link like +2 earlier shows the rest. Finished rows get a green tick and fold down to a step count. Your coworker can add notes as it goes, like 9 themes in 8 of 8 batches.
3

Stop one that's off track

Every working row has a stop icon: “Stop this agent — the rest of the run keeps going”. It works until the run first pauses. Click it and that helper stops, with no confirmation, while the others carry on. Its row shows a dashed circle, or a red mark if it was stopped mid-step. In Ivy’s run, stopping Check: App crash means that theme isn’t written up in this stretch. A stopped helper’s work isn’t kept, so when Ivy’s run continues after its pause, App crash is checked again and then written up.
4

One answer at the end

When the last helper finishes, your coworker turns their reports into the answer you asked for. The card folds down to a count, like 27 agents, and each row shows what that helper used.
A helper’s row also has a transcript link. It opens that helper’s full working in the task’s files, so you can check exactly what it did.

Letting a run use your apps

Helpers can’t touch your connected apps unless the plan asks for them. The one exception is a custom helper with no tool list, which can still do what your permission rules already allow without asking. Ivy’s plan names Slack, because its last step posts the report to #support-leads. When a plan names an app, you’re asked once, before anything runs. The plan appears on the card once you approve.
An approval card headed Let “ticket-themes” use Slack, with only Decline and Approve buttons and no Always allow

One question for the whole run. There's no Always allow, because every run asks for itself.

  • Approve lets any of the run’s helpers, up to 30, use Slack without asking again. The permission ends when the run does, and the card keeps a line saying Using Slack — you approved this for this run.
  • There’s no Always allow. A standing rule would approve the apps of every future run, so each run asks on its own.
  • A “never” rule still wins. Approving a run can’t override a permission rule that says Never. Anything else that would need your yes is refused, and the helper says so in its report.
  • Decline, and nothing has run, so nothing is lost. Your coworker can rework the plan without the app and hand you the result to act on.

Long runs

A big run doesn’t have to finish in one go. After about ten minutes of work it pauses, then picks up again on its own straight away.
The ticket-themes card reading 14 done · continuing with its paused notice, followed by a row showing the run started again on its own

Ivy's run pauses at 14 done, then starts its next stretch on its own. Finished helpers aren't run again.

While it’s paused, the header reads 14 done · continuing and the card says:
Too big for one turn — continuing on the next one. Finished agents are replayed, not re-run.
In plain terms: helpers already working finish first, and finished helpers aren’t run or paid for again. The next stretch appears in the conversation as Started on its own. There’s nothing for you to do.

Keeping a dynamic workflow you like

When a run turns out well, keep it. Once a run completes, its card offers Make repeatable. Its tooltip reads “Saves this run as a dynamic workflow, then adds it to Workflows with a trigger that runs it.”
The finished ticket-themes card folded down to 27 agents, with the Make repeatable button and its tooltip above it

Make repeatable appears only on a run that completed. Ivy's ticket-themes run is ready to keep.

Click it and a message confirms what it made: “Saved as the ticket-themes dynamic workflow and added to Workflows, with a trigger that runs it.”
  • A saved dynamic workflow. It’s kept in your coworker’s own files, so every task can use it. In the chat, type /ticket-themes. Its row in the slash menu reads “Run the ticket-themes dynamic workflow”. Add what it should work on after the name, like /ticket-themes march-tickets.csv, then send.
  • A separate workflow. A new one appears under Workflows. It isn’t the dynamic workflow itself. It has a Start trigger, then one step that asks Ivy to run ticket-themes and waits for the result. Add steps after it to act on what comes back.
A workflow canvas with a Start node connected to a step titled ticket-themes, badged with the coworker Ivy

The workflow that Make repeatable builds: a Start trigger, then one step that hands the ticket-themes job to Ivy.

You don’t always need the slash command. Your coworker can reach for a saved dynamic workflow by itself when a request fits it. A dynamic workflow can even run a saved one as one of its steps. Make repeatable never overwrites a different dynamic workflow with the same name. It saves the new one beside it, as ticket-themes-2, and the message says so. Then change the name inside the new script to match, or it takes over the original’s. See Dynamic workflow scripts. Each click of Make repeatable adds another workflow, so click it once per run. To read or change a saved dynamic workflow, open your coworker’s Files tab.

Under the hood

The plan your coworker writes is a short script, built from a handful of building blocks: agent, parallel, pipeline, phase, log, budget and args. You don’t need to read it to use any of this. To read one part by part, see Dynamic workflow scripts.

Good to know

Say how big the job is when you ask. “Go through all 200 tickets and group them by theme” tells your coworker to plan for scale. “Have a look at these tickets” doesn’t.
Six at a time, 30 in all, within a spending limit. Up to six helpers work at once, and the rest wait their turn. One run can use up to 30 helpers, so a bigger job needs a second, narrower run. Your coworker also gives each run a spending limit. When there’s no room left for another helper, no new ones start. If a big job runs short, ask your coworker for a bigger limit.
Helpers work alone. They don’t see your conversation, can’t start helpers of their own, and can’t ask you anything. Some can only read, and some can also change files. Your coworker picks which kind each job needs.
Results live in the task’s files. Each helper’s transcript is saved there, and so is any result too long to hand back to your coworker in full. Like all task files, they’re discarded with the task’s private workspace when it ends. Download anything you want to keep, or ask your coworker to save it to itself.

Common questions

Yes, until the run first pauses. While a helper is working, its row has a stop icon. Click it and that helper stops, and the rest of the run keeps going. After a pause, stop the task instead, and every helper stops with it. A stopped task leaves the line “This run was stopped before it finished.”
More than an ordinary task, because you’re paying for every helper on the team. Each row on the card shows what that helper used, though after a pause, rows finished in an earlier stretch show none. Each run also works within a spending limit. That’s why the capability is off until you turn it on.
Usually the rest carry on. The failed row turns red and shows what went wrong, and your coworker builds its answer from what came back. If the whole run fails, the card says why.
Only if you say yes. When the plan names an app, you approve it once, before anything runs, and the permission ends with the run. See Letting a run use your apps.
Yes. Click Make repeatable, open the new workflow under Workflows, add a Scheduled Trigger in front of its ticket-themes step, then start the workflow. Or give your coworker a schedule whose task is “Run the ticket-themes dynamic workflow.” If it uses an app, each new run still asks for your approval first.

Next steps

Dynamic workflow scripts

The building blocks behind every plan.

Working with code and files

The capability this depends on.

Slash commands

Run a saved dynamic workflow by name.

Working with coworkers

Hand work to a real coworker instead.