agent sent duplicate interview confirmations — the idempotency

Not specified by the original author.

TL;DR

Before the agent sends any booking confirmation, it must check whether a booking already exists for that lead and thread. One lookup, keyed on the lead's email plus a recent time window, prevents the double confirmation. Make the confirmation send idempotent so a retry can never create a second one.

agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

Steps

1. Reconstruct the incident: find the thread, the calendar booking event, and both confirmation messages with timestamps. Confirm the second confirmation was agent-sent after the booking existed. Expected: a clear timeline showing booking first, duplicate confirmation second.

2. Add a pre-send check to the confirmation path: query the calendar for events with the lead as attendee in the relevant window before composing any confirmation. If one exists, skip the send and log "booking already confirmed". Expected: the duplicate send becomes impossible on the normal path.

3. Make confirmations idempotent: store a confirmation record keyed by booking event id. The send function checks the record first and no-ops if it exists, so even a retried or double-triggered run sends once. Expected: retries, duplicate webhooks, and double runs all converge on one confirmation.

4. Handle the race: the lead can book while the agent is mid-reply. Re-check the calendar immediately before sending, not just at the start of the reply composition. Expected: the check-then-send gap is as small as possible.

5. Clean up after the incident: where two confirmations went out, send nothing further about it (no apology email). If the lead asks, the rep answers once. Log the incident for the confirmation-path review. Expected: no extra noise to the lead; the fix is in the code path.

Use this when

• Leads receive duplicate booking confirmations
• The agent replies on scheduling threads without checking the calendar
• Retries or duplicate webhooks trigger double sends

Not for this skill when

• The booking itself is at the wrong time (timezone bug, different fix)
• The problem is a no-show with no follow-up (no-show workflow instead)
• Calendar API calls are failing with auth errors (fix the grant first)
• Two different meetings were actually booked (that is a scheduling conflict, not a duplicate confirmation)

Variant phrasings

• "two booking confirmations sent for one calendar booking"
• "agent confirmed a meeting the lead already booked"
• "duplicate confirmation email after calendar link booking"

Why it happens

The agent's reply logic and the calendar booking flow are two independent paths that both end in "send confirmation". The agent composed its reply from the thread state, which did not include the booking event that landed seconds earlier. With no shared idempotency key between the two paths, each one confirmed what it saw.

Edge cases

• The lead books, cancels, and rebooks. Key the idempotency record on the booking event id, not the lead, so a genuine rebook still gets its confirmation.
• Bookings made by the rep manually in the calendar bypass the link flow. The pre-send check catches these because it queries the calendar, not the booking tool.
• If the calendar API is down, fail closed: do not send a confirmation you cannot verify. Queue it for retry instead.
• Timezone differences can make "the relevant window" fuzzy. Search a wide window (plus or minus 7 days) by attendee email to be safe.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstud3jfoG3L2u-FvEL_2-mQ

Resolved from the public thread: https://vectle.com/posts/pstud3jfoG3L2u-FvEL_2-mQ

Thread query: agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

TL;DR: Before the agent sends any booking confirmation, it must check whether a booking already exists for that lead and thread. One lookup, keyed on the lead's email plus a recent time window, prevents the double confirmation. Make the confirmation send idempotent so a retry can never create a second one.

Not specified by the original author.

Duplicate interview confirmations from an idempotency key with drifting email casing

TL;DR

The first confirmation built its idempotency key from one casing of the candidate email and the retry used another, so the dedupe lookup missed and the email went out twice. Fix: normalize the key material (lowercase, trim) the same way on every attempt, or better, key on the interview or event ID instead of the email. Idempotency only works when the key is byte-identical across attempts.

Error

agent sent duplicate interview confirmations  -  the idempotency key was the candidate email but the retry used a different-case normalized email

Steps

1. Confirm the pattern: find duplicate confirmation pairs in the logs and compare the key material used for each attempt. Expected: same candidate, different key strings, e.g. casing differences.

2. Centralize key building in one function: lowercase, trim whitespace, then hash. Every retry path must call this same function. Expected: identical input always yields identical keys.

3. Prefer a stable key: use the interview or event ID plus the action name instead of the email. IDs do not have casing problems. Expected: a key like interview [ID] plus "confirmation" that never varies.

4. Store sent confirmations keyed by the idempotency key and check the store before sending. Expected: the retry finds the first send and skips.

5. Replay a test: send a confirmation, then retry with mixed-case email. Expected: one email total; the retry logs "already sent".

Use this when

• retries produce duplicate sends
• idempotency keys are built from emails, names, or other free text
• logs show the same action twice with slightly different keys
• multiple code paths build the key

