outreach do not contact list stale

Not specified by the original author.

TL;DR

Local notes are invisible to the next agent. The CRM is the shared source of truth. Every send must write its outcome back to the CRM in the same run (contact timestamp, sequence step, message ID) before the lead is considered done. Make the write-back part of the send transaction, verify it landed, and have the next run build its send list from CRM state, not from the agent's memory.

The query

agent marked leads as contacted in its own notes but never wrote back to the CRM, so the next shift's agent emailed all of them again

Use this when

• Contacted leads get re-emailed by the next run, shift, or agent instance.
• The agent tracks contact state in local files, notes, or conversation memory.
• The CRM's activity history disagrees with what the agent believes it sent.

Not for

• CRM API rate limits dropping write-backs (that is a throttling problem).
• Duplicate sends from parallel workers (that is a locking problem).
• Suppression-list misses (that is a list-hygiene problem).

Steps

Step 1: Confirm the gap between notes and CRM

echo "agent notes say contacted: $(wc -l agent-notes.txt)"
echo "CRM activities logged: $(grep -c 'email_sent' crm-export.csv)"

Expected output: the two counts disagree, with the agent's count higher. The difference is the set of leads the next shift re-emailed. Export the CRM activity history for those leads to build the backfill list.

Step 2: Add a write-back step immediately after each send

# the send is not done until the CRM knows about it
message_id = send_email(lead)
crm.log_activity(
    contact_id=lead["crm_id"],
    activity_type="email_sent",
    timestamp=now(),
    message_id=message_id,
    sequence_step=current_step,
)

Expected output: every send produces a CRM activity record in the same run. The activity carries the message ID so duplicates are detectable later, and the sequence step so the next run knows where the lead is.

Step 3: Verify the write landed

python -c "from crm import get_activities; print(len(get_activities('[crm id]')))"

Expected output: the activity count for the test lead increased by one. A write-back that is not verified is a hope, not a record. Read-back verification catches silent API failures.

Step 4: Build the next send list from CRM state

SELECT lead_id, email FROM leads
WHERE lead_id NOT IN (
  SELECT contact_id FROM crm_activities
  WHERE activity_type = 'email_sent'
);

Expected output: the send list excludes every lead the CRM knows was contacted (narrow the activity window to the last 14 days for sequence re-entry rules). The next shift's agent starts from this query, not from anyone's notes. Local state is never consulted.

Step 5: Make CRM-write failure block the local done-mark

# if the CRM write fails, the lead stays unsent locally too
try:
    crm.log_activity(...)
except CRMError:
    retry_with_backoff(lambda: crm.log_activity(...))
    mark_unsent(lead)  # do not advance; the next run retries the send

Expected output: a failed write-back never produces a locally-done lead. The lead is retried (send plus write-back together) on the next run instead of being silently dropped or double-sent.

Step 6: Backfill the missing history

python backfill_activities.py --from agent-notes.txt --dry-run

Expected output: a dry-run report of the activities that would be created from the agent's notes. Review it, then run without the flag. The backfill stops the bleeding for already-contacted leads while steps 2-5 prevent the next incident.

Variant phrasings

agent lost track of sequence position after a context compaction

Same local-state death, different cause. The sequence position must live in the CRM (or the sequence tool), not in the agent's context.

scheduled cron restarted the agent mid-run and it re-enrolled 800 leads

The checkpoint row was never committed. Steps 2 and 5 make the checkpoint (the CRM write) part of the send itself.

outreach agent re-contacted candidates from a 6-month-old campaign

The suppression state lived outside the system of record. Same principle: one source of truth, written at send time.

Why it happens

Agents optimize for their own run's success: the notes are complete, the sends went out, the run looks green. But the notes die with the process, and the next agent starts from the CRM, which knows nothing. The write-back was treated as bookkeeping to do later, and later never came. Contact state is not metadata about the send. It is the send, as far as every future agent is concerned.

Edge cases

• If the CRM API is down, the agent must queue the write-backs durably (not in memory) and flush them before the next send list is built. An in-memory retry queue dies with the process and recreates the original bug.
• Backfilling from notes can create duplicate activities if some sends did write back. Dedupe the backfill on message ID before creating activities.
• The send list query in step 4 must account for the CRM's indexing lag. A write-back from five minutes ago may not be queryable yet. Add a small grace window or read-your-writes check.
• When two tools both write activities (the agent and the sequence platform), agree on one activity type per send. Two activity types for one email breaks the exclusion query.
• Do not backfill and then delete the notes. Keep the notes as the audit trail of what the agent believed, alongside the CRM as the system of record.

Provenance

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

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

Thread query: agent marked leads as contacted in its own notes but never wrote back to the CRM, so the next shift's agent emailed all of them again

TL;DR: Local notes are invisible to the next agent. The CRM is the shared source of truth. Every send must write its outcome back to the CRM in the same run (contact timestamp, sequence step, message ID) before the lead is considered done. Make the write-back part of the send transaction, verify it landed, and have the next run build its send list from CRM state, not from the agent's memory.

Not specified by the original author.

Outreach agent re-contacted opted-out candidates from an old campaign

TL;DR

The agent re-emailed people who opted out because the suppression list was a spreadsheet nobody loaded into the sending pipeline. Fix: move the do-not-contact list into the system the agent queries before every send, and make the suppression check a blocking gate. A list the send path never reads is not a suppression list.

Error

outreach agent re-contacted candidates from a 6-month-old campaign  -  the do-not-contact suppression list lived on a spreadsheet nobody loaded, so the opt-outs were never honored

Steps

1. Export the spreadsheet and count the entries; then check how many of those addresses appear in recent sends. Expected: you know exactly how many opt-outs were violated.

2. Import the list into your sending system or a suppression table the agent can query: email (lowercased, trimmed), opt-out date, source. Dedupe on the normalized email. Expected: one authoritative list, no duplicates.

3. Add a blocking gate in the send flow: normalize the recipient, check suppression, abort the send on a hit, log the skip. Expected: a suppressed address can never be sent to, no matter which campaign or agent tries.

4. Retire the spreadsheet: point everyone who used to edit it at the new list, and mark the old file clearly so it stops being "the list" in anyone's head. Expected: one source of truth.

5. Test with a suppressed address and a fresh address. Expected: suppressed aborts with a logged skip; fresh sends normally.

Use this when

• opt-outs get emailed again
• suppression data lives in spreadsheets, docs, or someone's inbox
• multiple agents or campaigns share one audience
• compliance wants proof of honoring opt-outs

Not for this skill when

• the suppression list was loaded but the check ran after the send (that is ordering)
• the opt-out arrived as a reply the classifier missed (that is the reply-classifier problem)
• the candidate never opted out and just got too many emails (that is frequency policy)

Variant phrasings

• "suppression list not loaded"
• "opted-out candidates emailed again"
• "do not contact list ignored by agent"
• "unsubscribe spreadsheet never synced"

Why it happens

The spreadsheet was the process for a human team, and nobody rebuilt the process when the agent took over sending. The agent can only enforce rules that live in systems it reads; a file on someone's drive is invisible to it. Every manual list that matters to sending must become a queried table with a blocking check.

Edge cases

• Emails change; also suppress on candidate ID or phone where you have them, not email alone.
• Keep the opt-out record even if the candidate later re-applies; stopping outreach is separate from recruiting them inbound.
• If the list updates from a form, the gate must read the live table, not a cached copy.
• Log every suppressed skip; auditors ask for this.

Provenance

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

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

Thread query: outreach agent re-contacted candidates from a 6-month-old campaign - the do-not-contact suppression list lived on a spreadsheet nobody loaded, so the opt-outs were never honored

TL;DR: The agent re-emailed people who opted out because the suppression list was a spreadsheet nobody loaded into the sending pipeline. Fix: move the do-not-contact list into the system the agent queries before every send, and make the suppression check a blocking gate. A list the send path never reads is not a suppression list.

Not specified by the original author.

TL;DR

Fix this in Apollo by acting on the exact message first: cross check org chart contacts against current employment, remove people who have left from reporting lines, and reassign the reporting contact to the current role holder before outreach. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one record, then rerun the full scope and reconcile the counts.

Apollo org chart error, a departed VP was still listed as a reporting contact, enrichment outdated

Use this when

• The operation in Apollo fails with this exact message: Apollo org chart error, a departed VP was still listed as a reporting contact, enrichment outdated.
• The same failure repeats on retry with unchanged inputs.
• A run, import, export or alert is blocked until this item completes.

Not for this skill when

• The message is a permission or platform outage notice. 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 Apollo, and copy the full message plus the record, account or list involved into the run notes. Verify: the error is reproduced on demand with a named record, not only seen in a log.
2. Apply the specific fix for this error: cross check org chart contacts against current employment, remove people who have left from reporting lines, and reassign the reporting contact to the current role holder before outreach. Verify: one named record now completes end to end with the correct result and the original message does not appear.
3. Check the neighbouring records that share the same source, mapping, workspace or settings, because this class of failure rarely affects only one record. Verify: the neighbouring records are listed and each is marked affected or clear.
4. Compare the result counts, fields or alerts against the source in Apollo so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in Apollo 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 record so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Org charts are snapshots that decay as people move, and enrichment refreshed company data without rechecking whether the named people still held those roles.

Variant phrasings

Apollo org chart error, a departed VP was still listed as a reporting contact, enrichment outdated

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

How to fix this failure in Apollo

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

Troubleshooting this failure in Apollo

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: Apollo 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/pst_hAOli7SPSZ1af14BGMLMlA

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

Thread query: Apollo org chart error departed VP still listed as reporting contact enrichment outdated

TL;DR: Fix this in Apollo by acting on the exact message first: cross check org chart contacts against current employment, remove people who have left from reporting lines, and reassign the reporting contact to the current role holder before outreach. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one record, then rerun the full scope and reconcile the counts.