Skip to main content
Parallel collaboration

Dynamic Workflows

Dynamic workflows let Qoder CLI CN run structured multi-agent processes in the background. They suit tasks that need phased execution, large-scale concurrency, cross-validation, or a reusable fixed process. A dynamic workflow puts its orchestration plan into a JavaScript script. The script decides which subagents to launch, how to divide phases, how to merge intermediate results, and what final result to return to the current session.

When to use dynamic workflows

ApproachBest for
SubagentA single focused subtask that only needs to return a summary to the main session.
SkillReusable instructions, domain knowledge, or a process the main Agent should follow.
Dynamic workflowReusable orchestration requiring multiple subagents, multiple phases, parallel branches, or verification rounds.
Use a dynamic workflow when a task is clearly bigger than a single Agent call: repository audits, deep research, migration planning, release checks, cross-file scans, or review processes that need several independent perspectives before summarizing.

What dynamic workflows can do

CapabilityDescription
Scripted orchestrationKeep loops, branches, phases, and intermediate state in the dynamic workflow script.
Multi-agent dispatchLaunch multiple subagents for independent slices of work.
Phased executionShow progress with named phases such as scan, analyze, verify, and summarize.
Parallel or pipelined processingRun independent branches concurrently, or pass each item through several processing stages in order.
Background executionKeep using Qoder CLI CN after starting a dynamic workflow.
Process reuseSave frequently used processes as project-level, user-level, plugin, or built-in dynamic workflows.

Running a dynamic workflow

You can ask Qoder CLI CN to use a dynamic workflow in natural language:
Use a dynamic workflow to review this repository for security risks and summarize the findings.
You can also invoke a saved or built-in dynamic workflow directly by name:
Use the deep-research dynamic workflow to investigate the trade-offs of this architecture decision.
Qoder CLI CN may create a dynamic workflow for the current request, or use an existing one when it matches the task. Dynamically generated workflows show their plan before execution; you can run it, view the raw script, reject with feedback, or cancel. Dynamic workflows run as background tasks. After starting, Qoder CLI CN returns a run ID and keeps showing execution progress in the tasks interface.

Deep Research

deep-research is a built-in dynamic workflow suited to questions that require broad web retrieval, comparing multiple sources, and verifying conclusions one by one. You can invoke it directly with a clear research question:
/deep-research Compare the security and operational trade-offs of passkeys versus passwords for consumer web apps in 2026.
If the question is too broad to start researching directly, Qoder CLI CN asks clarifying questions first, then passes the refined question to the dynamic workflow. The dynamic workflow has five phases:
PhaseWhat it does
ScopeBreak the question into complementary search angles, chosen according to the question's domain.
SearchLaunch one web-search Agent per angle in parallel. Each Agent ranks results against the original question and excludes clearly low-quality or irrelevant pages.
FetchDeduplicate URLs, fetch relevant public pages, assess source quality, and extract concrete claims that are supported by the original text and can be verified or falsified.
VerifyMultiple independent Agents challenge the extracted claims. Claims that fail cross-validation are excluded; claims that cannot be verified are marked "unverified" rather than "refuted."
SynthesizeMerge semantically duplicate claims, organize related findings, annotate confidence, and produce a report with an executive summary, caveats, open questions, and source citations.
The final report provides evidence, confidence levels, and source URLs for the main findings. Claims that failed verification do not enter the main findings; if an Agent or network request fails before verification completes, the report lists the affected claims as "unverified" rather than treating them as "refuted." Deep Research uses web search and web content fetching tools through subagents. Pages that require sign-in, are private, sit behind paywalls, or are otherwise inaccessible may not yield useful content. This dynamic workflow launches multiple Agents and can consume tokens quickly; start with a well-scoped question, and constrain time, region, audience, or decision criteria when necessary.

Monitoring dynamic workflows

Use /workflows in the TUI to open the dynamic workflow task panel.
/workflows
In the panel you can see running and completed dynamic workflows, and inspect status, phases, Agents, logs, output paths, errors, and final results. /tasks also shows dynamic workflow tasks alongside other background tasks. While a dynamic workflow is running, you can view individual Agents on the detail page. If an Agent is still controllable, you can skip or retry it from the detail page.

Saving dynamic workflows

Saved dynamic workflows can be reused by name. Qoder CLI CN discovers dynamic workflows from these locations:
ScopeLocationUse case
Project.qoder/workflowsThe dynamic workflow belongs to the current repository or team.
User~/.qoder-cn/workflowsPersonal dynamic workflows used across projects.
PluginDynamic workflows provided by a pluginThe dynamic workflow ships with a plugin.
Built-inQoder CLI CN built-in dynamic workflowsThe dynamic workflow is provided by Qoder CLI CN.
When names conflict, project-level dynamic workflows take precedence over plugin and built-in ones. Team-shared processes belong in the project-level directory; personal processes that should not be committed to the repository belong in the user-level directory. A saved dynamic workflow is a JavaScript file that starts with an exported meta object. The metadata tells Qoder CLI CN the workflow's name, description, phases, and optionally when to use it or an input schema.
export const meta = {
  name: "repo-audit",
  description: "Audit a repository area and summarize risks",
  whenToUse: "Use when the user asks for a structured repository audit",
  phases: [
    { title: "Scan", detail: "Find relevant files and areas" },
    { title: "Analyze", detail: "Run focused analysis agents" },
    { title: "Summarize", detail: "Merge findings into a final report" }
  ]
};
After saving to .qoder/workflows/repo-audit.js, you can have Qoder CLI CN use it like this:
Run the repo-audit dynamic workflow targeting the authentication module.
Saved dynamic workflows can receive input via args. Target paths, issue IDs, research questions, options, or any value that differs per run but should not modify the script are good candidates for args.

How dynamic workflows run

A dynamic workflow script is plain JavaScript. Scripts can use helpers such as agent(), parallel(), pipeline(), phase(), log(), workflow(), args, and budget.
  1. Qoder CLI CN picks a saved dynamic workflow for the task, or creates a new one.
  2. If review is required, Qoder CLI CN shows the workflow's name, phases, script, and run options.
  3. The dynamic workflow starts as a background task.
  4. The script launches subagents and groups them into phases.
  5. Intermediate results are kept in the dynamic workflow runtime and do not fill up the main session context.
  6. The final result is written to the workflow run output and summarized back in the current session.
During a dynamic workflow run, the script, manifest, journal, transcript, and outputs are written to the current session directory under .qoder/sessions.

Permissions and safety

Dynamic workflows may run many subagents and can consume tokens quickly. When validating a large or costly dynamic workflow, start with a smaller scope first. Dynamic workflow scripts cannot directly access the shell, filesystem, network, Node.js APIs, or MCP services. All side effects happen through subagents, which still go through Qoder CLI CN's tool, permission, and Hooks. Use Permissions to control what dynamic workflow subagents can do; use Hooks to enforce organization-level policies before and after tool calls.