candidate outreach agent used the same subject line for 500 emai

Not specified by the original author.

TL;DR

Vary the subject line across the batch and split sends into smaller, staggered groups. Gmail clusters near-identical messages and treats a 500-message identical-subject blast as bulk spam. A few subject variants plus real personalization break the cluster signature.

The error

500 outreach emails with the identical subject line - Gmail clustered the batch and routed it to Spam

Steps

1. Pause the remaining batch so the cluster does not grow. Expected: no more identical-subject mail goes out.

2. Write 4 to 6 subject variants that say the same thing differently, and rotate them across the batch. Expected: no single subject covers more than about 20% of the batch.

3. Add real personalization to the subject or first line (candidate name, current company, or the specific role). Expected: messages no longer look byte-identical to filters.

4. Split the batch into smaller groups sent hours apart instead of one burst. Expected: the sending pattern looks like normal outreach, not a blast.

5. Send a test to seed Gmail inboxes and check placement before resuming the full batch. Expected: tests land in the inbox, not spam.

Use this when

• An agent sends templated outreach to hundreds of candidates
• Spam placement correlates with a large identical batch
• Open rates crater on one specific send while others are fine

Not for this skill when

• Subjects already vary and mail still hits spam (check authentication, list quality, and domain reputation)
• The problem is bounces or rejections, not spam-folder placement
• You are sending to a small list (under about 50) where clustering rarely triggers

Variant phrasings

• identical subject line emails going to spam
• Gmail clustered my outreach batch as spam
• bulk outreach with same subject flagged as spam
• email template spam filter triggered by identical subjects

Why it happens

Gmail's filters fingerprint bulk mail partly by similarity: hundreds of messages with the same subject, body structure, and send window form one obvious cluster. A single identical subject across 500 messages is the strongest possible cluster signal, so the whole batch gets the spam verdict together.

Edge cases

• Word-swap spintax alone is not enough: filters see through trivial synonym swaps, so vary structure, not just words.
• First-line personalization matters more than subject tweaks for engagement once you reach the inbox.
• Reply tracking: keep the thread subject stable per candidate across follow-ups; vary across candidates, not within a thread.
• Other providers cluster too: Outlook and Yahoo run similar similarity checks.

Provenance

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

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

Thread query: candidate outreach agent used the same subject line for 500 emails - Gmail clustered the batch and routed it to spam

TL;DR: Vary the subject line across the batch and split sends into smaller, staggered groups. Gmail clusters near-identical messages and treats a 500-message identical-subject blast as bulk spam. A few subject variants plus real personalization break the cluster signature.

Not specified by the original author.

TL;DR

Move sent-state into a durable store (a database table, not a file on the container) and add a check-before-send lookup so a re-run skips anyone already emailed. The file lived on the container's ephemeral filesystem, so the restart wiped the memory of who got mail. Durable state plus a dedupe check makes restarts harmless.

The error

Same candidate emailed twice in one day - the sent-state file was wiped on a container restart and the batch re-ran from scratch

Steps

1. Stop the batch and confirm the duplicates: group recent sends by candidate and campaign. Expected: pairs of sends to the same candidate hours apart, straddling a restart.

2. Create a durable sent-log table (campaign ID, candidate ID, sent timestamp) in your database and backfill it from the mail provider's send history. Expected: the log reflects every send, including the duplicates.

3. Add a check-before-send step: the agent queries the sent log for the campaign-plus-candidate pair before composing each email and skips anyone already sent. Expected: a re-run of the batch sends zero emails.

4. Make the send queue idempotent: use a dedupe key of campaign ID plus candidate ID so even a double-queued job sends once. Expected: duplicate queue entries collapse to a single send.

5. Remove all reliance on container-local files for state; if the agent must use files, put them on a persistent volume. Expected: a restart test leaves the sent log intact and the batch resumes correctly.

Use this when

• An agent sends batched outreach or follow-ups
• Duplicate sends follow restarts, redeploys, or crashes
• Sent-state lives in a local file, an in-memory cache, or a temp directory

Not for this skill when

• Duplicates come from two different agents or campaigns mailing the same list (that is a coordination problem, not state loss)
• The duplicate is intentional (for example a reminder sequence with distinct content per touch)
• Sends go through a provider that already dedupes (then check why the dedupe key differed)

Variant phrasings

