An assistant may request the same action more than once because a response was lost, a workflow resumed or a model chose to try again. The important question is not whether the prompt says do this once. Ask the agency how the application recognizes the same authorized business action across those attempts.
Related service: AI automation development- 01Identify the approved action
- 02Check its prior state
- 03Execute or return receipt
- 04Reconcile uncertainty
SECTION 01
Tie identity to the business proposal
Specify which fields define the action: user, target record, operation and approved payload version. An AI-generated identifier should not be the only barrier against duplication. The receiving tool or trusted orchestration layer needs to remember whether the action is pending, completed, rejected or awaiting reconciliation.
Microsoft's retry guidance explains why repeating a non-idempotent operation can have side effects. For an agent, the risk includes model-level retries as well as network retries. Ask the agency to distinguish regenerating an answer, retrying a lookup and executing a write. These paths should not all share the same retry behavior.
SECTION 02
Illustrative example: creating a maintenance request
An employee approves an assistant's proposal to create a maintenance request for a broken projector. The destination creates the record, but its reply is lost. The assistant sees no confirmation and proposes calling the tool again. Without stable action identity, the facilities team may receive two separate requests.
The application checks the approved action's receipt or reconciles it with the destination. It returns the original request reference when found. If the employee later reports a different projector, that is a new intent and receives its own identity. The example is about action control, not a claim that every external system supplies identical duplicate-protection features.
SECTION 03
Ask for a failure demonstration
During acceptance, interrupt the connection after the destination accepts a write, resume a suspended conversation and replay the same approved call concurrently. Verify the actual destination records rather than trusting the chat summary. If the external API cannot support safe replay, require a pending-review state instead of endless automatic retries.
OWASP's excessive-agency guidance supports limiting what an assistant can do. Pair that limitation with action receipts containing the permitted target and result, without storing unnecessary sensitive data. Handoff should explain identity retention, payload changes, reconciliation ownership and how staff distinguish a retry from a consciously approved second action.
SECTION 04
Frequently asked questions
Is telling the model not to repeat enough?
No. Duplicate prevention belongs in deterministic execution controls because retries and lost responses can occur outside the model's reasoning.
Should every repeated sentence be blocked?
No. Two similar sentences may represent separate legitimate requests. Match the approved business intent and payload, not wording alone.
What if the tool's outcome cannot be checked?
Expose the uncertainty and route it for reconciliation. Do not claim success or safely repeat a consequential action without evidence.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Retry patternMicrosoft Learn
- Excessive agencyOWASP
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy