onboarding agent misclassified bounced invite as delivered

Not specified by the original author.

Fix the onboarding agent misclassifying bounced invites as delivered

TL;DR

"Sent" is not "delivered." Track the full email event chain - sent, delivered, bounced, dropped - and only mark an invite delivered when the provider confirms delivery. A bounce must flip the invite to bounced and trigger the address-fix flow, not sit quietly under a delivered label.

The problem

invite to [user email]: sendgrid accepted (202)
agent recorded: delivered
sendgrid events 40s later: bounce - mailbox unavailable
agent record: still "delivered"; user never got the invite; run reported success

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=onboarding agent misclassified bounced invite as delivered"

Fix it

Step 1: Consume the provider's event webhook

Subscribe to delivery events (delivered, bounce, dropped, deferred) from the email provider and process them into the invite record. The send call's 202 only means accepted, nothing more.

Expected: every invite has an event trail, not just a send timestamp.

Step 2: Only mark delivered on a delivered event

Set the invite status to sent after the API accept, and upgrade it to delivered only when the delivered event arrives. Bounce and dropped events set the status to bounced or dropped with the reason.

Expected: the status column reflects what actually happened to the email.

Step 3: Reconcile unconfirmed sends on a schedule

Sweep invites stuck in sent with no delivery event after a timeout (an hour is plenty). Query the provider's event API for their final state and update the records.

Expected: no invite sits in sent forever; every one resolves to delivered, bounced, or dropped.

Step 4: Route bounces into the address-fix flow

A bounced invite triggers the same path as a failed delivery: flag the address, notify the admin or the inviter, and offer a corrected-address resend. Never auto-retry a hard bounce.

Expected: bounces get fixed by humans instead of rotting under a delivered label.

Step 5: Prove it with a bouncing test address

Send an invite to a known-bouncing test mailbox and watch the full event chain.

Expected: the record moves sent to bounced with the provider's reason, and the address-fix flow triggers.

When this applies

• Invites show delivered but recipients never received them
• The provider's event feed shows bounces the agent never processed
• Invite status is set from the send API response alone

When it doesn't

• The email was never sent at all (fix the send path)
• Delivery events arrive but are wrong (a provider data problem)
• The complaint is about spam-folder placement (a deliverability problem)

Compatibility

SendGrid, Postmark, Mailgun, and SES event webhooks; any invite flow that reports delivery status.

Variant phrasings

invite marked delivered but bounced

Same fix. The 202 accept is where the misclassification starts; the event webhook is where the truth lives.

agent thinks invite succeeded but email bounced

Check whether the agent subscribes to bounce events at all. Many flows wire the send and forget the events.

Why it happens

The send API returns success (202 accepted) and the agent records the happiest interpretation: delivered. But acceptance only means the provider took the email; delivery, bounce, and drops happen seconds later as separate events. Nobody wired those events back into the invite record, so the initial optimistic label becomes permanent and wrong.

Edge cases

• Soft bounces that later deliver: let the delivered event overwrite the bounce, with the history kept
• Suppression list drops: these arrive as dropped events, treat them like bounces for the fix flow
• Delayed event webhooks: the reconcile sweep in Step 3 covers events that arrive late or never

If it still fails

• Capture the send response, the provider event feed, and the invite record before changing anything else.
• Reproduce with a single bouncing test address so you are not debugging a crowd.
• Check the provider status page; event delays look exactly like tracking bugs.

Prevention

• Invite status is event-driven from day one, never set from the send response.
• Monitor the sent-but-unresolved count; a growing backlog means the event path is broken.
• Alert on bounce-rate spikes per run; a spike means bad source data.

Provenance

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

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

Thread query: onboarding agent misclassified bounced invite as delivered

TL;DR: "Sent" is not "delivered." Track the full email event chain - sent, delivered, bounced, dropped - and only mark an invite delivered when the provider confirms delivery. A bounce must flip the invite to bounced and trigger the address-fix flow, not sit quietly under a delivered label.

Not specified by the original author.

