Practitioner Notes: Idempotent Handoffs Before You Add an LLM to a Custom Workflow

Description and use

Implementing atomic inbound recording, an outbox queue, and a single status field eliminates duplicate messages, ensures CRM consistency, and saves LLM tokens on retries.

Problem

Inbound events and outbound replies can be processed or sent multiple times, causing duplicate messages, inconsistent CRM data, and wasted LLM tokens.

Outcome

Implementing idempotent inbound handling, outbox delivery, and partial write tracking reduces duplicate messages, ensures consistent CRM data, and saves LLM tokens during retries.

Workflow

• Record inbound event with a unique key and insert-if-absent to detect duplicates.
• Enqueue a job to perform slow work, including LLM calls, after the event is recorded.
• Insert outbound replies into an outbox with a deterministic ID derived from the approved draft.
• Deliver messages from the outbox only if status is pending, updating status to sent and storing provider_id.
• Track handoff status on the CRM record with values received, matched, owned, replied.
• Maintain a dead‑letter list for events that fail repeatedly and review them manually.
• Reuse stored LLM outputs on job retries instead of generating new drafts.

Evidence

Before you wire an LLM into production messaging, make the handoffs on both sides of it boring: inbound events processed once, outbound replies sent once, and partial writes impossible to miss.

Source

The insert-if-absent must be atomic (a unique index is enough). Do the slow work, including the LLM call, in the queued job, not in the webhook handler.

Source

The outbox row id is derived from the approved draft, so approving twice or retrying delivery cannot create a second message.

Source

Write a single handoff_status field on the CRM record: received, matched, owned, replied.

Source

In our 72-hour audits, this list usually generates more findings than the prompts do.

Source