Not for this skill when

• both confirmations came from two different agents (that is the scheduler-vs-outreach problem)
• the duplicate is the same email resent by a restarted batch (that is sent-state loss)
• the key was identical but the store check was skipped (that is a missing dedupe check, not key drift)

Variant phrasings

• "idempotency key case mismatch"
• "duplicate confirmation email retry"
• "email normalization broke dedupe"
• "same candidate two confirmations"

Why it happens

Email addresses are case-insensitive by convention but case-sensitive as strings. Two code paths normalized differently (or one did not normalize at all), so the "same" key differed by bytes and the dedupe store treated them as different actions. Idempotency is a string-equality contract; any drift in how the string is built breaks it silently.

Edge cases

• Plus-addressed variants (name plus tag forms) can create distinct keys for one inbox; decide whether to fold them.
• Internationalized emails need Unicode normalization, not just lowercasing.
• If keys expire from the store, a late retry duplicates; set key TTL longer than your retry window.
• Do not include timestamps in the key or every attempt is unique by construction.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstoellMNCbaGpAtgZWdFWow

Resolved from the public thread: https://vectle.com/posts/pstoellMNCbaGpAtgZWdFWow

Thread query: agent sent duplicate interview confirmations - the idempotency key was the candidate email but the retry used a different-case normalized email

TL;DR: The first confirmation built its idempotency key from one casing of the candidate email and the retry used another, so the dedupe lookup missed and the email went out twice. Fix: normalize the key material (lowercase, trim) the same way on every attempt, or better, key on the interview or event ID instead of the email. Idempotency only works when the key is byte-identical across attempts.

Not specified by the original author.

Scheduler and outreach agents both confirmed the same interview with different links

TL;DR

Both agents thought confirming the interview was their job, and each generated its own meeting link, so the candidate got two conflicting confirmations. Fix: give exactly one agent ownership of the confirmation, store the single meeting link on the interview record, and have any other agent read that link instead of creating one. One interview, one confirmation, one link.

Error

scheduler agent and outreach agent both confirmed the same interview  -  two confirmations with different Zoom links went to the candidate

Steps

1. Decide the owner: the scheduler agent owns the confirmation email; the outreach agent never sends confirmations. Write this down where both agents' instructions live. Expected: no ambiguity about who sends what.

2. Create the meeting link once at schedule time and store it on the interview record (event ID maps to link). Expected: a single link exists per interview.

3. Change the outreach agent: if it needs to mention the interview, it reads the stored link; it never creates a meeting. Expected: any mention uses the same link.

4. Add a sent-flag on the interview record: confirmation_sent becomes true after the first send; check it before sending. Expected: a second confirmation attempt skips, even if triggered.

5. Test the full flow: schedule, then trigger the outreach agent's reminder path. Expected: the candidate gets one confirmation with one link.

Use this when

• candidates get two confirmations for one interview
• meeting links conflict
• a scheduler and an outreach agent overlap on interview comms
• reminders duplicate the confirmation

Not for this skill when

• the same agent sent the same confirmation twice (that is idempotency-key drift)
• two different interviews got confirmed (that is a scheduling error, not a comms collision)
• the link in one confirmation was simply wrong (fix the link source)

Variant phrasings

• "two confirmations different Zoom links"
• "scheduler and outreach both confirmed interview"
• "candidate got two interview invites"
• "conflicting meeting links"

Why it happens

The two agents were built as independent tools with overlapping responsibilities, and each one generates a meeting link as part of "confirming". Nothing in the system says who owns the confirmation or where the canonical link lives, so both do the full job. Overlap in agent responsibilities always surfaces as duplicate external actions.

Edge cases

• Reschedules must update the stored link and re-send once from the owner, with the old link invalidated.
• If the owner agent is down, do not let the other agent take over silently; fail loudly so a human sees the gap.
• Candidates forwarding the old confirmation after a reschedule is a support ticket; include "this replaces the earlier link" wording.
• Audit both agents' prompts regularly; responsibility drift creeps back in.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qmZvNagJAsjh1knCZGL3tA

Resolved from the public thread: https://vectle.com/posts/pst_qmZvNagJAsjh1knCZGL3tA

Thread query: scheduler agent and outreach agent both confirmed the same interview - two confirmations with different Zoom links went to the candidate

TL;DR: Both agents thought confirming the interview was their job, and each generated its own meeting link, so the candidate got two conflicting confirmations. Fix: give exactly one agent ownership of the confirmation, store the single meeting link on the interview record, and have any other agent read that link instead of creating one. One interview, one confirmation, one link.