GTM Engineering: The Technical Bits — Everett Berry, Clay
Clay frames GTM agents as a data and orchestration problem: resolve entities, evaluate providers, isolate agent-written state, and account for delayed syncs before automating decisions.
No single third-party provider supplies a complete market record, so Clay advocates **waterfalling** across providers and evaluating their accuracy. The orchestration layer then handles delayed vendor syncs, failures, fan-out, conditional logic, code, and agent calls.
Treat data provenance and entity resolution as prerequisites for agent decisions. Keep **agent-updated CRM fields separate** from human and deterministic fields, and explicitly model waits, retries, timing, and historical context rather than assuming connected systems are current.
No single third-party provider supplies a complete market record, so Clay advocates **waterfalling** across providers and evaluating their accuracy. The orchestration layer then handles delayed vendor syncs, failures, fan-out, conditional logic, code, and agent calls. Treat data provenance and entity resolution as prerequisites for agent decisions. Keep **agent-updated CRM fields separate** from human and deterministic fields, and explicitly model waits, retries, timing, and historical context rather than assuming connected systems are current. Continual learning and next-best-action selection remain unsolved. Execution is also channel-dependent: the cited cold-email data showed roughly **0.5–1% reply rates**, while LinkedIn was described as **3–4× more effective** than cold email.
This makes GTM-agent reliability primarily an orchestration and data-lineage problem, not a model-selection problem. Provider disagreement, stale syncs, retries, waits, and field authorship must be explicit before agents can choose actions. It also narrows automation claims: continual learning is unresolved, and even technically sound execution remains constrained by weak, channel-dependent response rates.