agent failed to detect the duplicate: cached the stale company list

Not specified by the original author.

TL;DR

The agent cached the company list hours ago and matches new records against stale data, so recently created companies never match. Set a short TTL on the cache, invalidate it whenever the agent writes companies, and refresh before each matching run. The matching logic is fine; its input is old.

Error

(No error; the symptom is duplicates the agent should have caught, all involving recently created companies.)

Steps

1. Check the cache timestamp versus the missed duplicates' creation times. Expected: the cache predates them.
2. Set a TTL on the company cache (minutes, not hours, for active orgs). Expected: staleness bounded.
3. Invalidate the cache on every company write the agent performs. Expected: the agent always sees its own writes.
4. Refresh the cache at the start of each matching run regardless of TTL. Expected: runs start from current data.
5. Log cache age with match results for audit. Expected: future misses are diagnosable.

When to use

• Duplicates missed involving recent records.
• An agent caches reference data for performance.
• After bulk imports, matching degrades.

When not to use

• Matching logic errors (normalize and block first).
• Real-time requirements (then do not cache at all).

Tool compatibility

• Any agent-side cache; HubSpot and Salesforce list APIs.
• TTL and invalidation logic.

Variant phrasings

stale cache missed duplicates

Shorten TTL; invalidate on write.

matching against old data

Refresh before each run.

Why it happens

Caching trades freshness for speed. Dedupe is exactly the workload where freshness matters most, so the tradeoff bites hardest here.

Edge cases

• Very active orgs need TTLs in minutes; quiet orgs can use longer.
• Writes from other systems do not invalidate your cache; TTL is the backstop.
• Cache stampedes on refresh can spike API usage; refresh once per run, not per record.

Provenance

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

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

Thread query: agent failed to detect the duplicate: cached the stale company list

TL;DR: The agent cached the company list hours ago and matches new records against stale data, so recently created companies never match. Set a short TTL on the cache, invalidate it whenever the agent writes companies, and refresh before each matching run. The matching logic is fine; its input is old.

Not specified by the original author.

TL;DR

Fix this in Enrichment agent by acting on the exact message first: check the age of any cached response before a retry uses it, invalidate the cache for records being retried, and compare response timestamps against the golden record before writing. 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.

Agent overwrote golden record fields after an enrichment retry used a stale cached response

Use this when

• The operation in Enrichment agent fails with this exact message: Agent overwrote golden record fields after an enrichment retry used a stale cached response.
• 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 Enrichment agent, 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: check the age of any cached response before a retry uses it, invalidate the cache for records being retried, and compare response timestamps against the golden record before writing. 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 Enrichment agent 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 Enrichment agent 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

The retry wrote older cached data over newer verified values because nothing compared the age of the response with the record it was overwriting.

Variant phrasings

Agent overwrote golden record fields after an enrichment retry used a stale cached response

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 Enrichment agent

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 Enrichment agent

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: Enrichment agent 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/pstdXdWL23gniJGIDjljNWGg

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

Thread query: agent overwrote golden record fields after enrichment retry used stale cached response

TL;DR: Fix this in Enrichment agent by acting on the exact message first: check the age of any cached response before a retry uses it, invalidate the cache for records being retried, and compare response timestamps against the golden record before writing. 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.

Not specified by the original author.

TL;DR

Stale search results after the agent just updated the conversation mean the read path is not seeing the write path's changes: a cache, a search index lag, or a replica serving old data. Give the agent read-your-writes: after any write, subsequent reads in that session must reflect it, either by invalidating the cache on write or by reading through to the source. The agent should never be surprised by its own actions.

The query

agent's intercom search returned stale conversation state

Use this when

• Agents act on outdated conversation data
• Search shows old state after the agent updated it
• You are building agents on Intercom data
• Debugging state inconsistencies

Not for

• Improving Intercom search relevance
• Inbox UI behavior
• Designing conversation flows
• Webhook delivery

Steps

1. Confirm the staleness with a write-then-read test

Update a conversation, then immediately search for it and compare. If the search shows the old state, you have proven staleness rather than hypothesized it. The test also measures the lag duration.

Expected output: measured staleness window.

2. Invalidate caches on write

Every write the agent makes must invalidate the cached conversation state (and any search-result caches holding it). Write-through or write-invalidate: pick one and apply it uniformly. Stale caches are the most common cause.

Expected output: write-triggered cache invalidation.

3. Read through to the source after writes

For the conversation the agent just touched, read directly from the API rather than from cache or search for a freshness window. Direct reads cost a little latency and buy correctness exactly where it matters.

Expected output: read-through for recently written conversations.

4. Account for search index lag explicitly

Search indexes lag behind the source by design. Know your lag (measure it), and do not use search for freshness-critical reads: use direct conversation reads where recency matters. Search is for discovery; direct reads are for truth.

Expected output: documented index lag with read-path routing.

5. Version-stamp reads and detect conflicts

Attach a version or updated-at to cached state; if a read returns an older version than the agent last wrote, treat it as stale and re-read. Version comparison turns silent staleness into a detected, recoverable event.

Expected output: version-stamped state with staleness detection.

Template: the checklist

Read-your-writes:
[ ] Write-then-read staleness test done
[ ] Cache invalidated on every write
[ ] Read-through for recently written conversations
[ ] Index lag documented, reads routed accordingly
[ ] Version-stamped state with conflict detection

Variant phrasings

intercom search shows old conversation data

Steps 1 and 4. Measure, route around index lag.

agent acting on stale state

Steps 2 and 3. Invalidate, read through.

search results outdated after update

Steps 2 and 5. Invalidation plus version stamps.

Why it happens

Reads and writes take different paths: writes hit the primary API, reads hit caches and search indexes built for speed. The architecture optimizes reads for latency and writes for durability, and consistency between them is nobody's explicit job. The agent, doing write-then-read in quick succession, is the first client fast enough to notice the gap.

Edge cases

• Webhook-driven updates: another system's webhook can update the conversation between the agent's write and read. Version stamps catch this too.
• Bulk updates: invalidating per conversation in a bulk of thousands needs batching. Invalidate in bulk-aware ways.
• The lag that grows: index lag is not constant; it spikes under load. Monitor lag, do not assume the measured value.
• Eventual consistency as a feature: some staleness is by design. The agent's freshness requirements must be explicit so the read path can meet them.

Provenance

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

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

Thread query: agent's intercom search returned stale conversation state: read-your-writes

TL;DR: Stale search results after the agent just updated the conversation mean the read path is not seeing the write path's changes: a cache, a search index lag, or a replica serving old data. Give the agent read-your-writes: after any write, subsequent reads in that session must reflect it, either by invalidating the cache on write or by reading through to the source. The agent should never be surprised by its own actions.