When AI follows the rule and the customer still waits

Imagine a customer returning a purchase. The carrier marks the parcel delivered. The warehouse has a backlog and has not recorded or inspected it. Under the refund policy, money cannot be returned until the warehouse confirms receipt and inspection.

An AI assistant checks the record and holds the refund. It has followed the rule. The customer can see the delivery scan and is still waiting.

This is a hypothetical case. A delivery scan does not prove what is inside the parcel or whether the return qualifies. The inspection rule may be sound. The problem is that a correct stop has left someone with a decision to make, and the agent's answer alone cannot make it.

The previous issue (opens in a new tab) followed a policy into an individual action. This one follows the result back into the work: who receives an unresolved case, and what can they actually decide?

Give the next person the whole case

“Refund blocked” tells a support colleague very little. The shared return record should bring together the carrier's delivery evidence, the missing warehouse confirmation, the customer's wait and the condition that stopped the refund. Otherwise, each contact can become another search through messages and systems, ending with the same incomplete answer.

The record also needs a destination. A returns manager, for example, may have authority to review exceptions. The assistant can assemble the evidence and explain why it stopped. The manager decides what the evidence permits.

If the parcel is sitting in an intake queue, the useful intervention may be to get it inspected. If other checks are sufficient under the manager's authority, they may approve an exception for this return. They may also decide that the remaining uncertainty requires waiting. The customer's frustration matters, but it is not automatic permission to issue a refund.

What the announcements show

Several product announcements from this reporting week describe pieces of the supporting infrastructure. They are vendor accounts, not evidence that any of these products resolves the hypothetical return.

The AWS account of Postman's Agent Mode (opens in a new tab), published October 9, describes selecting relevant tools and context, with user approval before actions change application state. Atlassian's October 6 MCP announcement (opens in a new tab) describes tools separated into risk tiers so clients can require confirmation for higher-risk steps. That safeguard is configurable; the announcement does not establish that every client enforces it.

Atlassian's October 7 software-development announcement (opens in a new tab) describes agent progress returning to a Jira work item. ServiceNow's October 6 AI Workflow Factory announcement (opens in a new tab) describes workflows being built, run and refined while people set direction and approve outcomes.

The common design question is where a controlled action becomes visible to the colleagues responsible for what happens next. An approval step helps, but the work record must also show the unresolved condition and the eventual outcome.

Keep the exception and the outcome distinct

Suppose the returns manager approves an early refund after reviewing this customer's evidence. The record should preserve that exception, its reason and its limits. It applies to this return; it does not quietly rewrite the policy for the next one.

Approval also does not mean payment has happened. The return should remain pending until the payment system confirms the refund, then retain the transaction reference. The support colleague answering the next customer message needs to know what actually occurred.

Over time, the records may reveal a pattern. Are customers waiting because parcels sit in an intake queue? Does warehouse confirmation arrive too late to be useful? Are managers repeatedly finding another kind of evidence sufficient for a defined kind of return?

Each explanation calls for a different response. Fixing intake addresses an operational delay. Defining a bounded alternative for some returns changes the policy. Keeping inspection may be right where other evidence cannot resolve the risk. The policy owner needs the context to make that judgment; one delayed parcel, or a bare count of exceptions, cannot make it for them.

An agent workflow therefore needs more than a stop condition. In this example, the shared return record must reach the support colleague, the manager who can decide the case and the owner who can review the rule. Who receives the cases where your agent followed the rule and the work is still unfinished?

Correction · October 12, 2026: The original edition overstated Atlassian's confirmation safeguard. Its announcement describes risk tiers that let clients require confirmation; it does not establish confirmation for every higher-risk action. The October 12 revision also developed the argument through a hypothetical example.