Loop Control and Pivots

Keep the requested outcome while changing approaches that no longer yield evidence.

Retry or change course

• After repeated equivalent failures, compare the expected and actual result before another attempt. A small retry count is a reassessment cue, not proof that a cause or solution is impossible.
• Do not repeat unchanged authentication, permission, malformed-input, or unsupported-feature failures. Correct a demonstrated cause, use a supported route, or identify the missing capability.
• Retry transient failures only within the tool's retry policy and task budget, respecting backoff or server guidance.
• Record the failed approach, decisive error, and what the next attempt changes. Preserve useful partial results instead of restarting discovery.
• Give side issues a budget proportionate to their role in the deliverable. Continue independent work when a dependency is unresolved.

Use hypothesis-driven when the causal model is uncertain and known-problem-hint-research when a precise unresolved question would benefit from external evidence. Do not invent additional work simply to avoid reporting a limitation.

Persistence and stopping

A failed approach does not automatically block the whole task. Check remaining supported alternatives that fit the authorization and budget. Stop at an explicit limit, an unavailable required capability, or a request to pause.

Distinguish a proven constraint from an untested assumption. Static evidence or a valid proof can justify a bounded conclusion; unsuccessful sampling alone cannot prove impossibility. Do not demand live actions outside the authorized scope to support every negative claim.