Key decisions
- One workflow and its stopping point are defined.
- Synthetic ordinary and exception inputs exist.
- Expected behaviour is written before testing.
- Human review has an owner and a visible queue.
Choose one workflow and its boundary
Describe the trigger, input, proposed action and stopping point. For a fictional enquiries desk, the pilot may classify a request and draft a reply while a person still decides whether to send it. State the cases that are outside scope. Anthropic’s agent guidance distinguishes different workflow patterns; that context can inform a design, but it does not verify the accuracy of your particular process.
Create representative tests before the demo
Use synthetic ordinary requests, ambiguous messages, missing information and duplicated inputs. Write the expected response for each. Include a case where the correct behaviour is to stop or request human review. Keep the same set for repeated comparisons and add new cases when you discover a failure. A demo using only the easiest examples cannot establish how the workflow handles the exceptions your team actually encounters.
Make review and exceptions observable
Define who reviews a draft, where the unresolved task appears and how to recover from a failed step. Review an execution record instead of relying only on the final screen. n8n documents workflow executions; the useful lesson here is to connect a visible outcome with the sequence that produced it. Do not log real confidential input into an exercise simply to make a screenshot look realistic.
Decide what the pilot proves
Record tested cases, review effort and unresolved failures. Compare the same task before and after the pilot if you want to assess a change, using consistent definitions. A small test may justify a wider supervised trial while still leaving unattended operation unproven. State that boundary in the decision. Any live permissions, retention rules and operational responsibility need agreement before expanding the workflow.
Try the exercise
Design an acceptance sheet for a fictional AI enquiry classifier. Include an ordinary request, an ambiguous one and a duplicate. Decide what the system may draft and what a person must approve.
Expected output
A bounded test set, an exception route and a written trial decision. It is a concept exercise, not evidence of savings or accuracy in a live business.
Your evidence checklist
Mark only what you have checked. This records your own progress, not an independent audit or a predicted result. There is no automatic saving; download the note if you want to keep it.
0 / 6 checked
Questions and answers
Can the pilot be judged from one successful demonstration?
A demonstration shows one path under its chosen conditions. Use ordinary, ambiguous and failure inputs before deciding whether to expand. Keep the evidence and unresolved limitations together so the next trial has a reasoned scope.
What should happen when the AI is uncertain?
Define a visible review or stopping rule suited to the task. The person responsible should know what information is missing and what action remains pending. Avoid silently turning uncertainty into a confident output that the workflow treats as approved.
Next step
Make the pilot small enough to test, and make its exceptions clear enough for a person to own.
Sources and verification
- Anthropic — Building effective agents ↗
Checked:
- n8n — Workflow executions ↗
Checked: