Retrying entire AI workflows on Gemini 500 errors causes duplicate side effects

Developers using Google's Gemini or Vertex AI APIs often respond to intermittent 500, 502, 503, or 429 errors by adding broad retry logic around their entire automation workflow. However, retrying the full workflow replays every side effect, leading to duplicate CRM updates, Slack alerts, Jira tickets, and inconsistent database states. The root cause is misplaced retry boundaries: the retry logic should wrap only the isolated model call, not the steps before or after it. Google's Gemini Python SDK already handles transient failures with exponential backoff by default, meaning raw HTTP clients or full-workflow retries are the more likely culprits. The recommended fix is to isolate the LLM call into a dedicated sub-workflow or worker, so that a transient model failure triggers only that step to retry while downstream writes execute exactly once.