In my voice-driven CRM assistant, a user records a voice note in Slack and the assistant acts on it. The first version sometimes acted on the same note more than once.
Why one note looked like several
Slack sends an event when a file is shared. A voice note is not shared once. As it moves through recording, upload, transcription and appearing in the channel, the same event can arrive between two and five times.
Treating each as a new instruction meant duplicate transcription, duplicate model calls and duplicate records in the CRM.
The event name is not the identity
The fix was to stop treating the event as the unit of work. The durable thing is the file. Every one of those events refers to the same file identifier, so that is what I deduplicate on, before downloading audio or spending anything on transcription.
Two details that mattered
The early events do not reliably say what kind of file it is. Filtering on type at that point threw away real voice notes. I moved the type check to after the file's details have been fetched, when the answer is dependable, and non-audio uploads are routed away from transcription there.
Slack also expects a quick acknowledgement. If the workflow does its slow work first, Slack assumes the delivery failed and sends it again, which creates the very duplicates I was removing. So the workflow acknowledges straight away and does the work afterwards.
What I took from it
A provider's event names describe its own lifecycle, not my business events. Reliable automation finds the durable object behind the events and makes that the boundary for "have I already done this".