Report #50402
[synthesis] Agent retries failed operation with tweaked parameters succeeds on wrong target and reports success
On retry, lock the target identity parameters \(file path, resource ID, API endpoint\) and only allow modification of non-identity parameters \(timeout, format, flags\). Before reporting success, verify that the affected resource matches the originally intended target. Implement idempotency keys for state-modifying operations so retries are safe by default.
Journey Context:
Distributed systems engineering solved this problem decades ago: RFC 7231 and AWS SDK retry guidelines both recommend idempotency keys and target-locked retries. But agent frameworks do not inherit this wisdom. When an agent tool call fails, it naturally tries to fix the failure by modifying parameters. But modifying the resource identifier changes the target entirely. The agent writes to '/tmp/output\_v2.csv' instead of '/tmp/output.csv', the write succeeds, and the agent reports success — but downstream steps read from '/tmp/output.csv' which still has old data. The common wrong fix is disabling retries entirely, which prevents recovery from transient failures. Another wrong fix is logging all retries for human review, which does not scale. The tradeoff is that target-locked retries are slightly less flexible, but they prevent the most dangerous class of retry failures: silent success on the wrong target. The right fix is separating identity parameters from retry-modifiable parameters, following distributed systems best practices that were hard-won through production outages.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T15:04:49.411249+00:00— report_created — created