double confirmation two Zoom links scheduler outreach

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.

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.

TL;DR: Expire the old confirmation link on every reschedule and allow only one live confirmation per candidate. The loop is a state bug: rescheduling re-armed the confirm step while every previous link still resolved. Revoke first, then send the fresh link, and make reschedules idempotent.

scheduler agent set up a loop: every reschedule triggered a 'confirm your slot' email and candidates kept clicking the stale link

1. Read the reschedule handler and check what happens to the previous confirmation token. Expected: the handler sends a new confirm email but never invalidates the old token.

2. On reschedule, revoke the previous confirmation link before generating the new one. Expected: clicking the old link now shows "this slot was moved, here is the current one" instead of confirming the stale slot.

3. Make reschedule idempotent: the same candidate moved to the same new slot twice produces one confirm email, not two. Expected: replaying the reschedule request changes nothing after the first run.

4. Enforce one pending confirmation per candidate: a new reschedule supersedes, never stacks. Expected: a candidate with three reschedules has exactly one live link.

5. Add a rate guard: more than two reschedules in a day routes to a human instead of sending another automated email. Expected: the third reschedule in a day creates a recruiter task, not an email.

Use this when

• Candidates confirm slots from old emails after a reschedule.
• Each reschedule multiplies the confirmation emails instead of replacing them.
• Confirmation clicks seem to re-trigger scheduling actions.

Not for this skill when

• The loop is in the candidate's email client auto-clicking links (link prefetch); fix with one-time tokens, not reschedule logic.
• The confirmations are fine but the calendar events duplicate (that is an event-creation bug).
• Reschedules are rare and each one is correct; the issue is email volume, not stale links.

Variant phrasings

• reschedule email loop with stale confirmation links
• candidates clicking old confirm links after interview moved
• every reschedule sent another confirm your slot email
• confirmation link still worked after the interview was rescheduled

Why it happens

Confirmation emails are events that mutate state, and the reschedule flow treated "send confirm" as a fresh action each time without retiring the previous one. Every historical link stayed a live button. Candidates clicking any of them re-confirmed outdated state, which in some setups re-triggered scheduling actions, feeding the loop. The missing piece is lifecycle: each confirmation token needs exactly one live generation at a time.

Edge cases

• The candidate clicks the old link in the seconds between revoke and the new send: the revoke message must point them at the newest email, not a dead end.
• Two recruiters rescheduling the same candidate at once: serialize reschedules per candidate so the revoke-then-send pairs cannot interleave.
• Email clients that prefetch links: a prefetch must never count as a confirmation. Require an explicit click-through page.
• A candidate who already confirmed the old slot before the reschedule: they need a "your interview moved" notice, not just a new link.

Provenance

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

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

Thread query: scheduler agent set up a loop: every reschedule triggered a 'confirm your slot' email and candidates kept clicking the stale link

TL;DR: