Long-Running Agents Create Long-Lived Mistakes
The following timeline reconstructs a production failure pattern that becomes possible when an AI agent can pause, retain state, and resume hours later.
Task: Process an approved customer refund
Runtime: 2 hours, 58 minutes
Failure: The agent completed an action that was no longer valid
9:05 AM: The Decision Was Correct
The agent opened order #4821 and collected three facts:
- The order had been delivered.
- Refund Policy v17 allowed a full refund.
- The calculated amount was $129.
It generated a recommendation and sent it to a support manager for approval.
At this moment, the agent’s reasoning was correct. Its retrieved evidence matched the order, its calculation was accurate, and the requested action was permitted.
9:12 AM: A Human Approved the Refund
The manager approved the recommendation.
The workflow stored a checkpoint containing the order details, policy version, refund amount, and approval. The agent then moved to the payment stage.
The approval appeared to settle the decision. In reality, it only confirmed that the action was valid at 9:12.
9:22 AM: The Business State Changed
A fraud-monitoring rule detected that the card had also been used on another disputed order.
A human analyst moved order #4821 into fraud review. Refunds for orders in this state were supposed to stop until the investigation finished.
The database now contained a different truth.
The agent did not see it because it had already completed the decision stage.
10:04 AM: The Workflow Paused
The payment service became unavailable. After several failed attempts, the workflow saved its progress and waited.
Get Ravi Mansuriya’s stories in your inbox
Join Medium for free to get updates from this writer.
This kind of pause is becoming normal. OpenAI’s Agents API, for example, is designed for workflows that can continue across hours or days, save intermediate results, use tools, and compact context across multiple windows.
The engineering challenge is no longer only whether an agent can resume.
It is whether its earlier assumptions should resume with it.
11:48 AM: Old Context Became a New Action
The payment service recovered.
The agent loaded its checkpoint:
Refund approved. Amount: $129. Next action: issue refund.
That summary was accurate but incomplete. It preserved the decision while omitting the conditions that made the decision valid.
The agent did not reread the order. It did not confirm that Policy v17 still applied. It did not check whether the approval remained valid after the status change.
The refund was issued successfully.
12:03 PM: Everything Worked Except the Workflow
The model had not hallucinated. The payment API had not malfunctioned. The approval record was genuine.
The failure existed between those components.
The order’s data clock had moved forward. The approval belonged to an earlier authorization state. The checkpoint had compressed away an important condition. The retry mechanism treated resumption as continuation rather than a new decision.
OWASP describes persistent agent memory as both a capability and an attack surface. NIST is also examining how agent permissions should change when context, tools, and delegated authority change.
12:27 PM: The Team Changed One Boundary
The team did not rewrite the prompt.
Instead, it added a rule before every irreversible action:
Reread the current business state and prove that the original evidence, approval, and intended action still match.
Approvals received expiration times. Checkpoints stored source versions. Payment calls received idempotency keys. A changed order status forced the agent to abandon its earlier plan.
For teams assessing an AI chatbot development company, this is a more revealing question than asking which model it uses:
What must the agent revalidate after it resumes?
The agent had not forgotten its plan.
That was the problem. It remembered the decision longer than the decision remained valid.
