Before retrying an AI workflow, check what already happened in the rooms
A failed or interrupted workflow does not prove that nothing happened. In a growing operation the effects are the whole point: an alarm may already have reached the on-call phone, a batch entry may already be written, a deviation report may already be in someone's inbox. So the first check before any retry is not "did it finish?" but "what did it already do?" A missing acknowledgement is not a missing effect.
This is the recovery decision that comes after the work itself is defined (the agent task brief and the operational report brief) and after one run has been accepted (scheduling agent work).
Give the operation an identity
Where the executing system supports it, give each consequential operation a stable key and keep a retained receipt, so a retry is recognised as the same request. Define what counts as the same request, and refuse a changed payload silently reused under the old identity — last night's room summary is not this night's. Stripe documents the pattern: its idempotent requests save the first request's result under a client-supplied key, return it unchanged on retry and error when the parameters differ.
Read the authoritative result
An illustrative workflow composes a room summary and records it, then the connection drops before the worker receives confirmation. Starting over from the beginning may write a second entry, and the team then holds two versions of the same night.
Read back the destination through the approved route: the record, its identifier and its timestamp. If the result cannot be established, mark it unknown and pause the dependent action instead of guessing.
Separate the retry classes
Not every repeated action is equal. Reading a sensor history again is harmless. Sending the same alarm to the on-call list again is not. A duplicate batch entry damages the traceability the operation depends on, and a duplicate report changes what the team believes happened in the room.
Duplicates are also a transport fact: in message-based systems, MQTT QoS 1 is at-least-once delivery — unacknowledged packets are resent by design, and the receiving application must detect the duplicate itself.
Keep an action ledger that separates attempted, confirmed, failed and unknown effects, so the next step is chosen from evidence rather than from memory. A model's recollection of the attempt is not an authoritative receipt. Before repeating any specific operation, obtain its actual retry contract instead of assuming another identical call is quiet.
Resume the remainder, then test the boundary
Use the ledger to define the smallest next step: send the missing part, not the whole task — the same staged thinking as a controlled update and rollback. In an isolated, authorised test, interrupt the workflow after the write and before the acknowledgement, then verify both the retained evidence and the duplicate prevention.
What to ask
For each step in the workflow: is it safe to repeat, what is the authoritative receipt, which system owns that receipt, and what does the workflow do when the receipt is missing? A recovery rule that asks what already happened before asking whether to run it again is part of the design, not a line in the prompt.
If you would rather have these recovery rules designed for your growing system than reconstructed after an outage: the Manna MIND Agentic Server is configured around your growing system for Manna-run agent analysis and reports, and you stay the person who accepts the results. To talk through how your workflow should recover, contact Manna.
Prepared with AI assistance for Manna Insect Oy.