10 Ways Playbooks Beat Ultracode

This is the technical companion to Playbooks vs Dynamic Workflows, which explains why a process can be worth preserving in the first place.

The strongest technical Playbook advantages

1. Cross-harness orchestration

Each Step can declare its own:

• Registered harness
• Model
• Reasoning settings
• Instructions
• Required outputs
• Trigger conditions

One Step could use Claude Code, another Codex, another OpenCode, and another a custom harness.

Claude workflows support per-agent prompts, tools, effort, and Claude model selection, but the managed workers remain Claude Code agents. A Claude agent could shell out to another CLI, but that is not the same as making that harness a first-class worker with lifecycle, status, artifacts, and provenance. Claude custom-agent configuration

Mix models and agent harnesses by Step.

2. Durable forks instead of replay

The Playbook design explicitly says that rerunning a Step from the same sealed parent creates:

• A new execution identifier
• A new isolated workspace
• A new sibling successor state
• Preserved history for both outcomes

It forks the Run history, not the Playbook definition.

Claude can restart a running agent. It can also relaunch a stopped workflow and reuse completed results. But the first changed or failed agent, plus every subsequently started agent, runs again. Even completed agents in a parallel fan-out may be rerun because they started later.

That is suffix replay, not durable branching. Claude workflow replay semantics

Replay recomputes. A Playbook fork preserves alternatives.

3. First-class task states

A successful Playbook Step does not merely return text. It publishes a complete immutable task state containing:

• Code and filesystem state
• Git position and changes
• Exact artifact versions
• Parent state identifiers
• Producing Step and Sessions
• Exact input binding
• Declared outputs

This means you can answer: “What exact world did this Step start from, and what exact world did it produce?”

Claude workflows preserve their script and agent results, but they do not document an equivalent immutable task-state DAG.

Every successful Step produces an inspectable state, not merely an answer.

4. Atomic publication

During a Step, edits remain isolated and invisible to downstream Steps.

Only an accepted step_complete operation publishes the full successor state. If the Step fails, its partial work does not silently become input to later Steps.

That gives Playbooks a transaction-like boundary:

• Success publishes one state
• Failure publishes no state
• Partial work does not leak
• Completed states cannot later be mutated

Partial work stays private until the Step is accepted.

5. Versioned artifacts with exact provenance

Artifacts are not merely files that happen to exist.

A Playbook knows:

• Which Step declared the artifact
• Which execution produced this occurrence
• Which state contains it
• Which exact upstream artifact versions were consumed
• Which Session or Sessions participated
• Which definition revision governed the work

This prevents “use the latest research file” ambiguity.

Know exactly which work produced every artifact.

6. Interactive agent Sessions

Claude’s workflow UI shows phases, agent counts, token totals, elapsed time, prompts, recent tool calls, and results.

But Claude workflows explicitly prohibit normal mid-run user input. Human sign-off between stages requires separate workflows. Claude workflow controls and limits

Playbook Steps are intended to run through addressable PTY Sessions. A human can enter the Session, inspect what is happening, answer a question, provide guidance, and allow the same atomic Step to continue.

Inspecting an agent is not the same as working with it.

7. Continue a Step in a fresh context

The Playbook design allows one atomic Step execution to use multiple sequential Sessions.

If one model context ends before the work is complete, step_continue can start a fresh Session with:

• The same exact input binding
• The same unpublished workspace
• The original instructions
• Additional continuation instructions
• The same eventual atomic completion boundary

Claude can restart an agent or replay workflow work. That is different from continuing the same atomic Step in a fresh model context without publishing an intermediate state.

A Step can outlive one model context.

8. Explicit parallel branches and merges

When several Steps run from the same state, their results become independent siblings. Wall-clock completion order does not accidentally make one depend on another.

Combining them requires an explicit merge Step. The merge agent chooses the exact parent states it used, and those parents become permanent provenance.

Parallel work never merges by accident.

9. Selective recomputation from exact inputs

Playbook eligibility is based on exact artifact occurrences and exact input bindings.

If research changes but the approved design does not, only Steps whose relevant input binding changed need to become eligible again. The engine does not have to invalidate everything that happened later merely because it started later.

Rerun work because its inputs changed, not because it appeared later in a list.

10. A process that remains attached to the task

A Claude workflow is a Run. It finishes, pauses, stops, or is invoked again.

A Playbook remains attached after it becomes quiescent. If a human or agent later publishes a new task state, the Playbook reevaluates what is now applicable.

The Run can stop without the process disappearing.

Budget-aware execution

This is one of the strongest differences.

Claude currently provides:

• Token and elapsed-time displays
• An advisory workflow-size target
• Up to 16 concurrent agents
• Up to 1,000 agents per Run
• Per-agent maxTurns
• A large-workflow warning
• A --max-budget-usd cap for an enclosing non-interactive Claude session

The size setting is advice, not a cap. The large-workflow warning is advisory. There is no documented per-Step token allocation, verification reserve, or wall-clock deadline. Claude workflow cost controls, Claude CLI budget cap

Allocate a fixed compute budget deliberately across exploration, execution, verification, and retries.

Playbooks are designed to:

• Set a total token, cost, or wall-clock budget
• Allocate budgets by Step
• Reserve budget for verification
• Control maximum concurrency
• Reallocate unused budget
• Spend more on critical Steps
• Continue improving until the budget or quality threshold is reached
• Maximize useful work within a fixed resource envelope

Dynamic workflows can cap consumption. Playbooks can allocate a budget across the process.

Dynamic workflows report resource use. Playbooks plan it.

Technical costs of Playbooks

• More state and checkpoint storage
• More runtime and recovery complexity
• More harness adapters to maintain
• Potentially large branch histories
• Harder merge and conflict semantics
• More authoring and output-contract work
• Less control-flow flexibility than arbitrary JavaScript
• Full-coverage joins can block indefinitely
• Retry and crash recovery still require careful design
• A bad process can be repeated with greater precision

What dynamic workflows technically do better

• Arbitrary JavaScript control flow
• Fast task-specific adaptation
• Large fan-out with little setup
• Built-in prompt-cache sharing
• Existing progress and inspection UI
• Per-agent prompts, Claude models, tools, and effort
• Pause, restart, and cached replay
• Easy saving, editing, and distribution
• No immutable-state engine to operate
• Better fit for novel or disposable work

For the first-principles argument, read Playbooks vs Dynamic Workflows.

Dynamic workflows coordinate agents. Playbooks coordinate models, harnesses, Sessions, artifacts, and the evolving state of the task.