When is an AI task actually complete?

A click is not yet an outcome. Connect AI actions to confirmed completion, safe retries and clear operational ownership, with practical acceptance tests.

Wann ist ein KI-Auftrag wirklich erledigt?

English edition — originally published in German as Wann ist ein KI-Auftrag wirklich erledigt?.

“Done,” the AI assistant reports. It has drafted the response and handed the request to an interface. Yet the destination system still lacks the change. Or the change was saved, but the response was lost along the way. Clicking again now risks executing the action twice.

Once AI acts in business systems, it needs a verifiable definition of completion. For COOs and CTOs, this is a concrete design task: which observation permits the status “done”? And who takes ownership while the result is uncertain? This article sets out a workflow that business owners and developers can define together.

:::takeaways{title="For implementation"}

:::

Approval is not yet an outcome

A prepared quotation, an approved message and a confirmed send are different states. That distinction must exist both in the interface and in processing. A green tick after clicking “Send” would be misleading if the sending service had merely accepted the request.

This boundary already exists in technical communication. The HTTP standard defines status 202 as acceptance for processing that has not yet been completed. Acceptance therefore does not guarantee successful completion. For management, this creates a business requirement: define the outcome actually required for each action.

The distinction also matters in our prototype work. An interface can already represent actions, ownership and return paths using demonstration data. A local status change, however, does not establish an effect in a connected business system. Production implementation begins when the appropriate external evidence is added.

Define completion before connecting the system

Take a delivery-date change as an illustrative example. AI prepares the new date and a message. A person reviews the implications and approves the specific change. The overall case involves two separate outcomes: the saved date and the agreed communication.

A short completion agreement establishes how both sides recognise success. This is an operational agreement between process owners and developers, not a legal contract. It describes the target record, permitted change, approval and evidence of the outcome. It also specifies a time limit for resolving uncertainty.

| Step | Sufficient evidence | |---|---| | Prepare the date change | Reviewable draft identifying the order and new date | | Approve the change | Authorised approval of this exact version | | Save the date | Matching order identifier and confirmed new value in the authoritative system | | Send the message | Confirmation appropriate to the sending objective, with a message identifier | | Complete the case | All agreed component outcomes evidenced |

Whether a sending confirmation is sufficient or a delivery confirmation is also required depends on the process objective. Neither automatically establishes that someone has read the message. The interface must name precisely the state supported by the evidence.

Uncertainty is a work state of its own

After a timeout, it may be unclear whether the change was saved. “Failed” would then be as premature as “done”. The cockpit should show “Checking outcome”, identify the responsible person and provide a next verification step.

For example, the application queries the current state using the known order or action identifier. If it finds the expected result, it can confirm the step. If the state differs or remains unknown, the case goes for clarification. The available evidence travels with it, so nobody has to research the entire history again.

For time-sensitive cases, business owners and operations agree a deadline. When it expires, the responsible person receives a specific task. A spinner that keeps turning indefinitely is not a managed exception process. The last check, the outstanding step and the next action should remain visible.

Retry without acting twice

A lost response must not cause the same order to be created twice. A primary technical source on safe retries explains the use of unique request identifiers supplied by the caller. The aim is to repeat the same intended operation without introducing additional side effects.

This principle is called idempotency. The identifier only helps if the destination handles retries correctly. Check identifier expiry and changed parameters. Without this guarantee, reconcile the target state or seek manual clarification.

The implication for the interface is straightforward: another click must not blindly start a new action. The application distinguishes between retrying the same approved operation and creating a new request. The technical safeguard belongs in processing; a warning beside the button is insufficient.

Keep partial successes visible

Suppose the date was changed, but the message could not be sent. The overall case remains open even though one part succeeded. The next attempt must not automatically execute every step again.

The workspace shows the confirmed date separately from the outstanding message. A responsible person uses the process rules to decide whether to complete the communication or correct the date change. Some actions can be offset through a reversing entry or correction; a message already read cannot be recalled from the reader's mind. Each action type therefore needs an appropriate recovery path.

This also makes the AI work layer useful when things go wrong: it keeps context and handling together. Our article on integrating AI into existing systems describes the foundation for such connections.

Start with a few targeted tests

Before production use, business users and developers test the same workflow with deliberately introduced failures. Four tests provide a concrete starting point:

  1. A double click produces only the single intended change.
  2. The response is lost after a successful save; reconciliation identifies the existing success.
  3. Approval becomes invalid before execution; the action is stopped.
  4. One step fails; confirmed steps remain visible and are not blindly repeated.

Each test needs an expected state in both the destination system and the workspace. Verification should detect unauthorised actions as well as falsely reported successes. These are acceptance criteria for this workflow, not a universal security guarantee.

Include clarification work in the economics

Reliable outcome verification requires development and operational effort. It can be worthwhile if it reduces follow-up enquiries, duplicate handling and manual checks. The pilot must establish whether it does.

:::callout{type="info"} Hypothetical calculation: of 2,000 monthly actions, 100 currently require manual status clarification taking eight minutes each. If this falls to 20 in the pilot, it removes 640 minutes, or 10 hours and 40 minutes, of clarification work. At an assumed CHF 90 per hour, that represents CHF 960 of valued time. Additional verification calls, support and implementation have not yet been deducted. These are not measured project results. :::

Track confirmed completions, uncertain states, duplicate executions and human rework. Cost per resolved AI case helps connect this quality to the effort required.

Which action must your AI assistant be able to complete reliably? We can help define evidence of completion, ownership and a bounded acceptance test.

Sources and interpretation

Research reviewed: 26 October 2026. The HTTP standard establishes the meaning of an accepted request. The primary technical source explains safe retries. The workflow, table, tests and calculation are our editorial interpretation. The example does not describe a production customer installation.