The retry sends the email twice: what agent framework comparisons leave out

The mechanism worth arguing about sits in one line of the pre-ship checklist: derive the idempotency key from the business fact, not from a run ID that changes on retry ^[4]. A run ID identifies the attempt. The business fact identifies the thing you promised to do exactly once. If the key moves when the process restarts, the external system cannot recognise the second call as the same intent, and durable execution will faithfully rebuild the orchestration state that led up to a send it has no power to cancel ^[7].

The rest of the checklist follows from that. Persist planned, in-progress, succeeded and failed as explicit status, separate from the model's opinion about what happened ^[4]. Before retrying, check both local state and the external system, because the external system is the source of truth about whether an email left ^[4]. Where the action cannot be made idempotent at the boundary, put an outbox, a transaction log, or a compensating process behind it ^[4].

Not one of those four items is supplied by any of the four products. The comparison the piece builds ends with a residual column that is nearly identical across all four rows, and it is entirely about side effects and state ownership ^[1]. So framework choice subtracts zero obligations ^[18]. What it changes is the quality of the evidence you hold while you discharge them: LangGraph's explicit state tells you which node the run died in, while an unbounded AutoGen group chat tells you that a conversation happened ^[2]. LangGraph buys that legibility with graph and schema design work up front ^[13]; AutoGen only gives it to you if you imposed termination rules, bounded rounds and message schemas before the run ^[10].

The Flowise reading needs care in both directions. A Human Input node or a required tool approval pauses an Agentflow execution and writes a checkpoint, and the Agentflow V2 docs say the workflow can resume from it even after an application restart ^[15]. That makes the flat claim that Flowise only supports in-run state wrong ^[16], and it is a real difference from `$flow.state`, which is shared inside one execution and destroyed when that execution ends ^[14]. It is still a documented restart behaviour rather than a guarantee covering every recovery design you might need ^[16].

CrewAI's failure mode is quieter and worse. Roles, goals, tasks and processes read well to business stakeholders, which has genuine value, but a role description is not a transaction boundary and not a security control ^[11]. Three agents with different backstories, the same model, the same context and the same evidence are not three independent checks; the reviewer will confirm the writer's mistake ^[12]. Teams who count that reviewer as a safety gate in front of a payment call have bought a second opinion from the same opinion.

Which is the actual dividing line. Orchestration state lives inside the framework. Business state does not ^[3]. Every ranked list of these four products measures the first and stays silent about the second, and it is the second one that owes the customer an apology for the duplicate onboarding email ^[5].