Playbooks vs Dynamic Workflows

When you ask an AI system to investigate a production failure, redesign part of a software system, or conduct research, it produces more than a result. It also chooses a process. It decides how to divide the work, what to inspect, which parts can run in parallel, what evidence to collect, how to combine the results, and when to stop.

That means you must evaluate two outputs: the result and the process that produced it. The process matters most when a wrong result would have serious consequences, the result is hard to check, or you expect to repeat the work.

This is the practical difference between Claude Code's dynamic workflows and the Playbooks Alinery is designing. A dynamic workflow lets AI generate an orchestration script for the current task. A Playbook specifies how repeated tasks should run and remains available for review and revision. Claude workflows are available now; the Playbook behavior below is Alinery's current design and still has to be implemented and validated.

What dynamic workflows do

A Claude Code dynamic workflow is a JavaScript program that coordinates subagents. Claude can write one from a request, and Ultracode mode can decide to launch one or more workflows for a substantive task. A workflow can divide work into phases, run agents in parallel, repeat work until a condition is met, and combine the results.

Dynamic workflows are not opaque or necessarily disposable. You can inspect the script, edit it, save it as a command, and run it again. That makes them useful for one-time work and for testing a process before deciding whether to maintain it.

Their main advantage is low setup cost. If a task is new, the environment is changing, or you do not expect to repeat the work, asking AI to design the process at execution time is often reasonable. It can adapt its plan to facts that were not known in advance. It can also help you discover whether any part of the process is worth standardizing.

If AI can generate the process, why write a Playbook?

The relevant difference is not whether a human or an AI wrote the first draft. AI can draft a Playbook, and a person can save a generated workflow. The difference is whether someone will review and update the process for future tasks.

Saving a generated script is only the first step. To rely on it repeatedly, someone still needs to inspect its assumptions, decide where it applies, test it, revise it when conditions change, and take responsibility for the checks it requires. Once that happens, it becomes a maintained process.

Alinery is designing a Playbook as one Markdown file that defines a set of Steps. Each Step names its required inputs, advisory outputs, model, agent harness, instructions, and optional harness settings. The harness is the program that runs the model and gives it tools, such as Claude Code or Codex. A Task selects one Playbook when it starts and keeps the exact selected version for the life of that Task.

This gives people a versioned file to inspect. They can see what evidence a Step receives, what work it asks an agent to perform, and what later work depends on its result. A later edit to the Playbook does not silently change a Task that is already running.

A Playbook does not require one fixed sequence

A reusable process does not have to send every task through the same ordered list.

In the current design, a Step becomes eligible when the Task has the files that Step requires. The design calls this material eligibility. Different saved results can make different later Steps eligible. If several inputs match one requirement, several applications of a Step can run in parallel. A later Step can wait for all associated results. Task policy, budgets, and existing claims still determine whether eligible work starts.

The Playbook fixes the parts that should remain consistent, such as required inputs, instructions, and downstream dependencies. Agents still make judgments inside each Step, and the Task can take different paths when its evidence differs.

Process information helps when results are hard to verify

For simple work, checking the final result may be enough. If a script converts a file and a test confirms the output, there may be little value in maintaining a detailed process.

For software architecture, security work, research, and other tasks without an obvious answer, the final result can be difficult to assess directly. In those cases, the process provides additional evidence. You can inspect which sources were assigned, which checks were requested, what evidence and results were retained, and which required inputs were available before later work began.

This does not prove that the result is correct. A documented process can repeat a bad assumption or omit an important check. It does, however, make the basis of the result easier to inspect. When a new workflow is generated for every task, a reviewer may need to understand a new process while also judging its output.

Repeated use can make review more consistent

People learn a process by reviewing it repeatedly. They learn what each Step normally produces, where errors tend to appear, which evidence should be present, and which deviations need attention. That familiarity can make missing evidence and unusual results easier to notice.

Whether this reduces verification time or improves quality must be measured. Familiarity can also create complacency, and a repeated process can reproduce the same mistake. A Playbook still requires review, measurement, and revision. Its benefit is that those activities can refer to the same process across multiple Tasks.

Process changes should be deliberate

A maintained process should change when evidence shows that a change is useful. A person can review completed work, identify repeated failures or interventions, revise the Playbook, and use the revised version for later Tasks.

The current design does not automatically rewrite Playbooks. Automatic revision would require the system to decide which history matters, what change it supports, and who may approve the new policy. A practical operating rule is to write or propose a revision, have a person review it, and select the revised file for new Tasks. Existing Tasks keep the version they started with.

The costs of Playbooks

Playbooks require work before and between executions. Someone must define the process, test it, review failures, maintain it, and stop using it when it no longer fits.

A poor Playbook can repeat a bad decision across many Tasks. A stale Playbook can apply assumptions that are no longer true. Too much structure can also interfere with exploration before the team understands the problem well enough to define a useful process.

The execution system is more complex too. It must track exact inputs, preserve state and history, isolate concurrent work, record where each result came from, and recover safely from interruption. A dynamic workflow can use ordinary JavaScript control flow without requiring that additional state model.

Three questions determine which approach fits

Will you perform the work again? If probably not, a dynamic workflow usually has the advantage. You avoid maintaining a process that may never run again.

What happens if the result is wrong? For a cheap experiment, variation in the process may be acceptable. For decisions involving money, security, safety, or long-term technical commitments, knowing how the work was performed becomes more valuable.

How easy is the result to verify? If a reliable test can check the answer quickly, maintaining the process may add little. If the answer is difficult to evaluate, explicit inputs, checks, and review points provide useful evidence.

High stakes do not make a Playbook correct, and one-time work does not make a dynamic workflow careless. These questions only identify when the cost of maintaining a known process is more likely to be justified.

Generating several results is another valid approach

You can run several dynamic workflows and compare their results. Independent attempts may find different solutions, and disagreement can reveal uncertainty. This works especially well when an objective test or a qualified reviewer can select the best result cheaply.

The selection step still needs a process. The attempts may all miss the same problem because they use similar prompts, models, or evidence. More candidates increase the chance of finding a good answer, but they do not guarantee that any attempt performed a missing check.

Early errors affect later work

An early process error can become an input to later work. For example, an incorrect requirement can lead to incorrect code, and tests written from the same requirement can then confirm the wrong behavior. Each later Step may add work that must be inspected or replaced when the original error is found.

This is a practical reason to make important checks explicit. It is not evidence that errors grow at a fixed exponential rate. The amount of damage depends on the task, when the error is detected, and how much later work depended on it.

Use each approach where it fits

Dynamic workflows are a strong choice for new, one-time, or easily verified work. They reduce preparation time and can adapt the process to the current task. They can also help develop a process before anyone commits to maintaining it.

Playbooks are intended for recurring work where the process itself needs to be inspected, reused, and revised. They make the process explicit, but they do not guarantee a correct result or remove the need for human judgment.

Use a dynamic workflow when you want AI to determine the process for the current task. Use a Playbook when you want a maintained process to specify how repeated work should be done.