Dynamic Agent Workflows: Letting Models Build Their Own Execution Frameworks

1. Where the Problem Starts: The Capability Boundary of a Universal Orchestration Framework

In recent years, mainstream coding agents are essentially a combination of “model + an orchestration framework,” often called a harness in the industry. The framework is responsible for assembling context (which files to read, which history to retrieve), exposing tools (file read/write, command execution, network access, data queries), splitting subtasks, deciding when to stop, retrying after failures, and storing intermediate results.

The value of this framework is that it abstracts general engineering tasks into a fixed pipeline. As a result, most tasks that look like coding—adding features, fixing bugs, writing tests, and refactoring—can run out of the box. But universal abstraction necessarily contains assumptions. Once the task structure deviates from those assumptions, the default framework changes from “good enough” to “awkward.”

The tasks that truly need custom orchestration fall into several structurally different categories:

• Troubleshooting low-frequency and occasional failures: Problems where a single run has a very high success rate and a very low failure probability. A single execution cannot provide a conclusion. What is needed is a loop of “multiple parallel hypotheses + repeated sampling + evidence-based falsification,” not a single question-and-answer exchange.
• Research and verification tasks: The output is a set of assertions to be checked. The workflow focuses on “gathering evidence one by one,” rather than “generating code.”
• Multi-role review and adversarial evaluation: Security audits, solution reviews, and business plan evaluations require independent judgments from different perspectives followed by cross-examination.
• Batch homogeneous tasks: Processing dozens of documents or hundreds of file units requires a fan-out/merge structure and secondary validation.
• Collaborative team tasks: Multiple executors divide work, hand off results, and run in parallel, requiring shared state and conflict resolution.

When these five types of tasks are placed in front of a fixed pipeline, the gap becomes a large amount of manual coordination. Dynamic workflows are designed to solve this gap.

2. Paradigm Shift: From “Static Templates” to “Runtime-Compiled Orchestration”

In traditional approaches, orchestration logic is configuration or scripts written in advance by engineers. The key shift in dynamic workflows is: the orchestration script itself becomes an output of the model.

In other words, the model no longer only produces an answer to the task. It first produces a program for producing that answer—defining what roles exist, what tools each role can use, how phases run in parallel or sequentially, what the termination conditions are, and where artifacts are written. It then executes this program immediately and self-corrects based on execution results.

This is essentially program synthesis applied at the process layer: the task description is the specification, and the orchestration script is the synthesized program. This brings three structural benefits.

First, context is assembled on demand. After reading the repository, logs, or documents, the model can determine which information is worth entering which role’s context. Static templates cannot provide this “reconnoiter first, then define the workflow” capability.

Second, termination conditions can be explicitly designed. The default framework often uses “task completion” as the only stop signal. Dynamic orchestration can express formal stopping criteria such as “a hypothesis has been refuted by evidence,” “score variance has converged,” or “error rate is below a threshold.”

Third, the workflow itself becomes a reusable asset. An orchestration scheme polished for a particular class of problems can be exported, versioned, and shared. The next time a similar problem appears, it can be called directly instead of starting the conversation over.

3. Mechanics Breakdown: Six Stages of a Dynamic Workflow

Stage 1: Task parsing and constraint extraction. The model needs to turn vague requirements into an executable specification: what the target artifact is, where the inputs are, what hard constraints exist (which files must not be modified, whether citations are required, how many rounds of budget are available), and what counts as success. The quality of this step directly determines the ceiling of every subsequent stage.

Stage 2: Orchestration design. Decide role division (generator/executor/reviewer/arbiter), topology (sequential, parallel fan-out, loop, conditional branch), tool allowlists for each role, and degree of parallelism.

Stage 3: Script generation. Produce a readable and reviewable orchestration description. This point is important: if orchestration logic is hidden inside the model’s implicit reasoning, humans cannot review it. Once it becomes text, humans can modify it, store it, and reuse it.

Stage 4: Constrained execution. Run within sandbox and permission boundaries. Write operations are limited to designated directories, network and credential access is controlled, and irreversible operations (deletions, production changes, large-scale batch rewrites) have human confirmation checkpoints.

Stage 5: Observation and retention. Each run leaves structured artifacts: hypothesis lists, evidence chains, scoring details, and failure samples. Writing artifacts to disk rather than keeping them in the conversation context is key to controlling cost.

Stage 6: Evaluation and iteration. Use a unified scoring standard to judge whether this round of orchestration meets the target. If not, change the workflow rather than modifying a single prompt.

4. Seven Directly Reusable Orchestration Patterns

1. Hypothesis-falsification loop. Suitable for low-frequency failures. Ask the model to propose multiple competing hypotheses at once. Each hypothesis requires an independent reproduction experiment. “Whether it can be refuted by evidence” is used as the elimination condition until only the hypothesis with the strongest evidence remains. This logic comes from the scientific method and is far more effective than telling the model to “think again,” because it turns the stopping condition from subjective to objective.

2. Fan-out and merge. Split a large-scale homogeneous task into independent units for parallel processing, then aggregate them uniformly. It is suitable for batch renaming and cross-file symbol replacement, batch document rewriting, and batch data cleaning. The key is that slices must be truly independent; otherwise, parallelism introduces conflicts.

3. Independent verification (Verifier). Use different executors for generation and verification, and the verifier does not share the generator’s reasoning process. It only looks at artifacts and original facts. This is used in scenarios with extremely high accuracy requirements, such as verifying each assertion in technical documentation item by item.

