Give Claude Code workflows explicit stop conditions

A longer prompt is still a delegation problem

Anthropic describes Claude Code dynamic workflows as a way for Claude to plan larger tasks, run parallel subagents, and verify outputs before reporting back. Its announcement of Claude Opus 4.8 and dynamic workflows names migrations across large codebases as one example. That changes the scale of the work an agent can attempt. It does not change who is accountable for accepting the result.

I would treat repo-scale agent work as a change in delegation, not as a reason to write a larger prompt and hope for the best. A prompt says what outcome I want. A workflow also says what the agent may change, what must be true before it reports success, what evidence it must return, and when it must stop for a person.

That distinction matters because “the tests pass” is not a complete definition of done. A migration can compile while missing a call site, changing behavior that a test does not cover, or leaving obsolete paths behind. A refactor can meet its local checks while crossing a boundary I did not intend to move. The agent should not be allowed to turn uncertainty into an unqualified success message.

I would make autonomy a workflow decision. The model can do more of the work when the task is bounded, the checks are meaningful, and the result is easy to inspect. It should do less when the work changes external behavior, relies on a disputed product decision, or cannot be verified from the repository.

Define the finish line before the agent starts

Before delegating a migration or refactor, I would write down the acceptance conditions in terms someone else could check. “Modernize the clients” is an intention, not a finish line. Which clients are in scope? What should replace the old interface? What must not change? Which tests and static checks are required?

A useful task description separates the desired change from the boundaries around it. The following is a policy sketch, not Claude Code configuration syntax:

task: Replace the deprecated payment client interface
scope:
  include:
    - production code that calls the deprecated interface
    - tests for those call sites
  exclude:
    - public API changes
    - unrelated dependency upgrades
must_pass:
  - repository build
  - relevant test suites
  - formatting and static analysis
must_return:
  - files changed and why
  - commands run and their outcomes
  - remaining deprecated call sites, or evidence none remain
  - unresolved assumptions and risks
stop_if:
  - a public contract must change
  - a required check cannot run
  - behavior is ambiguous in the existing code or tests
  - the change requires expanding the stated scope

The point is not the YAML. The point is that scope, checks, evidence, and stop conditions are separate parts of the delegation. If I leave one implicit, the agent may make a reasonable choice that still isn’t the choice I wanted.

I would also name the checks concretely. “Run tests” leaves room to run a convenient subset and call the task complete. “Run the repository build and the payment test suite; report any suite that could not run” makes the gap visible. If a check is slow or unavailable, the workflow should say whether the agent may continue with implementation and then stop before claiming completion.

Require evidence, not confidence

The final response should let me review what happened without trusting the agent’s summary alone. I would ask for the changed areas, the exact checks run, their outcomes, and any checks skipped. For a migration, I would also ask for a search result or equivalent evidence that the old interface is no longer used in the agreed scope.

That evidence is useful even when every check passes. It gives a reviewer a trail from the stated acceptance conditions to the proposed change. It also exposes mismatches: perhaps the agent edited generated files, skipped an integration suite, or interpreted “in scope” more broadly than I did. Those are review questions, not details to bury under “done.”

A passing test suite is evidence about the tests that ran. It is not proof that every requirement was met. I would phrase the agent’s completion condition accordingly: report success only when each required check has a recorded outcome and each requested piece of evidence is present. If a check fails, the agent can investigate within the agreed scope, but it must report the failure rather than silently weaken the acceptance bar.

This is also where parallel work needs a clear coordinator. Independent agents can inspect separate areas, but their results still need to be reconciled against one scope and one set of acceptance conditions. If two agents make incompatible assumptions, the coordinator should surface the conflict. It should not resolve a product or architecture decision merely to keep the task moving.

Make the stop points explicit

I would make the agent stop and ask for a human decision when it reaches a boundary that cannot be settled by repository evidence. Examples include a change to a public contract, a choice between competing behavior interpretations, a security-sensitive change outside the task’s stated design, or a need to expand scope. These are not failures of autonomy. They are the workflow working as intended.

Some stops can be automatic: a required check cannot run, the repository state is unexpected, or the planned change would touch an excluded area. Others require judgment. If a migration reveals two plausible replacement behaviors, the agent can explain the options and the consequences it found, but it should not choose one just because one is easier to implement.

I would state the stop behavior directly, rather than rely on a general instruction to “ask if unsure”:

If a stop condition is reached:
- do not make the decision by inference
- do not continue with a broader substitute task
- report the condition and the evidence that exposed it
- give the smallest set of options that need a human decision
- wait for direction before changing the affected behavior

This keeps a pause from becoming a vague handoff. The person reviewing can see what triggered it, what has already changed, and which decision would let work resume. The agent may be able to continue on independent, in-scope work, but only if doing so cannot hide or compound the unresolved decision.

Scale autonomy with verifiability

I would not use the same delegation for every repository task. A mechanical, well-bounded migration with reliable tests can support more autonomous execution than a change whose acceptance depends on product intent or operational risk. That is not a ranking of model capability. It is a judgment about how well the workflow can detect a wrong turn before it becomes an accepted change.

For repo-scale work, I want the agent to return a reviewable proposal, not to define success for itself. The workflow should encode the scope, required checks, evidence, and human decision points before execution begins. Then more capable agents can take on longer tasks without making review depend on confidence, or on a reviewer reconstructing what was never specified.