Loops and graphs can resolve the exact same support ticket, and the difference is not the outcome. It is who decides the path to get there. A loop starts with a human setting the goal, the policy, and the bar, then handing the whole thing over. From there the agent owns every step: draft a reply, check it against policy, fix the gaps, and ask itself whether the ticket is resolved. If not, it runs another pass through the same loop. If yes, it is done and sent. The agent picks every step inside one fixed frame, which is exactly why loops fit one-off work, the kind where you genuinely do not know the path yet and do not want to draw one in advance. A graph flips that. You draw the path first, as a state machine of nodes and checkpoints, and the agent fills each node instead of deciding what comes next. Read the ticket, check whether it is a known issue, apply a known fix or investigate a new one, draft the reply, run it through QA, and if QA fails, loop back to redraft instead of moving forward. A review step checks it again, sends it if it passes, or sends it back to fix if it does not. This is built for recurring work, a support pipeline that runs the same shape every time, where checkpoints matter more than flexibility. Both sit on the same company brain underneath: past tickets, policy, product docs, all the context that moves through every node, whether the structure on top is a loop or a graph. The brain does not care which execution model is running it. Use a loop when you do not know the path yet and need the agent to figure it out inside a frame. Use a graph when you already know the path and need the agent to execute it reliably, the same way, every single time. Bookmark this before you build a rigid graph for a job you have never actually done once.