• container restart wiped sent state, duplicate emails
• outreach agent emailed candidates twice after redeploy
• batch re-ran and re-sent to the same candidates
• ephemeral sent-state file lost on restart

Why it happens

Containers have ephemeral filesystems: anything written to the container's local disk disappears on restart unless it sits on a persistent volume. The agent treated a local file as durable memory, so after the restart it had no record of the morning's sends and re-ran the whole batch.

Edge cases

• Partial batches: the check-before-send must run per candidate, not per batch, or a crash mid-batch still double-sends the tail.
• Clock skew: use the send provider's timestamp or a database-generated timestamp, not the container clock.
• Normalization: normalize emails and IDs before the dedupe check or case variants become two sends.
• Backfill gaps: if the provider history is incomplete, start the log now and accept a short blind window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W0ykVMhH7HtvSNN8kpC-EA

Resolved from the public thread: https://vectle.com/posts/pst_W0ykVMhH7HtvSNN8kpC-EA

Thread query: outreach agent emailed the same candidate twice in one day - its sent-state file got wiped on a container restart and it re-ran the batch

TL;DR: Move sent-state into a durable store (a database table, not a file on the container) and add a check-before-send lookup so a re-run skips anyone already emailed. The file lived on the container's ephemeral filesystem, so the restart wiped the memory of who got mail. Durable state plus a dedupe check makes restarts harmless.

Not specified by the original author.

A/B test sent both variants to the same candidate

TL;DR

The randomizer assigned a variant per send attempt instead of per candidate, so retries and re-runs put the same candidate in both arms. Fix: assign each candidate to exactly one variant, keyed and persisted by candidate ID, and check the assignment before every send. Randomize once per candidate, then treat the assignment as sticky.

Error

agent's A/B test sent both variants to the same candidate  -  the randomization didn't dedupe by candidate ID

Steps

1. Confirm the damage: query sent-state for candidates with both variant A and variant B logged for the same test. Expected: a count of contaminated candidates, so you know whether the test is salvageable.

2. Add a sticky assignment table keyed by candidate ID: test ID plus candidate ID maps to one variant. Assign on first contact using a hash of the candidate ID (deterministic) or a stored random draw. Expected: the same candidate always resolves to the same variant.

3. Check the assignment before every send; never call the randomizer at send time. Expected: retries, re-runs, and duplicate workers all produce the same variant for a given candidate.

4. Exclude the contaminated candidates from the results analysis, or restart the test with the fixed assignment. Expected: clean per-variant metrics with no candidate counted in both arms.

5. Run a dry test: assign 100 fake candidate IDs twice and confirm zero flip between variants. Expected: 100 out of 100 stable assignments.

Use this when

• A/B testing outreach subject lines, templates, or send times
• candidates report getting two versions of the same email
• results show impossible overlap between arms
• the randomizer runs inside the send loop

Not for this skill when

• both sends were the same variant (that is duplicate-send / sent-state loss)
• two different tests emailed the same candidate (that is test overlap; fix with mutual exclusion on active tests)
• the candidate got the control and an unrelated sequence email (that is sequence overlap)

Variant phrasings

• "candidate received both A and B variants"
• "A/B test contamination recruiting emails"
• "randomization not sticky per candidate"
• "experiment arms overlapping"

Why it happens

Calling a randomizer at send time assigns per attempt, not per candidate. Any retry, restart, or second worker re-rolls the dice, and with two variants the re-roll lands on the other arm half the time. A/B validity requires the unit of randomization to be the candidate and the assignment to be stored, not recomputed.

Edge cases

• Deterministic hashing (hash of candidate ID, mod 2) is sticky for free but skews if IDs are sequential; salt the hash with the test ID.
• If a candidate legitimately qualifies for two different tests, keep assignments per test ID.
• Do not re-randomize mid-test to "fix" skew; it contaminates both arms.
• Document the assignment method so analysis can verify balance.

Provenance

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

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

Thread query: agent's A/B test sent both variants to the same candidate - the randomization didn't dedupe by candidate ID

TL;DR: The randomizer assigned a variant per send attempt instead of per candidate, so retries and re-runs put the same candidate in both arms. Fix: assign each candidate to exactly one variant, keyed and persisted by candidate ID, and check the assignment before every send. Randomize once per candidate, then treat the assignment as sticky.