A demonstration usually shows the case where everything works. An operating workflow also needs an answer for missing inputs, conflicting evidence, unavailable tools and actions the agent is not authorised to take.
- 01Define the normal path
- 02Name the stopping conditions
- 03Make the handoff useful
- 04Learn from exceptions
Define the normal path
Write the input, expected output and acceptance criteria. State the actions the system may perform and the boundaries it must respect. A broad instruction to “handle it” makes exceptions harder to recognise.
Start with a workflow whose steps can be understood and reviewed. More autonomy is useful only when it improves the task under the conditions you can actually support.
Name the stopping conditions
Missing required information, contradictory source material, repeated tool failure and uncertain identity are examples of reasons to stop or ask for review. Choose conditions appropriate to the task rather than relying on a model to improvise every boundary.
Include a cost or attempt limit. Repeating the same failing action indefinitely is not persistence; it is an unbounded failure mode.
Make the handoff useful
Provide the reviewer with the task, actions already taken, current state and specific decision needed. A vague “something went wrong” transfers the investigation without preserving its context.
Avoid asking the human to approve an action they cannot inspect. Prepare the proposed result, affected records or change summary before the approval point.
Learn from exceptions
Group repeated failures and improve the workflow. Some need clearer inputs; others need a better tool or a permanently human step. Do not automatically remove the review boundary because it is inconvenient.
An honest early account of AI assistants in the source library was more useful than a perfect autonomy claim. Dependability comes from handling the ordinary failures as deliberately as the happy path.