An automated assistant drafts messages successfully for a week. Then a source system changes, and the same workflow starts using the wrong field. Who can stop it before the next batch leaves?
Name the owner before the exception
Assign someone who can review the workflow’s state, pause new actions and coordinate recovery. Ownership should include a backup arrangement for absence. A group chat labelled “AI team” is not enough if nobody knows who has the required access.
Define stop conditions in terms of observable events: a source unavailable, a required validation failing, an unexpected rise in rejected outputs or a permission change. Avoid a rule such as “stop when quality is poor” without saying how poor quality will be recognised.
Test the pause with a harmless case
In a controlled environment, interrupt the workflow and check what remains queued. Does pausing prevent new work only, or also stop pending external actions? Can a retry create a duplicate? Keep a record that distinguishes completed, pending, cancelled and uncertain actions.
Use a manual fallback for the essential task. For example, a team might return to human-prepared drafts while the source mapping is corrected. Do not resume merely because the error message disappears; validate the corrected behaviour with representative cases.
Keep permissions proportionate. A drafting assistant does not automatically need authority to send messages, alter customer records or approve payments. Review each external action separately and retain the approvals appropriate to its consequences.
After an incident, document what failed and what would have detected it sooner. The value of a stop control is practical: someone can use it, knows what it stops and can explain how work will continue safely afterwards.