Dynamic workflows still need a stopping rule

The useful idea in the article

Anthropic describes dynamic workflows as task-specific orchestration: the system breaks down a problem, runs independent subagents, checks and challenges their findings, then combines the results. Progress persists across interruptions. The article also makes the cost visible: this can consume substantially more tokens than an ordinary session.

The part I want to examine is the checking step. Parallel work can cover more ground, but a larger collection of plausible answers is not automatically a more trustworthy result. I care about what a verifier receives, what it can change, and what happens when it disagrees with the writer.

A concrete version of the problem

Resume Gauntlet starts from evidence about someone’s work and produces a document. The failure I wanted to catch was not only bad grammar. A system can turn a team result into a sole-author claim, turn an experiment into a production claim, or keep a number while dropping the conditions that made it true.

I separated raw facts from rendered wording and made the review a distinct part of the workflow. Eight reviewer perspectives inspect the output. A plausibility check asks a different question from a parser check; neither replaces the other. Their value comes from the particular failure each is responsible for detecting.

Independence needs an implementation

In the canonical Claude workflow, writer and verifier model families must differ, and verifier tools are read-only. The reviewer reports a defect instead of rewriting the artifact it was supposed to judge. That preserves an inspectable relationship between the draft, the finding and the later fix.

I also check that expected reviewers returned. A missing report is not a passing report. Otherwise a broken orchestration step can make a run look cleaner simply by skipping the person, or agent, most likely to object.

This is a narrower, task-specific system than the broad workflows in Anthropic’s article. I am comparing design decisions, not claiming I implemented Claude’s dynamic-workflow runtime or that this project depends on that feature.

Check the thing that will be delivered

A verdict about an earlier draft should not quietly authorize a changed PDF. I bind validation to the artifact being delivered and inspect the rendered result. Layout, parse integrity and claim defensibility can all fail after a source-level edit that looked harmless.

The same principle appears in software review. If a worker returns a claim that a test passes, the orchestrator needs enough evidence to connect that result to the code under review. A summary without the artifact identity is easy to carry past the point where it stopped being true.

The stop condition is part of the product

A review system needs a defined response to rejection. In Resume Gauntlet, blocking outcomes keep the workflow unresolved, bounded fix loops attempt repairs, and missing verification must be reported. A completion message cannot be the only evidence that the work completed.

Reuse is useful when its conditions are explicit. An unchanged artifact and unchanged review requirements can justify carrying prior work. When either changes, the workflow needs to determine what must be checked again. Repeating every step wastes effort; carrying every old verdict hides risk.

That is the practical question I take from this reading: where is additional parallel work likely to change the answer, and where do I instead need a stronger contract between the work and its verification? For systems I build, I want the stopping rule to be something I can inspect and test.

Sources & further reading

• Anthropic: Introducing dynamic workflows in Claude Code
• My Resume Gauntlet project notes