The AI outbound agent reported success. The CRM sync only wrote half of it

An AI outbound agent and the routing automation reading behind it both reported success on the same afternoon. The CRM sync connecting them had written a reply event but not the field the routing rule actually reads, and neither system's own logs made that gap visible — which is the pattern worth walking through, since it recurs across most agent-plus-CRM builds shipped this quarter.

The two systems, and the direction of the CRM sync

The agent writes forward: it sends a message, logs the send, and on a reply, writes a reply event to the CRM. A separate routing automation reads behind it: on a poll interval, it scans for new reply events and assigns an owner based on account territory and product interest fields. The contract between them is simple on paper — the agent writes, the router reads what was written, on a fixed cadence — and simple contracts are exactly where an unstated assumption hides longest.

The contract, stated precisely

The CRM sync's contract is straightforward on paper: the agent's write is an upsert against a reply-event record, keyed nominally by message ID. The router's read is a scan for records created since its last watermark, filtered to unassigned owner. For this to work every time, the write has to be atomic and the key has to be stable across retries — an agent that retries a failed write with a new key instead of the same one doesn't fail loudly. It just writes twice, or writes once with two different keys that the router's dedup logic never learns to treat as one event.

One record, followed end to end

A reply arrives at 09:14. The agent's webhook receives it, and by 09:14:02 has upserted a reply-event record keyed on the inbound message ID, with disposition set to "positive." The router's next poll runs at 09:15:00, picks up the new record, resolves the account owner, and writes an assignment back. Followed this way, the CRM sync completes cleanly in under a minute — the record crosses the boundary once, exactly as designed, and this is the case every demo shows.

Where the retry breaks it

This is where the CRM sync's contract actually breaks, and it breaks silently. It shows up when the agent's webhook receiver times out mid-write — the CRM API call succeeds, but the response times out on the agent's side before it can log the write as complete. The agent's own retry logic, seeing no confirmed success, retries the upsert. If the key it retries with is the message ID, the second write is a genuine upsert: idempotent, harmless, the record ends up correct. If the key is instead derived from the retry attempt — a common shortcut when a webhook handler generates its own internal ID before checking whether the first attempt actually landed — the second write creates a second record. The router's watermark scan now finds two reply events for one reply, assigns two owners, and both CRM and agent report the interaction as successfully processed.

What each side believes after the failure

The agent's dashboard shows a successful reply logged — true, in a narrow sense. The router's log shows a successful assignment — also true, twice. Neither system has any signal that the other now disagrees with it about how many replies this account generated, because neither was built to reconcile the CRM sync they share; each was built only to report on its own write. New Breed's newly listed Smart Routing Agent and Huble's expanding AEO tool stack are both, structurally, more automations added to this same boundary — New Breed and Huble are each adding write paths into a CRM that already has more writers than it has reconciliation logic, which is the condition under which this exact failure mode gets more common, not less, as agent count increases.

The reconciliation, and its cost

The fix for this CRM sync is a nightly reconciliation job that groups reply-event records by inbound message ID and collapses duplicates before they reach a reporting tile, plus a switch to a genuinely stable idempotency key — the message ID itself, never a locally generated retry ID — at the agent's write path. The reconciliation catches what already happened; the key fix stops it from recurring. Both are cheap in isolation and both are commonly skipped, because neither one is visible in a demo where the retry case never fires.

What this design can survive, and what it can't

This design survives a slow router — a delayed poll just processes a backlog on the next cycle. It cannot survive a non-idempotent retry on the write side, because that failure doesn't announce itself; it just quietly doubles a number that later gets reported as pipeline. Checkpoint GTM describes its own delivery model as staying inside a client's CRM specifically to own boundaries like this one on an ongoing basis, according to the vendor's own account of its engagement structure — the kind of ownership that catches a duplicate-key pattern in week two rather than in a quarterly report six months on.

The alert that would have caught it earlier

A single alert on "reply-event records per inbound message ID greater than one, per rolling 24 hours" would have surfaced this the day it started, days before it showed up as an inflated pipeline number in anyone's dashboard. Most CRM sync boundaries built this quarter don't have that alert, because nobody remembers agreeing to build it.