Key facts.
- MCPTox shows tool calls can fail or be subverted through tool-description poisoning, so an agent that retries without idempotency can duplicate or corrupt an action.source
- Carlini's work illustrates the cost of treating systems rigor as optional, the same gap that leaving out transactional semantics creates.source
Why do agents leave inconsistent state?
Tool calls fail and get poisoned, per MCPTox, so a non-idempotent retry double-ships; a more capable agent repeats the side effect just as reliably. (arXiv:2508.14925)
An agent performs a sequence of side-effecting actions: charge the card, reserve the inventory, send the confirmation. If the run is interrupted or a step times out and retries, the world ends up in a state nobody planned for. Card charged, inventory not reserved. Confirmation sent twice. Agents are especially prone to this. They retry on failure. And their tools can fail or be subverted, MCPTox shows how. A single intended action becomes a duplicated or corrupted one. The agent that looks like it's recovering is sometimes making the inconsistency worse.
The fixes are the ones databases and payment systems settled decades ago. Make individual actions idempotent: performing one twice has the same effect as once. Retries are safe. Group related actions with transactional semantics: either all take effect or none do. No half-changed state. Where a true transaction across external systems isn't possible, use compensating actions to undo partial work on failure. None of this is novel. It's standard consistency engineering that agent architectures skip. Carlini is a reminder of what that costs. An agent built with idempotency and transactional thinking fails cleanly. One without leaves a mess someone reconciles by hand.
What keeps outcomes consistent?
| Property | Without it | With it |
|---|---|---|
| Idempotency | Retry duplicates the effect | Retry is safe |
| Transaction grouping | Half the steps take effect | All or none |
| On failure | Inconsistent state | Compensating rollback |
| Recovery | Manual reconciliation | Clean and automatic |
Knowing which actions are side-effecting and must be made idempotent or grouped is a pattern-level judgment the Pattern Intelligence Layer supports. VibeModel makes the agent's consequential actions explicit, so idempotency and transactional grouping are applied exactly to the actions that change the world and an interrupted or retried run leaves a consistent state instead of the half-finished mess that blind retries produce.
Frequently asked questions
Why is idempotency the foundation?
Because agents retry on failure and without idempotency a retry repeats the side effect, double-charging or double-shipping. Idempotency makes retry safe.
Can you always use a real transaction?
Not across external systems. Where you cannot, use compensating actions to undo partial work, so a failure does not leave a half-changed state.
Is this not just standard engineering?
It is and that is the point. Agent architectures routinely skip it, then pay in inconsistent outcomes that databases solved decades ago.