Test Claude dynamic workflows with planted bugs in your repo

You are deciding whether Claude dynamic workflows should hunt bugs in your repo. Anthropic's launch test planted 70 bugs in a 116k-line codebase. Across three runs, one agent found 14, 15, and 27 bugs. Each of three workflow runs found 66 bugs.

Anthropic made dynamic workflows for Claude Managed Agents available in public beta on October 9, 2026. Those numbers should not decide for you. Run a small planted-bug benchmark on your own codebase, then set a session budget before you enable the workflow. Use the benchmark to find out whether the runtime is worth it on your code, not to prove the workflow is smart.

Run a five-step planted-defect benchmark

Keep the defects realistic. A bug that only appears under load is harder to score than a bug that shows up in a unit test. A defect that hides behind a feature flag is harder still. Do not aim for a perfect test. Aim for one you can rerun after a refactor.

• Pick a repo and a branch that is close enough to your real workload to matter. Record the prompt, branch, and time window so the benchmark can be rerun after a refactor.
• Plant a known number of defects. Add a small set of realistic bugs and record each one in a defect sheet. Done: a list you can score without guessing.
• Run matched single-agent and workflow passes. Give the single agent the same prompt, repo state, and time window. Start the workflow on the same branch and let it use its own phases. Finish with two find lists that name file, line, and severity.
• Compare full finds and misses. Mark each planted defect as found, missed, or false positive. The output should be a table where the workflow's advantage is visible, not implied.
• Set a session budget and a run-lifetime guardrail. Choose a token spend cap for the test and a lifetime cap for the run. The result should be a guardrail that stops the run before it becomes a surprise invoice.

The trap is assuming you can steer the run after launch. Once the run is live, its threads do not accept follow-up messages from the agent. Write the first message with the test scope, the defect sheet, and the stop condition. Extra hints to the single-agent pass turn the comparison into a prompting test.

A workflow run may launch as many as 1,000 agents during its life, with up to 64 active at once. The default run lifetime is 24 hours, and one session can hold 10 open runs. On a large monorepo, those multi-agent limits matter more than the prompt.

Price the run before you trust the run

The pricing model is easy to budget. A workflow run has no separate fee. Token use from the agents is charged at model pricing, and Managed Agents adds a session-runtime charge of $0.08 per session-hour. The spend to fear is a long-running session that keeps consuming runtime while agents work.

Before the run starts, write down what a useful result looks like. A higher find count is a signal. The same finds with more runtime need a different threshold. Obvious misses call for prompt inspection before model blame.

If the session budget is hit, an active workflow run pauses and goes idle. Increasing or deleting the budget can resume it, unless an interrupt also paused it. For a benchmark, that is useful. You can stop, inspect the partial find list, and decide whether the workflow earned the cost.

Keep the benchmark small enough to finish in a short review. A long test that nobody reviews is worse than a short test that changes a decision. Rerun it when the codebase changes shape, because a workflow that wins on a small service may lose on a large backend.

Enable workflow bug-finding in production only after your own benchmark reliably beats the single-agent baseline on your repository, your dependencies, and your budget.