Approvals that continue the work

An approval is a promise in both directions. The person reads what an agent wants to do and says yes. The product has to carry the work on from there. Until September, ours often did not.

Someone approved an action in the chat and was asked the same thing again. The identical task produced two proposals and a card that never cleared. Someone else pressed "Send it" on an approval card several times and nothing posted. A card could say "Approved" while nothing was ever going to happen, and one approver watched a card disappear and took that to mean the message had been sent.

712

We were asking about the wrong things

Before fixing the yes, we looked at what we were asking people to approve. In the 30 days to 9 September, 307 of 776 approval cards asked for permission to hand work to a teammate, and 259 of those expired with nobody answering. A hand-off stays inside the workspace, and it no longer asks by default.

Four ways a yes went nowhere

The chat moved on before the work ran. Approving an action queues it, and the queued job runs seconds to about 30 seconds later. The conversation resumed at once, saw its own action still waiting, and proposed it again.

A redrafted plan started a second run. When a person's answers changed a plan, the new draft got a new key, so the check that stops a plan starting twice never matched it. One request could start two runs and ask the same questions twice.

Failures multiplied. When an approved action failed, every retry raised a new card about the error, so one message produced three separate cards.

The receipt left before the send. A message waits out a 35-second hold so the person can take it back, and the receipt on screen was removed 8 seconds after the click.

An extra field nobody approved

Approved actions in connected apps failed every time. Our system added a key of its own to every call. The connected apps check each call against the action's own list of allowed inputs, and they refuse the whole call when something extra arrives. That key had been added since 16 June, so no approved action in a connected app had ever run through that path.

What changed

After an approval, the chat now waits up to 45 seconds for the real outcome: the action ran, it failed, or the person took it back. We repeated the task that had failed, live, and got one proposal, carried out, with no repeated question.

A new plan in a conversation cancels any earlier plan still running there, so two dispatches for one conversation leave exactly one run.

When an approved action fails, its retries now share one card. The receipt stays on screen until the action has finished or failed. An approved action reaches a connected app with exactly the details the person approved, and nothing else. A card that says "Approved" now reports a stall once the action runs past its time limit, instead of promising forever. And the time an approved action has to run now starts when the person decides.

What is still not right

If the work takes longer than the 45-second wait, the chat gets an honest note that the action is running and must not be repeated, not the result itself.

When an agent asks a question in the middle of background work, it waits up to 72 hours. After that, the run carries on without an answer.

An approved action that genuinely runs longer than 10 minutes reads as stalled until the page is reloaded.

A sweep to catch approved actions whose resume job was lost was considered and deferred.

What to ask any vendor

After you approve something, what tells you it actually happened? What happens if you press approve twice? How many of your approval requests expire unanswered, and why were they asked?

Good answers come with a demo. The insights are free. If you want this level of engineering pointed at your operation, start with the free audit. The plan is yours to keep either way.