The costliest mistake an AI agent can make is not "didn't do it" but "did it twice". A write through an API has three outcomes: succeeded, refused and unknown, and retrying an unknown outcome creates double payments, orders and receipts. Here is how Samreshuuu handles it with one rule for every integration, how it checks writes in YooKassa, MoySklad and Ozon, and six questions to ask an AI agent vendor.

The costliest mistake an AI agent can make is not "didn't do it" but "did it twice". The agent takes a payment, creates a purchase order or posts a supply receipt, the request goes out, and no answer comes back: the network blinked, the service stalled, the connection dropped. At that moment nobody knows whether the write went through, neither the agent nor you. An agent that repeats the request just in case leaves you with two payments or two receipts. An agent that says "it failed" leaves a gap if the write actually went through. Below: why a write through an API has three outcomes rather than two, how an AI agent for business should behave in the third one, with examples from payments, inventory and a marketplace, and what to ask a vendor before trusting an agent with your money and accounts.

AI solves olympiad problems, yet happily creates a duplicate

Models today write code, review contracts and crack problems mathematicians spend years on. On the Latent Space podcast, TypeSafe AI founder Diogo Almeida put it as a paradox: how can AI be smart enough to take on millennium-prize problems and still fail to automate the most basic work?

Part of the answer is that basic work does not happen in a chat. It happens inside other people's systems: a marketplace seller account, accounting software, a bank, a CRM. There, a model's intelligence gets no credit for "roughly right". There is either one payment or two. Browserbase, writing about the new Jev model, says it precisely: an output can be compelling to a person without being reliable enough for unattended automation. An engineer at Raindrop put it even shorter: the real environment agents need is the one you deploy them to. Not a demo, but your account with its timeouts, permissions and failures.

Business automation with AI hinges not on how smart the model is, but on what it does when something goes wrong.

A write has three outcomes, not two

When an agent reads data (stock, orders, a bank statement, reviews), a failure is harmless: it didn't work, read again. When an agent writes (takes a payment, creates an order or a receipt, changes a price), things get harder. Such a request has three outcomes.

Outcome	What happened	What to do
Write succeeded	The service replied "created" and returned the result	Read it back and compare it with the request
Write refused	The service replied with a refusal: no permission, invalid data	Read the reason and either fix the request or say plainly what is in the way
Outcome unknown	The request went out, no answer came back: timeout, dropped connection, server-side error	Find out what happened first, and only then decide whether to repeat

The third outcome is the most dangerous because it looks like the second. For a simple automation, "no answer" and "error" are the same thing: the scenario fails or repeats the step. But a request that got no answer may well have reached the service and been carried out. The service took the payment; the answer got lost on the way back.

The HTTP standard says so directly: a request whose repetition creates a new record must not be retried automatically unless there is a way to know the first one did not take effect.

Why "just retry" creates duplicates

Picture this: the agent issues an invoice to a customer or creates a purchase order with 40 line items. The request went out, 30 seconds passed, no answer. What happens next depends on how the agent is built.

Retry immediately. If the first write went through after all, you now have two. The customer gets a second invoice, the supplier a double order, and somebody has to find and cancel the duplicate by hand.

Say "it failed". If the write went through, you don't know about it. Ask the agent again and you get the same duplicate, this time by your own hand.

Say "done". The worst option. The agent never saw an answer but reported success anyway. In its piece on testing AI workflows, n8n describes exactly this kind of failure: a response can sound convincing while getting an important detail wrong.

The right move is a fourth one: admit the outcome is unknown, and check.

One rule for every integration

Samreshuuu has more than a hundred integrations: marketplaces, inventory systems, banks, CRMs, 1C, email, messengers. Every call the agent makes goes through one layer, and the question "may a request that got no answer be sent again" is answered there, not by the model and not by an individual scenario. The answer is the same for all of them.

Reads may always be repeated. They change nothing.
Writes that replace a value may be repeated. Setting a price to 990 twice still leaves it at 990.
Writes that create something new may be repeated only if the service itself promises protection against duplicates. That promise is recorded explicitly for the integration, per operation, and the layer does not trust a header somebody made up.
Everything else the layer does not repeat on its own. The agent gets a note saying "the outcome is unknown; check its state before repeating the write", and acts on it.

On top of that sits one more safeguard of our own. Every write the agent makes carries its own key, and if the same call with the same key arrives again within five minutes, it does not go to the service a second time: the agent gets the stored answer of the first one.

Here is how this looks in the three most sensitive areas.

Payments: a key that stops you paying twice

Payment services usually have duplicate protection built in. YooKassa calls it an idempotency key: the request carries a unique tag, and if YooKassa receives a second request with the same tag, it does not take a new payment but returns the result of the first. Stripe works the same way.

The subtlety is who sets the tag. Ask a model to "make up a unique ID" and on a retry it will make up a new one, which removes the protection. So in our case the tag is set by code: one key per operation, carried by every attempt of that operation. The network drops, the request goes out again, YooKassa sees a familiar key and returns the same payment.

For specific operations at T-Bank and Modulbank the same promise is recorded in the integration's description, and the retry layer honors it.

Inventory: how the agent checks itself in MoySklad