4. Tournament selection. First generate a large batch of candidates, then compare them pairwise or eliminate them by groups according to predefined dimensions, gradually converging to a small set of optimal solutions. It applies to naming, solution selection, and architecture choices. The prerequisite is that scoring dimensions must be fixed first; otherwise, comparison degrades into random ordering.

5. Multi-perspective adversarial review. Have multiple executors each play a fixed role (reviewer, user, competitor, attacker) and apply pressure to the same artifact, then have an arbiter role summarize conflict points. Its value is forcing coverage of blind spots that a single model easily overlooks.

6. Mining and distillation. Induct recurring patterns from a large amount of historical records, distill them into executable rules, and write them into project-level convention files. Its output is not a conclusion but institutionalization: turning one-time discoveries into long-term constraints for subsequent runs.

7. Stage-gate pipeline. Insert explicit quality gates into long workflows. If the previous stage’s artifact does not meet the standard, it cannot enter the next stage. This prevents errors from amplifying along the pipeline.

5. Prompt Design: From “What Result You Want” to “What Process You Want”

Most people’s prompts only describe the desired result. Under dynamic orchestration, this wastes the biggest leverage. An effective specification needs to cover six things: artifact form, evidence standard, role division, termination conditions, prohibitions, and budget limits.

An illustrative orchestration specification (the format is for explanatory purposes only and is not a specific product interface):

workflow: intermittent-failure-repro
goal: reliably reproduce a test failure that occurs about 1 in 50 runs
roles:
  - theorist:  propose and rank competing hypotheses, at least 3 per round
  - runner:    sample a single hypothesis N times and calculate failure rate
  - referee:   determine support or refutation based only on evidence
budget:
  max_rounds: 6
  parallel_workers: 4
  samples_per_round: 200
stop_when:
  - a repeatable reproduction procedure exists (failure rate > 50% for 10 consecutive runs)
  - or only 1 hypothesis remains and evidence is insufficient to refute it
constraints:
  - do not modify the source code of the system under test
  - every conclusion must include a log line or run output as evidence
artifacts: [repro_script, sampling_log, verdict_table]

Compare this with typical prompts:

• Weak: “This test occasionally fails. Help me check it.” — There is no sampling scale, no hypothesis management, and no stopping condition. The model can only provide guesses.
• Better: “Use a workflow to reproduce it: propose at least 3 competing hypotheses, independently sample each hypothesis 200 times and calculate the failure rate. If refuted by evidence, eliminate it and record the reason. Stop when a stable reproduction procedure is found or rounds run out. Do not modify the system under test, and attach run evidence to every conclusion.”

6. Engineering Implementation Points

Versioning and reuse. Manage effective orchestrations like code: naming, change logs, applicable scenario descriptions, and effectiveness comparisons. The value of sharing often exceeds the benefit of a single execution.

Cost and latency control. Dynamic orchestration naturally tends to spin up a few more executors. You must set limits on parallelism, per-role budgets, and early-stopping rules. You should also tier roles by capability—use stronger models for generation and lighter models for verification and batch mechanical work. Costs can be significantly reduced without losing conclusion quality.

Context hygiene. Long loops push a large amount of intermediate noise into the context, degrading judgment in the later stages. The standard practice is to write intermediate results to disk and bring only indexes and summaries back into the context.

Observability. Each executor’s input summary, tool calls, elapsed time, and artifact paths should be recorded in a structured way. These logs, metrics, and alerts can be carried by general-purpose logging services and monitoring/alerting capabilities. Intermediate artifacts can be stored in object storage, fan-out tasks can be decoupled with message queues, and parallel executors can run on container platforms. These are vendor-neutral general platform capabilities that can be composed in standard ways on cloud platforms.

Permissions and irreversible operations. Operations such as batch renaming, whole-project replacement, and file deletion become extremely expensive to roll back once executed at scale. The recommended default is “generate patch + human confirmation + rollback-capable commit,” rather than letting executors write directly to disk.

7. Risks and Boundaries

Dynamic workflows do not solve unclear goals. If “what counts as good” is not defined, even the most sophisticated orchestration only scales errors.

There are four common failure modes: first, reasonable process but wrong facts: role division looks beautiful, but the evidence chain is fabricated. This must be constrained by evidence binding and mandatory citation. Second, over-engineering: applying dynamic orchestration to a task like changing one line of copy only wastes budget. Third, tournament selection without scoring standards: when comparison dimensions are not fixed, selection is equivalent to drawing lots. Fourth, evaluation standards contaminated by the generator: if generation and review share the same context, verification becomes meaningless. They must be isolated.

8. Deployment Checklist

1. Does the task have a clear success criterion and verifiable artifacts?
2. Is the task structure substantially different from a “single question-answer” task?
3. Are the roles truly independent (tools, context, and judgment basis are not shared)?
4. Are termination conditions objective and determinable?
5. Are budgets (rounds, parallelism, cost) capped?
6. Do irreversible operations have human confirmation and a rollback path?
7. Are effective orchestrations saved, named, and reused?

The real significance of dynamic workflows is to upgrade “teaching models to do work” from prompt engineering to process engineering: you no longer ask follow-up questions round by round; you define processes, review processes, and accumulate processes. When coding agents build execution frameworks for themselves, the human role also moves forward from operator to designer of rules and criteria.