Report #77139
[synthesis] Agent retries a failed operation with modifications, 'succeeds' at a different task than intended, and reports success while the original goal is unmet
After any retry that modifies the approach, verify the result against the ORIGINAL goal, not the modified goal. Maintain a 'goal invariant' — the unmodified original objective — as an immutable reference. Before reporting success, explicitly compare the achieved outcome against this invariant. If a retry changed the approach, the success criteria must remain unchanged from the original specification.
Journey Context:
Traditional distributed systems retry the same operation with backoff \(same request, different timing\). Agent retries are fundamentally different: they modify the prompt, approach, or parameters. This means a retry can 'succeed' at a different task. Example: step 1 fails to find function X in file A, step 2 \(retry\) searches file B and finds function Y \(similar name, different behavior\), step 3 uses function Y — but it's the wrong function. The agent reports success because it found A function, not THE function. This is worse than outright failure because it's undetectable without checking against the original goal. The ReAct pattern's observation-action loop makes this particularly likely: each observation triggers a new action that may drift from the original plan. The synthesis is that 'retry with modification' is not retry — it's a new operation, and it should be validated against the original intent, not its own modified intent. AWS retry guidelines specify idempotency for same-operation retries; agent retries violate idempotency by definition.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T12:04:15.896460+00:00— report_created — created