MoySklad has a similar mechanism, the syncId field. When the service receives a repeated create request with a tag that is already taken, it does not create a second document; it returns the first one.

Here is how the agent uses it when it creates an order, a receipt or a write-off:

The tag is set by code, not by the model, for the same reason as with payments.
A lost answer is not a refusal. If no answer came back, the agent does not report an error; it looks the document up by its tag.
Found it: the write went through. The agent returns the document it found and carries on.
Didn't find it: the outcome is still unknown. The service may not have accepted the write, or may not have finished it yet. The agent says neither "created" nor "not created", and it knows the only safe retry: the same request with the same tag.
A new draft is a duplicate. Building the document again means a new tag. The agent does not do that on a retry.

For bulk edits the rule is the same but the mechanics differ. The agent reads updates back by document ID and resends only what did not apply, in smaller batches. Created records it looks up first, and only then decides what to send again.

And even when a write succeeds on the first try, the agent reads the document back and compares line items, quantities and references with what you asked for. A document created wrong is a failed write, not a success, and the agent names the field that doesn't match.

Marketplace: "success" is not the final word

Ozon has discount requests: a buyer asks for a lower price, the seller approves or declines. When the agent approves a batch of requests, Ozon replies "success", but that does not yet mean everything was recorded as sent: the price Ozon finally approved may differ from the one submitted.

So the agent does not take the answer at its word. After the write it reads the affected requests back and shows what actually stands in the account. If fewer requests come back than were reported "successful", the agent searches wider instead of treating the write as confirmed.

It is the same idea as with inventory, seen from the other side: you check not only an answer that got lost, but also one that arrived.

A permission refusal is not a dead end

Another common situation: the service did answer, but with a refusal. What matters here is what exactly it refused.

In MoySklad, document permissions are split: "create" and "post" are separate checkboxes in a role. A posted receipt changes stock immediately; an unposted one sits as a draft. If the key can create but not post, MoySklad replies with error code 1092. Its meaning is narrow: the document cannot be posted. It can still be created.

Until recently the agent read that refusal broadly as "no access" and dropped the task. Now, on code 1092, it repeats the request marked "do not post" (applicable=false), creates a draft and tells you plainly: the receipt is created, you need to post it, and here is where.

Where a permission cannot be granted, the agent does not send you off to grant it. An app installed from the MoySklad app marketplace has no posting permission at all: its permission set is defined by the app's descriptor, and neither an administrator nor the user can extend it. "Ask your administrator for access" in that case means a second support ticket instead of a result. The honest outcome is a draft and one "Post" button that you press.

The difference between "it failed" and "I made a draft, you just need to post it" is the difference between a task you redo from scratch and a task that takes you five seconds.

The robot vacuum and the cables

Zapier's new developer survey has a good metaphor. A robot vacuum really will clean your floors while you relax, right after you spend 15 minutes moving chair legs and coiling phone chargers so it doesn't eat them. An AI agent is the same. Lost answers, permission refusals, half-applied batches and a "success" hiding a different price are the cables. A good agent doesn't pretend they aren't there; it knows how to handle them.

Tellingly, in the same survey the five skills developers rank as most future-proof all come down to one job: deciding whether something is safe, correct and worth shipping. That is the main question to ask of an AI agent too.

Questions for an AI agent vendor

Before connecting an agent to your payments, inventory, orders or prices, ask:

Question	Good answer	Red flag
What does the agent do if a write gets no answer?	Treats the outcome as unknown, checks whether it was recorded, and only then decides	"It retries" or "it reports an error"
How does the agent avoid duplicates on a retry?	A tag on the request, set by code; the retry reuses it	"The model makes sure there are no duplicates"
Does each scenario decide this on its own, or is there a shared rule?	A shared rule for every integration, plus checks where a service has its own mechanisms	"It depends on the integration", with no details
Does the agent check the result after writing?	Reads it back and compares it with the request	"The service said 'success', so everything's fine"
What if the agent lacks a permission?	Does what it can, such as a draft, and tells you what is left for you	"It reports that access is denied"
What does the agent say when it doesn't know how a write ended?	Says exactly that: the outcome is unknown, here is how to check	Reports "done"

You can test this by hand: ask the agent to create a test document, then ask what it would do if no answer came back. An agent that replies "I'll try again" has answered the key question.

In short

An AI agent's worst mistakes happen not in the chat but on writes, which have three outcomes: succeeded, refused and unknown. The third is the most dangerous because it looks like an error.
"Just retry" on an unknown outcome creates duplicates: double payments, orders and receipts.
The right move is to check. Payment services and MoySklad offer a tag on the request for this: a retry with the same tag returns what was already created instead of a second one.
A "success" is worth reading back too: on Ozon the approved price may differ from the one sent.
Read permission refusals narrowly: no right to post does not mean no right to create. A draft beats nothing.
Ask a vendor not "what can the agent do" but "what does it do when something goes wrong".

What AI agents for business are and how they differ from chatbots is covered in what an AI agent is. How the agent works with specific systems is in the guides to MoySklad and Ozon, and an overview of AI for marketplace sellers is in our roundup of seller tools. How an agent differs from Make, Zapier and n8n scenarios is in AI agent vs. automation builders.

AI agent mistakes: what happens when it gets no answer from a marketplace, inventory system or bank