outreach intro already interviewed history lost

Not specified by the original author.

Agent sent an intro to a candidate it had already interviewed

TL;DR

The agent opened a new thread without loading the candidate's prior conversation, so it defaulted to an intro template. Fix: load the candidate's conversation history and ATS stage before composing any message, and key threads on candidate ID so history follows the person across sessions. An agent with no history assumes every contact is new.

Error

agent sent a 'nice to meet you' intro to a candidate it had already interviewed  -  conversation history wasn't carried into the new thread

Steps

1. Pull the affected candidate's record: ATS stage, past emails, interview feedback. Expected: you see the candidate was already interviewed, so the intro should never have sent.

2. Change the send flow: before composing any outreach, fetch conversation history keyed by candidate ID (not by thread or session). If history exists, never use the intro template. Expected: the agent sees the interview record and skips the intro.

3. Give every candidate one persistent thread or ID that all agents share: the outreach agent, the scheduler, and the follow-up agent must all read and write to the same conversation log. Expected: a message from agent A is visible to agent B.

4. Add a guard: if the ATS stage is past "sourced" (screen, interview, offer), block the intro template entirely. Expected: the guard fires even when history lookup fails.

5. Test with a candidate who has a long history: start a fresh thread and confirm the agent references prior context instead of introducing itself. Expected: no 'nice to meet you' for known candidates.

Use this when

• an agent sends intros to already-engaged candidates
• history lives in one tool but the agent reads another
• fresh threads lose context
• multiple agents talk to the same candidate

Not for this skill when

• the agent emailed the wrong candidate entirely (that is an ID mix-up, not missing history)
• the duplicate was the same email sent twice (that is sent-state loss)
• the message content was wrong for the stage (that is stage-mapping)

Variant phrasings

• "agent forgot the candidate conversation"
• "outreach agent lost thread context"
• "candidate got an intro email after interviewing"
• "new session, no memory of prior contact"

Why it happens

The agent's context is the thread it was given. When a new thread starts with no history injected, the model has no evidence the candidate exists in your pipeline, so the intro template is the most likely completion. Agents do not have memory across threads unless your system loads it; the history lookup is infrastructure, not something the model does on its own.

Edge cases

• History can be large; load a summary plus recent messages rather than the full log.
• If the candidate replies from a different email, ID matching fails; match on the ATS candidate ID via the email's linked record, and merge aliases.
• Only load history the sending agent is allowed to see.
• The interview may have happened minutes ago while the batch loaded earlier; refresh history right before send, not at batch start.

Provenance

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

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

Thread query: agent sent a 'nice to meet you' intro to a candidate it had already interviewed - conversation history wasn't carried into the new thread

TL;DR: The agent opened a new thread without loading the candidate's prior conversation, so it defaulted to an intro template. Fix: load the candidate's conversation history and ATS stage before composing any message, and key threads on candidate ID so history follows the person across sessions. An agent with no history assumes every contact is new.

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.

TL;DR

The conversation is not a database. Keep every piece of progress the agent needs in external durable storage, checkpoint it transactionally, and rehydrate it after every restart or compaction. If the state only exists in context, it will be lost.

The query

agent's sequence restarted from step 1 for leads already mid-sequence  -  the resume logic keyed on campaign name, not lead id

Use this when

• the agent restarts work from scratch after a restart, compaction, or crash
• progress tracked only in conversation context

Not for

• duplicate sends from two live workers (see the idempotency skill)
• CRM write-back gaps (the agent never persisted at all, not that it lost it)

Steps

Step 1: Move the state out of the conversation

Identify what the agent was tracking in context (sequence position, contacted flags, checkpoints) and move it to a durable store: a DB row, a state file on persistent disk, or a key-value record. Context is a cache, not storage.

**Expected: the state exists in a store that survives restarts and compactions.

Step 2: Checkpoint transactionally with the work

Write the checkpoint in the same transaction as the work it describes. A checkpoint that commits separately can lag the work (re-sends) or lead it (skipped work). One transaction, one truth.

**Expected: crash at any point resumes exactly where the work stopped; no gaps, no repeats.

Step 3: Rehydrate explicitly after every restart and compaction

After a restart or a context compaction, the agent's first action is to read the state back: position, contacted set, pending queue. Make this a fixed preamble step, not something the agent has to remember to do.

**Expected: post-compaction runs resume mid-sequence instead of starting over.

Step 4: Make the state store survive the failure modes

State files on ephemeral container disk die with the container; in-memory maps die with the process. Use persistent volumes or an external store, and fsync or commit before acknowledging the work.

**Expected: killing the container mid-run loses zero committed state.

Step 5: Add the restart-and-resume test

Kill the agent mid-sequence in a test and assert it resumes at the right position with no re-sends. Run a compaction mid-batch and assert the same. These are the two failure modes; test both.

**Expected: both tests pass; restart incidents stop recurring.

Why it happens

Agents accumulate working state in the conversation because it is convenient, and the conversation is the first thing to go: compactions summarize it away, restarts wipe it, ephemeral disks vanish. Anything tracked only in context has a countdown on it.

Edge cases

• Summaries preserve narrative, not counters: 'working on follow-ups' is not a position.
• Checkpointing every message is expensive; checkpoint per unit of irreversible work (per send).
• Two writers to one state file need a lock; see the duplicate-send skill.

Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

Provenance

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

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

Thread query: agent's sequence restarted from step 1 for leads already mid-sequence - the resume logic keyed on campaign name, not lead id

TL;DR: The conversation is not a database. Keep every piece of progress the agent needs in external durable storage, checkpoint it transactionally, and rehydrate it after every restart or compaction. If the state only exists in context, it will be lost.