agent's calendar sync created duplicate events — the external id was

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

Fix this in meeting prep agent calendar webhook by acting on the exact message first: make brief creation idempotent on calendar event identifier plus event updated time, check for an existing brief with that key before creating, and treat webhook retries as updates to the same brief instead of new brief requests. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent duplicated meeting briefs after calendar webhook retried the same event twice

Use this when

• The operation in meeting prep agent calendar webhook fails with this exact message: agent duplicated meeting briefs after calendar webhook retried the same event twice.
• The same failure repeats on retry with unchanged inputs.
• A call, review or send is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in meeting prep agent calendar webhook, and copy the full message plus the account, contact or meeting involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: make brief creation idempotent on calendar event identifier plus event updated time, check for an existing brief with that key before creating, and treat webhook retries as updates to the same brief instead of new brief requests. Verify: the single test item now produces the correct result, checked against its source record.
3. Check the neighbouring items that share the same template, integration, source or account, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result against the source system so a silent partial success is caught before sign off. Verify: counts and key values match the source or every difference is named and explained.
5. Rerun the original operation in meeting prep agent calendar webhook on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Calendar providers retry webhooks that are not acknowledged fast enough, and without an idempotency key each retry looks like a brand new event deserving its own brief.

Variant phrasings

agent duplicated meeting briefs after calendar webhook retried the same event twice

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix - agent duplicated meeting briefs after calendar webhook retried the same event twice

The how-to phrasing for the same failure in meeting prep agent calendar webhook. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting this failure in meeting prep agent calendar webhook

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: meeting prep agent calendar webhook at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstKZ6e5-6QJ1y-s52p5Wm7w

Resolved from the public thread: https://vectle.com/posts/pstKZ6e5-6QJ1y-s52p5Wm7w

Thread query: agent duplicated meeting briefs after calendar webhook retried the same event twice

TL;DR: Fix this in meeting prep agent calendar webhook by acting on the exact message first: make brief creation idempotent on calendar event identifier plus event updated time, check for an existing brief with that key before creating, and treat webhook retries as updates to the same brief instead of new brief requests. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Fix this in calendar sync agent by acting on the exact problem first: treat any availability window that did not come from a calendar response as missing rather than filling it in, record synced windows per interviewer from the actual responses, and flag interviewers with no retrieved window for a manual check. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one candidate first, then rerun the full scope and reconcile the results.

agent hallucinating figures not in source data for sync interviewer calendars for availability

Use this when

• The operation in calendar sync agent fails with this exact problem: agent hallucinating figures not in source data for sync interviewer calendars for availability.
• The same failure repeats on retry with unchanged inputs.
• An interview, a panel booking or a candidate confirmation is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The interview completes and you only disagree with a hiring decision such as advancing a candidate. That is a hiring call, not this failure.

Steps

1. Reproduce the failure on one named candidate in calendar sync agent and record the full problem text plus the candidate, requisition or panel involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: treat any availability window that did not come from a calendar response as missing rather than filling it in, record synced windows per interviewer from the actual responses, and flag interviewers with no retrieved window for a manual check. Verify: the single failing candidate now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring candidates, panels or requisitions that share the same automation, template or calendar sync, because this class of failure rarely affects only one candidate. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in calendar sync agent on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the ATS candidate record, the interviewer calendars or the booked calendar event, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the candidate record so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

agent hallucinating figures not in source data for sync interviewer calendars for availability

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single candidate proof, then the full rerun.

How to fix - agent hallucinating figures not in source data for sync interviewer calendars for availability error hallucination failure

The how to phrasing for the same failure in calendar sync agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

calendar sync agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

When one calendar in the sync returns nothing, an agent can present assumed working hours as synced availability, and only response level recording keeps assumed hours out of the panel search.

Edge cases

• The candidate was rescheduled, the panel was substituted or a timezone changed after the failing run started. Refresh the candidate state and reapply the fix against the current values, not the values from the failed run.
• The single candidate proof passes but the full rerun still fails on other candidates. Treat each remaining failure as its own scope, because a shared automation can hide more than one cause.
• The source systems disagree on the correct value. The ATS candidate record governs stage and panel assignment, the interviewer calendars govern availability, and the booked calendar event governs the interview time; record which source won and why.

Compatibility: calendar sync agent at current versions, plus the ATS, calendar or video platform the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

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

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

Thread query: agent hallucinating figures not in source data for sync interviewer calendars for availability error hallucination failure

TL;DR: Fix this in calendar sync agent by acting on the exact problem first: treat any availability window that did not come from a calendar response as missing rather than filling it in, record synced windows per interviewer from the actual responses, and flag interviewers with no retrieved window for a manual check. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one candidate first, then rerun the full scope and reconcile the results.