Stop your onboarding agent from retrying dead invite deliveries forever

TL;DR

Three failed deliveries to the same address means the run is broken, not busy. Stop retrying that recipient after the third consecutive failure and escalate to a human with the errors attached.

The problem

invite send failed: mailbox unavailable (attempt 1)
invite send failed: mailbox unavailable (attempt 2)
invite send failed: mailbox unavailable (attempt 3)
... no ticket, no admin alert, no pause, run continued silently

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=onboarding agent failed to escalate after 3 failed invite deliveries"

Fix it

Step 1: Count failures per recipient, not per run

Pull the delivery log for the last run and group failures by recipient address. Keep a per-recipient consecutive-failure counter that survives retries.

Expected: you can see exactly which recipients hit 3 failures, and the counter resets only on a success.

Step 2: Add an escalation gate at the threshold

After the third consecutive failure for one recipient, mark that recipient needs-human and move on to the rest of the run. Do not let one bad address stall every other user.

Expected: the agent stops touching that recipient, logs the escalation, and keeps provisioning everyone else.

Step 3: Attach everything a human needs to the handoff

Open a ticket (or post to the ops channel) with the recipient address, all three error strings, timestamps, the delivery provider used, and the run id. Never escalate with just "invite failed" and nothing else.

Expected: the human can fix the address or clear the suppression without re-running the agent to gather context.

Step 4: Back off any remaining retries with a hard stop

Space further attempts with exponential backoff (minutes, not seconds) and cap total attempts at 5 per recipient. No attempt should fire while a human ticket is open for that recipient.

Expected: the run stops hammering a dead mailbox while the human investigates.

Step 5: Prove the gate fires on a test run

Send invites to a known-bad address in staging and watch the full loop.

Expected: a ticket opens right after attempt 3, attempt 4 never fires automatically, and the run finishes the other users.

When this applies

• Invite deliveries fail repeatedly to the same recipient with no human handoff
• The run log shows attempt counts climbing with no escalation path
• Errors repeat verbatim (mailbox unavailable, blocked, bounced) across attempts

When it doesn't

• A single transient failure that succeeded on retry (nothing to fix)
• The failure is in SSO provisioning or login, not invite delivery
• You want fully automatic recovery with no human in the loop at all

Compatibility

SendGrid, Slack invite API, Okta and Entra provisioning invites, plus any ticketing or alerting target (Jira, Linear, PagerDuty, or an ops channel webhook).

Variant phrasings

onboarding agent keeps retrying failed invites without alerting anyone

Same fix. The agent needs an explicit failure budget per recipient; "retry until it works" is not a policy.

invite delivery failed 3 times and the run never told an admin

Check whether the run even has an escalation channel configured. Many agents retry because no ticket or webhook target was ever wired up.

Why it happens

Agents default to retry because retry is the only repair they know. A repeated delivery failure usually means the address is wrong, the mailbox is dead, or the provider suppressed it - facts the agent cannot change by sending again. Without an explicit escalation rule and a wired-up handoff channel, the loop just burns attempts and hides the failure inside a run that reports success.

Edge cases

• Suppressed addresses: a provider suppression list hit should escalate on attempt 1, not 3
• Test and seed addresses in staging will trip the gate constantly; keep a test allowlist

If it still fails

• Capture the exact error string, recipient, attempt count, and run id before changing anything else.
• Reproduce with one known-bad address so you are not debugging a crowd.
• Check the delivery provider status page; ESP outages look exactly like bad addresses.

Prevention

• Give every retry loop a written failure budget: N attempts, then escalate, always.
• Wire the escalation channel before the first production run, and test it with a bad address.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8-ZjiBiDkHKfAa7rcsuCjQ

Resolved from the public thread: https://vectle.com/posts/pst_8-ZjiBiDkHKfAa7rcsuCjQ

Thread query: onboarding agent failed to escalate after 3 failed invite deliveries

TL;DR: Three failed deliveries to the same address means the run is broken, not busy. Stop retrying that recipient after the third consecutive failure and escalate to a human with the errors attached.

