← All guides

October 27, 2026 · 8 min read

Late approvals, timeouts and “who said yes?”: the hard questions about AI agents taking actions

We asked people who build and run AI agents what is hardest about letting them act for customers. The same questions kept coming back: late approvals, timeouts, false successes, reviews nobody sees, and proving the customer agreed. Here are our answers, and what Allowfy does for each.

We asked a simple question in a community of people who build and run AI agents: when an agent takes real actions for a customer (cancelling an order, starting a return, moving a booking), what is the hardest part?

Nobody said "making the agent smarter". The answers were about the moments around the action: a yes that arrives too late, a call that times out, a success message that wasn't true, a review nobody sees, and a dispute where nobody can prove what the customer agreed to. Here are those questions, and how we answer them in Allowfy.

1. What happens when the customer's "yes" arrives late?

A late yes can be worse than no answer at all: the slot may have moved, the order may have shipped, the price may be different.

In Allowfy, every proposal has exact terms, a revision number and an expiry time:

  • The customer's approval is tied to one revision of the terms. If the terms changed, an approval of the old ones is refused (terms_changed), and a new approval is needed.
  • After the offer expires, it can't be confirmed at all. Nothing happens.
  • Before acting, Allowfy reads the current state again: the order must still exist, still belong to that customer, and still be cancellable or returnable. If the world moved on, the operation stops and says why.

2. When an approval times out, does it fail closed or go through?

Closed. An offer nobody confirmed expires, and nothing changes. You choose how long offers stay open (a few minutes for a booking, longer for a return), and the agent is told the exact expiry time when it proposes.

We think this is the choice that defines a product like this, so we made it the only one: silence is never consent.

3. The action was sent, the call timed out. Did it happen or not?

This is the case most systems don't model. They retry, and now there are two returns.

Allowfy treats "we don't know" as a real state:

  • Every execution carries the operation's ID as an idempotency key, so if your system already did it, a retry does nothing new.
  • If the answer is still unknown, the operation is not reported as failed or succeeded. It's held as outcome unknown, Allowfy tries again a limited number of times, and then asks a person.
  • The person checks their own system and settles it: it happened, or it didn't. That decision is recorded too.

4. "200 OK" isn't proof. How do you know it really happened?

A store can accept a request and still not apply it: a queued write that was dropped, or a job that never ran.

So after a change, Allowfy reads the order back from the store. If the order doesn't show the change yet, the outcome is unknown, not succeeded, and the same retry-then-a-person path applies. And the text the customer approves says what will really happen: for example, a cancellation only promises a refund on platforms where cancelling actually asks for one; elsewhere it says the refund is up to the store.

5. When something goes to review, how does it reach a person, and what happens while it waits?

A review queue nobody looks at is just a slower way to say no.

  • When an operation needs your team (because a rule says so, or the outcome is unknown), it appears in your review queue and you get a notification in the dashboard.
  • If nobody acts, there's a reminder after a day and an escalation after two.
  • While it waits, nothing is executed. The agent sees that it's waiting for the business, and can tell the customer.
  • One switch pauses every agent at once, including operations that were approved but not yet sent.

6. Does a verified agent prove the customer approved?

No, and it's worth keeping the two apart:

  • Who acted (authentication): the agent proves its identity with its own signing key. That tells you which assistant made the request.
  • What was allowed (authorization): the customer signs in to their own account with you (a code to their account's email, or your own sign-in), never by giving the agent a password. Then each change needs an approval of its exact terms, and your rules decide whether that is enough or your team must review it too.

The record keeps both, separately: which agent, which signed-in customer, which revision of which terms was approved, when, and under which rule.

7. In a dispute, whose record counts?

The one held by whoever took the money: the business. A log inside an agent vendor's database doesn't help the merchant much.

In Allowfy, the record is yours. Every step is written to a hash-chained ledger, with checkpoints signed by a key the database never holds. You can export a signed copy at any time and keep it outside Allowfy; anyone can verify it later, and a rewritten entry shows. For each operation there's also an evidence file with the terms, the approval and the outcome. It's tamper evidence for your records, not a promise about how any bank will rule.

8. Where should the human sign off?

On the steps you can't take back: money, shipping, anything irreversible. Reading an order status doesn't need anyone's approval; refunding 500 probably needs two.

In Allowfy that's a rule per action: allowed, needs the customer's approval, needs your team, or refused, with limits per order, per customer over time and per agent, a return window counted from the purchase date, and separate rules for cash-on-delivery orders. You test a rule on past operations before you publish it.

9. Should you log what the agent believed, not just what happened?

Yes. Many "the agent was wrong" cases turn out to be the agent being right about old information.

Allowfy records the exact terms at the moment of the proposal: the order as it stood, the amount, the date, plus the rule and the policy version that decided. When it executes, it compares with the order as it is now. So you can tell "the agent misread" apart from "the order changed in between".

The short version

  • A yes is tied to exact terms and expires. Silence is never consent.
  • "Unknown" is a real state: no blind retries, a person settles it.
  • A success is checked against the store, not taken on trust.
  • Reviews reach a person, with reminders, and nothing runs while they wait.
  • The record of who asked, who approved what, and what happened stays with the business, and shows if it was changed.

You can try all of this for free in test mode, where operations run end to end and nothing in your store changes. And check whether your site is ready for AI agents with the free Allowfy Check.