The agent failed halfway: how to retry without paying or acting twice

ai-agentsidempotencyreliability

Published 2026-10-22

Author: Talomnia team

An AI agent timed out after sending an email or a payment. Why a blind retry does it twice and what to ask a vendor about retries.

When an agent fails halfway, the dangerous case is an action that already happened while its confirmation was lost. A blind retry then sends the email or payment twice. A safe retry reuses one saved key for that exact action and checks the outside system first. A changed amount, recipient or text is a new action and needs new approval.

Below: what "failed" really means, public reports of retries gone wrong, the plain fix, and what vendors say about paying for failed runs. Everything was checked on 22 October 2026.

What does "the agent failed" actually mean?

"It failed" covers three different situations, and only one of them is harmless.

It failed before acting. Nothing left the system. A retry is safe.
It acted, then failed. The email went out or the payment was taken, but the agent crashed or timed out before it recorded the result. A retry repeats the action.
Nobody knows. The request was sent, the answer never came back. The action may or may not have happened.

A GitHub issue on the last9 MCP server, opened on 16 October 2026, puts it in one line: "A write that times out or fails in transport may still have been applied upstream." The maintainers closed it on 18 October after merging a fix. The lesson stands for any agent that writes to another system: an error message does not prove that nothing happened.

How one retry becomes two emails, two payments, two comments

There are no statistics on how often this happens. What exists are single public reports, and they show the same pattern again and again.

Payments, in a test. In an Upsonic issue opened on 4 October 2026, a developer ran a local fake ledger (nothing left 127.0.0.1). With a documented retry setting of three, the agent "paid three times for one requested payment", because "the tool cannot tell a repeat from a new call". One report, a local reproduction, no real money.
Comments on GitHub. A verdity issue from 23 September 2026 describes an error raised after a GitHub post had already gone out, so a retry "re-posts a duplicate comment/review".
Chat replies. An OpenClaw issue from 21 October 2026: after a reasoning-only retry, the agent treats a reply that was already delivered as missing and "resends it verbatim on the next turn". A duplicate chat message, not an email or a payment, but the same mechanism.
Charges, as a described gap. An open issue in Stripe's own AI toolkit repository, opened on 3 May 2026 and updated on 8 October, is titled "Agent-level retry creates duplicate charges — no idempotency guard above the tool layer". It describes a scenario the tooling does not yet cover; it is not a report of a confirmed customer double charge.

Each of these is one public report. Together they show why "just run it again" is the wrong default for an agent that touches the outside world.

The fix in plain words: one key per action

The engineering term is idempotency. In plain words: doing the same request twice has the same effect as doing it once.

The working pattern is simple. Before the first attempt, the agent saves one identifier for the action it intends to take: this run, this step, this email. It sends that identifier with every attempt. The receiving system sees the same identifier again and knows it is a repeat, not a new request.

An email-API vendor, SentFromAI, describes it in a blog post from 6 October 2026: "persist one identifier for each intended send, reuse it on every API retry, and keep the approved recipients and body unchanged." And: "A retry should repeat the same action, not ask the model to invent a new one." The same page is honest about the limit: "That is a send-request contract, not a guarantee that every workflow step runs once or that a person receives and reads the email."

Payment APIs have worked this way for years. Stripe's documentation describes idempotency keys of up to 255 characters, and notes that for API v1 keys can be removed automatically once they are at least 24 hours old; a request with a removed key is treated as new. So timing matters too: a retry a day later may no longer be recognised as a repeat.

The point for a buyer: the key belongs to the intended action, not to each attempt. If the agent makes a new key every time it retries, the key protects nothing.

Check before you repeat, and ask again if the payload changed

A key helps only when the other system supports it. The second safeguard is to look before retrying: was the email sent, was the payment taken, does the comment already exist?

The last9 issue title says it directly: "never retry after ambiguous failures; tell the agent how to check". An agent that cannot check should stop and report, not guess.

The second rule is about changes. A practical guide on technologyonthe.net (2 October 2026; a blog guide, not a vendor specification) says that a request reusing the same key with different arguments should be refused: "Do not silently run the new payload." If the amount, the recipient or the text changed between attempts, the "retry" is a different action.

This links to approvals. If you approved a hypothetical payment — for example, "pay 400 euros to this supplier" — that yes covers that exact payment. A retry with another amount or another account is a new action and needs a new yes. We covered which actions an agent should always bring to a person in what an agent must ask a human.

