An AI workflow can lose confirmation without the action itself failing.

If a product treats that uncertainty as success, it may tell the customer that work is complete without enough evidence. If it treats it as proof that nothing happened, it may encourage the same action again.

The product needs more than an accurate status label. It needs a defensible next step.

Epic’s October 21 Connectors announcement provides a timely example of work crossing applications. It describes how Emmie could place a hospitalized patient’s meal order in an external dietary-management app. Developer-created Connectors are planned to become discoverable through Epic Showroom in March 2027; the announcement is not evidence of broad deployment now.

This does not mean the AI receives new autonomous decision authority. Epic’s Johnston Thayer told Fierce Healthcare, “There will not be new autonomous actions taken as a result of these capabilities.” The useful product question is what customers can rely on when an authorized task crosses a system boundary.

Consider a hypothetical extension of the meal-order example, not an Epic incident or a description of its implementation.

The workflow sends an order request but receives no usable confirmation. The dietary system might have accepted the order, or it might not have. From the workflow’s perspective, the outcome is unknown.

Submitting it again could create a duplicate if the first request was accepted. Refusing to proceed could leave the order unplaced if it was not. Simply displaying “unknown” leaves someone else to decide which risk to take.

That is where a technical uncertainty becomes an operating responsibility.

Where the receiving system provides an authoritative way to check the order, the workflow should use it before deciding what to do next. A retry may be justified where the actual interface contract and duplicate protection make it safe for that operation. Neither capability should be assumed because a tool accepts a correctly structured request.

If the outcome still cannot be established, the product needs a defined handoff. A named operational role should receive the unresolved task, the evidence already available and responsibility for deciding what happens next. Otherwise, the apparent convenience of automation can leave the patient or an uninformed member of staff carrying the uncertainty.

The boundary matters in the other direction too. If the contracted task is to place an order, and acceptance by the receiving system is the agreed evidence of completion, that may be enough. The workflow should not claim the meal was delivered, but it need not verify delivery to fulfill a narrower promise.

For product and business leaders, this changes the release decision.

A team might support a narrower set of actions for which confirmation can be established. It might support a wider set with an explicitly staffed resolution process. The second option may offer more convenience, but its economics include investigation, waiting time and operational capacity, not just successful automated requests.

If nobody owns unresolved work, the promise is broader than the service the organization has agreed to operate.

This is not an argument for manual approval of every action. A bounded, authorized, low-consequence task may be appropriate to automate. Read-only retrieval also carries privacy and decision risks. The level of intervention should follow the task and its consequences, not a categorical distinction between reading and acting.

Before promising that an AI workflow will take care of a task, I’d want to know what counts as complete and who takes responsibility when that cannot be established.

The value is not only that work can move across applications. It is that the customer has a credible path forward when the result is uncertain.