The PRG Pattern for AI Agents
AI agents are running into an old problem. It is the same bug that broke web forms in the 90s.
In the old web days, a user would submit a form. If they hit refresh, the browser would resubmit the data. This meant two orders, two charges, or two emails.
The fix was the Post/Redirect/Get (PRG) pattern.
The logic is simple:
- The user sends a POST request.
- The server processes the work.
- The server sends a 302 Redirect to a new URL.
- The browser follows the redirect with a GET request.
A refresh now only reloads the result page. It does not repeat the action.
AI agents have brought this bug back to a new layer.
When an agent calls a tool to charge a card or create a record, things go wrong. A network drop happens. A container restarts. A rate limit kicks in. The agent does not know if the last call worked. So, it retries.
Without a fix, the agent creates duplicate orders and charges angry customers.
You must apply the PRG pattern to your agentic pipelines using idempotency keys.
The idempotency key is your redirect. It separates the action from the result.
How to implement it:
- Every mutating tool must accept an idempotency key.
- Generate the key before the first attempt.
- Derive the key from user intent, not a timestamp.
- The server must check if it saw the key before.
- If the key exists, return the stored result instead of running the task again.
For long tasks, you need more than just a key. You need checkpointing.
Checkpointing saves the state at every step. If the agent crashes halfway through a twenty-minute task, it picks up where it left off. It does not start over.
If you can only do one thing, make every tool call safe to run twice.
Build your agents with these five checks:
- Does every tool accept an idempotency key?
- Is the key based on intent rather than time?
- Is the key reused on every retry?
- Does the server return stored results for duplicate keys?
- Are intermediate steps saved for long tasks?
The pattern is the same. Only the layer has changed.