Who pays for the failed run?

Vendors split on this. Each line below carries the date of the page it comes from; all were checked in October 2026.

Vendor	Failed or interrupted run	Who decides	Source date
Manus	Credits refunded for a verifiable bug or platform malfunction, including when the agent stops mid-task without a valid reason and fails to deliver any results; not for issues with user instructions, subjective satisfaction or inherent AI limits	An AI agent and the Customer Success team, after investigation	16.12.2025
Devin	Legacy enterprise prompt credits: an unsuccessful message does not consume credits; newer plans are billed differently	Not stated	Page modified 19.10.2026
Cursor	Runs stopped mid-flight are charged (2025 staff post); runs resume from server-side checkpoints, with retries designed not to repeat completed work (2026 staff reply)	Not stated as a policy; staff suggest contacting support	22.10.2025; 23.07.2026

"Not stated" means we did not find it on the page we checked.

Manus refunds credits in full if "our investigation confirms" a verifiable bug or platform malfunction, including when the agent "stops mid-task without a valid reason" and "fails to deliver any results". Requests are reviewed by a "specialized AI agent" and the Customer Success team. There is no refund for problems with your own instructions, "subjective satisfaction with the outcome" or "the inherent limitations of AI". So a refund follows an investigation, not the request itself. If a bug is confirmed, the page says a credit refund is then processed automatically.

Devin's usage page, in its section on legacy enterprise prompt credits, says: "If a message is unsuccessful, prompt credits will not be consumed." The same page describes newer plans that are billed differently (usage-based self-serve plans introduced in March 2026, and enterprise ACU plans), so this line is not a rule for every Devin plan.

Cursor staff wrote on the forum in October 2025: "We believe it's fair to charge for runs that get stopped mid-flight." A later staff reply, from July 2026, says agent turns run against "server-side checkpoints" and the client resumes "with retries designed not to repeat completed work". Read the two together and with their dates.

Failed runs can also cost money after a usage-limit stop. In a Claude Code issue opened on 8 October 2026, one user reports background processes that kept running after a usage-limit stop: 59,235 API calls and roughly $2,000 of usage in 17 hours, 88% of it after the cutoff. It is a single report, still open, and the user asked for a refund of $2k. It is a good reason to ask what a limit stop, and the Stop control, actually stop. For setting a spending ceiling in the first place, see budget cap vs estimate.

Five questions to ask an agent vendor about retries

You don't need to read code to ask these. Good answers are concrete and written down.

If the agent sends an email or a payment and then fails before confirming, what happens on retry? How do you know the action already happened?
Does my approval cover the exact action (recipient, amount, text) or the whole run? If a retry changes anything, do you ask me again?
After a failure, do you resume from the last confirmed step or start over? Which steps do you treat as irreversible?
Who pays for a failed or interrupted run, and where is that written? Do failed runs count toward my spending cap?
If I press Stop or a limit is hit, do background processes stop too? Is there a cap on the number of calls?

If an answer is "it doesn't happen", ask how they would know. The reports above all started with a system that assumed it didn't.

To see how a job is set up and accepted on our side, read how Talomnia runs a job.

Sources

Questions

What happens if an AI agent fails after sending an email?

The email may already be delivered even though the agent saw an error. A safe agent checks the email service before retrying and reuses the same send ID. If the email API honours that ID, the retry returns the original send instead of creating a second one; that is a send-request contract, not a guarantee of one delivery.

What is an idempotency key, in plain words?

A label saved for one intended action and sent with every attempt, so the receiving system knows a repeat is the same request and does it only once. Payment APIs such as Stripe support them.

Do AI agent vendors charge for failed runs?

It varies (checked October 2026). Manus's help article (16 December 2025) refunds credits when its investigation confirms a verifiable bug or platform malfunction; Devin's legacy enterprise credits docs say unsuccessful messages don't consume prompt credits; a Cursor staff post on 22 October 2025 said it believes charging for runs stopped mid-flight is fair, and a 23 July 2026 staff reply says runs resume without repeating completed work.

Should an agent ask again before retrying a payment?

If anything in the payment changed (amount, recipient), yes: the earlier approval covered the old action. If nothing changed, it should first check whether the payment already went through.