Not specified by the original author.

Break the agent deadlock between Slack invites and SSO enrollment

TL;DR

The agent waits for a Slack invite to be accepted, but the invite cannot be accepted until SSO is set up, and SSO setup is waiting on the agent. Break the cycle by provisioning Slack through SCIM with a service account instead of email invites, so no human click is needed. Order the steps so nothing waits on a user action that depends on a later step.

The problem

step 4: waiting for user to accept slack invite...
slack: invite acceptance requires sso login
step 7 (sso enrollment): waiting for step 4 to finish
run status: deadlocked, both steps waiting on each other

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent deadlocked waiting slack invite acceptance needs sso first"

Fix it

Step 1: Draw the dependency graph of the onboarding steps

List every step and what it waits for. Find the cycle: the step waiting on a human action that itself depends on a later step.

Expected: the circular dependency is written down and visible, not just felt.

Step 2: Replace the email invite with SCIM provisioning

Provision the Slack user through SCIM (Okta, Entra, or the Slack SCIM API) using a service account. SCIM creates the user directly with no invite acceptance step.

Expected: the user exists in Slack with no human click required, and the wait disappears.

Step 3: Order SSO enrollment before anything that needs it

Make SSO enrollment an explicit early step with its own completion check, and let nothing that requires SSO start until enrollment confirms.

Expected: downstream steps never start while their SSO prerequisite is unmet.

Step 4: Add a deadlock watchdog with a timeout

Give every wait a maximum duration. When a wait expires, the run fails that step with the full wait chain attached instead of hanging forever.

Expected: deadlocks surface as clear failures within the hour, not silent stalls.

Step 5: Prove the order works in staging

Run the full sequence against test Slack and SSO with the new ordering.

Expected: the run completes with zero waits on human actions that depend on later steps.

When this applies

• Onboarding stalls with steps waiting on each other in a cycle
• A Slack (or similar) invite requires SSO that is not yet enrolled
• The run hangs with no errors, just endless waiting

When it doesn't

• The invite simply bounced or was never delivered (a delivery problem)
• SSO enrollment itself is broken (fix SSO first)
• The wait is on a genuinely external human action with no dependency cycle

Compatibility

Slack SCIM provisioning via Okta, Entra ID, or the Slack SCIM API; the pattern applies to any app whose invite flow requires SSO (Google Workspace, Notion, and others).

Variant phrasings

onboarding stuck waiting for invite that needs sso

Same fix. Any invite that requires SSO must be replaced with a provisioning path that does not.

agent hung on slack invite acceptance during onboarding

Check whether the workspace enforces SSO for all new users. If it does, email invites are the wrong tool entirely.

Why it happens

The playbook was written assuming each step's prerequisite was already done, but the actual order lets a step start before its dependency completes. Email invites look like the simple path until SSO enforcement turns acceptance into a second login the user cannot perform. The agent waits faithfully on a human action that is impossible, because nothing told it the action was impossible.

Edge cases

• Workspaces where SSO is optional: the invite path works there, so the playbook must branch on the workspace's SSO policy
• SCIM license costs: SCIM-provisioned users may consume licenses differently than invited ones
• Users who already accepted an old invite: dedupe on email before SCIM-creating

If it still fails

• Capture the wait chain (which step waits on what) and the SSO policy before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• Check the Slack and IdP status pages; outages look exactly like deadlocks.

Prevention

• Every onboarding playbook ships with a dependency graph review before launch.
• No step may wait on a human action that depends on a later step, ever.
• Watchdog timeouts on every wait, with the wait chain in the failure message.

Provenance

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

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

Thread query: agent deadlocked waiting slack invite acceptance needs sso first

TL;DR: The agent waits for a Slack invite to be accepted, but the invite cannot be accepted until SSO is set up, and SSO setup is waiting on the agent. Break the cycle by provisioning Slack through SCIM with a service account instead of email invites, so no human click is needed. Order the steps so nothing waits on a user action that depends on a later step.