# Workflow Runtime > Letting the model author its own workflow and spawn agents for it. Often it works; often it spends tokens and hours on work nobody needed. - Site: isnan lab (https://lab.falah-isnan.com/experiments/workflow-runtime) - Author: Falah Isnan (https://falah-isnan.com/) - Published: 2026-09-23 - Updated: 2026-09-23 - Stack: Agent orchestration / Claude - Access: Research note - Interim result: A workflow that has been designed and tested beats pointing the model at every problem and letting it author its own. Dynamic workflows are not written off — but before that path is worth taking, Workflow Runtime has to bound the work an agent may do and make it explicit when the process must stop. ## The question Should the model design a workflow for each problem, or run a workflow that was designed and tested in advance? The experiment is inspired by Claude's dynamic workflows: hand the model a problem, let it spawn several agents, and let the workflow it invents do the work. It is an appealing idea because it removes the design step. The question is what you give up when nobody decided in advance what the run was allowed to do. ## How it ran 1. **Hand over the problem, not a plan.** The model receives the problem and decides for itself what the workflow should be. No fixed steps, no prescribed order. 2. **Let it spawn the agents it wants.** Each agent takes a part of the problem as the model divided it. Nothing bounds how many there are or how much each is allowed to do. 3. **Read the run back.** Not only the answer — the run. What each agent actually did, how much of it was needed, and how long the whole thing took from end to end. 4. **Compare against a designed workflow.** The same problems, through a workflow that was designed and tested first: fixed steps, fixed order, a gate between each one. ## The approaches ### The model designs the workflow The model reads the problem, decides on a shape, and spawns agents to fill it. Every run is a new design, which means every run is also a new set of mistakes. - No design step — point it at the problem and go. - The shape of the run adapts to what the problem looks like. - Unnecessary work still happens, and nothing stops it. - Tokens and wall-clock are both spent before you can judge the result. ### A workflow designed and tested in advance Fixed steps in a fixed order, tested before it is used. It cannot reshape itself around a problem it has not seen, and it can be read back with confidence when it finishes. - The steps are known, so the result can be read back rather than guessed at. - Work outside the steps does not happen, because there is nowhere for it to happen. - Stopping is a defined condition, not something the run has to notice. - A problem the workflow was not designed for is not served by it. ## What came out Observed across runs rather than measured. The pattern was consistent enough to act on; the numbers behind it are not published. - **Predictability of the result** — Favours: A workflow designed and tested in advance (clear). A tested workflow produces a result you can read back. A model-authored one produces a result and a workflow, and both have to be checked. - **Work actually needed** — Favours: A workflow designed and tested in advance (clear). With the model in charge, agents still did work that nothing needed. Nothing in the run recognised it as unnecessary, so it ran to completion anyway. - **Wall-clock time** — Favours: A workflow designed and tested in advance (clear). For some problems the run simply took a long time. Tokens are the cost people count; execution time was drained just as thoroughly. - **Adapting to an unfamiliar problem** — Favours: Not settled (narrow). Unsettled, and the honest reason to keep the experiment open. A designed workflow cannot stretch to a problem it never anticipated — the dynamic one at least tries. ## Trade-offs - Gain: Letting the model author the workflow removes the design step entirely — there is nothing to build before the first run. Cost: The result is not consistently good. On some problems the model still does work nothing asked for, and the run has no way to notice. - Gain: Spawned agents can divide a problem in a shape nobody specified in advance. Cost: Each agent spends tokens and wall-clock on that division, whether or not it turns out to have been the right one. - Gain: A designed and tested workflow keeps the run inside work that is known to be useful. Cost: It has to be designed and tested first, and it will not stretch to a problem it was not built for. ## What is not solved 1. Agent work is still unbounded. The runtime needs to limit what an agent is allowed to do before the dynamic path is worth using. 2. Stopping is not defined. The run needs an explicit condition for when the process has to end, rather than ending when the model decides it is done. 3. The comparison is observational. Runs were read rather than measured, so there are no published figures for token or time cost. ## Interim conclusion A workflow that has been designed and tested beats pointing the model at every problem and letting it author its own. Dynamic workflows are not written off — but before that path is worth taking, Workflow Runtime has to bound the work an agent may do and make it explicit when the process must stop. What this result fed into: a runtime that runs multi-step agent workflows in a fixed order, rather than one the model invents per problem. sequential-workflow. ## Process notes - A designed and tested workflow beat letting the model invent one per problem. - Unnecessary agent work still happened, and nothing in the run recognised it as unnecessary. - Before the dynamic path is worth using it needs bounded agent work and an explicit stop condition.