The automation demo is the easy part.

Ask to see the second run

The first demonstration often shows a clean input moving through a successful sequence. That establishes possibility. The next useful question is what happens when the same input arrives twice, a field is missing, or a connected service stops responding. Those conditions test the operating system around the AI.

A buyer does not need to inspect every line of code. They do need to understand the workflow’s boundaries and how failures become visible. Ask the builder to explain one success, one recoverable failure and one case that should stop for a person.

Retries need context

Microsoft’s Retry pattern explains that temporary failures may be retried, but non-idempotent actions can execute more than once. In practical terms, a lost response does not always mean the original action failed. Repeating it blindly can create a duplicate update or external action.

Ask how the implementation identifies a work item and prevents duplicate execution. Find out which failures are retried, how attempts are limited and where unresolved work goes. These are design questions for the actual connected systems. A generic promise that the workflow retries automatically is not enough to assess them.

Define done at the receiving system

An AI model returning text is an intermediate event. If the job is to prepare a CRM handover, completion should include the relevant validation and confirmation that the receiving system accepted the update. Keep separate states for prepared, approved, attempted and completed when the workflow needs them.

This distinction matters during recovery. If an external write succeeds but a later notification fails, the system should know which step needs attention. Replaying the whole process without that context can recreate work that was already completed. Ask for a readable activity record that helps the owner make this distinction.

Test the boundaries before adding volume

Choose a test set that represents your ordinary work and its known variations. Add deliberate failures: a missing field, an unexpected format, a duplicate event and an unavailable connection. Verify that the system follows the agreed stop or escalation behavior. These are proposed acceptance checks, not a universal certification.

Permissions deserve the same attention. If a workflow only needs to read a document and prepare a draft, it should not receive broad write access merely for convenience. Expand access only when the specific action, owner and safeguards are clear.

• Show a duplicate event without a duplicate business action.
• Show an invalid input reaching an accountable owner.
• Show a failed connection and its final recovery state.
• Show how to pause the workflow and resume or revert safely.
• Show what the operator can see without developer help.

Agree ongoing ownership before launch

A workflow depends on changing systems, data and business rules. Decide who maintains connections, reviews exceptions, updates instructions and checks whether the result is still useful. Agree which failures require immediate attention and which can wait for routine review. The service should fit the consequence of the work.

Make operating effort visible in the commercial model. Include human review, support, usage costs and periodic changes alongside the build cost. A workflow that saves handling time but creates more maintenance than the team can absorb may need a smaller scope.

Use the approval matrix to define what the system may do and the mapping worksheet to document its boundaries. The most useful demonstration ends with a shared understanding of who owns the work on an ordinary Tuesday, including the parts that do not go to plan.