Claude Operator: Prompt to Autonomy · 20 min · 140 XP

Stopping conditions, budgets, and failure

Tell a worker when to stop, cap what it may spend, and make blocked reports useful.

A worker without a stopping condition keeps going. Not maliciously — it was asked to find something and it hasn't found it, so it looks harder, broadens the search, and burns your budget on a file that isn't there. Every delegation needs three sentences: when to stop, what not to attempt, and what to report if blocked.

A brief with an exit

Find where rate limiting is implemented.

Stop when: you've found it, or you've checked the middleware,
config and routing layers without finding it.
Do not: modify files, or search node_modules.
If blocked: report what you checked, what you found instead,
and the single next place you'd look.

"If blocked, report what you checked" converts a failure into information. The difference between a useless blocked report and a useful one is whether it lists the ground already covered — the useful one means you don't repeat it, and often tells you the thing genuinely isn't there, which was a real answer to the question.

Budget the fan-out too. Cap the number of workers and turns for an investigation before you start, and afterwards compare what you got to what it cost. Subagent spend counts toward a run's cost cap, so a parallel investigation is a multiplier in both directions. Some questions are worth three agents; most are worth one, and a habit of spawning a team for everything is expensive in a way that's easy not to notice.

Finally, keep review and integration separate. Have one specialist review a proposed patch against the diff, and let a single owner decide what lands. A reviewer that can also merge its own suggestions isn't a review step; it's a second author.

Practice. Write a delegation with an explicit stopping condition, an exclusion and a blocked-report format, and confirm the worker stops at the boundary. Cap the workers and turns for one practice investigation and compare cost to value afterwards. Simulate a missing dependency or denied permission and check the blocked report tells you what was attempted. Then have one specialist review a patch while you alone decide whether to integrate it. Finish by defining researcher, tester and reviewer roles for one bounded feature, with an order they run in.

Loading your workspace…