--- schema: 1 type: video title: 'GTM Engineering: The Technical Bits — Everett Berry, Clay' description: >- Ask one data vendor for phone numbers across a set of countries and you get about half of them. Hence waterfalling: layer provider on provider until the field is filled, and run evals to know which to trust. Everett Berry's tour of the hard parts of GTM engineering starts with data, because the goal is a perfect virtual copy of your market and accounts refuse to hold still. A company gets acquired, opens offices, ships products, hires and fires while your own team markets and sells at it, and each of those changes the record. Refreshing everything is expensive when you buy the data, so you pick which fields update and how often. Orchestration is the second problem, and it is data engineering. Berry usually finds teams running twenty or thirty tools whose views of the world disagree: some need one record in real time, others hundreds of thousands nightly; employee count moves constantly, headquarters almost never. Worse, those tools sync to each other behind your back, so a contact created in the CRM must reach the sequencer before you can act on it. Clay's answer is a graph of general purpose nodes: agents, tool calls, conditionals, code, and a map reduce fan out. Third is agents, one per account, dormant most of the time, woken by a trigger, holding state across a deal cycle of weeks. Fourth is execution, where the constraints turn human. Send as the rep and a campaign that lands badly burns your domain reputation, so you spread across domains and then route the replies home. Speaker info: - https://x.com/retttx - https://www.linkedin.com/in/everettberry - https://retttx.com Timestamps: 0:00 - What GTM engineering is, and why the role exploded 2:59 - Data, and why accounts never hold still 4:51 - Waterfalling across hundreds of vendors 6:19 - Orchestration across twenty or thirty tools 7:37 - Different systems, different refresh needs 8:27 - When your tools sync behind your back 9:05 - A graph of general purpose nodes 10:23 - One long running agent per account 14:39 - Execution, and the domain reputation problem 17:12 - Q&A: the hardest part is the human interface canonical: 'https://liquidgold.cc/watch/UhCY231d0FQ' markdown: 'https://liquidgold.cc/watch/UhCY231d0FQ.md' llms: 'https://liquidgold.cc/watch/UhCY231d0FQ/llms.txt' parent: 'https://liquidgold.cc/channel/aidotengineer.md' channel: aidotengineer updated: '2026-10-24T04:50:40.083Z' language: null children: [] videoId: UhCY231d0FQ durationSeconds: 1144 publishedAt: '2026-08-26T13:30:31.000Z' searchChunks: - ordinal: 0 text: null startSeconds: 23 endSeconds: 183 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=23' heldReason: rights - ordinal: 1 text: null startSeconds: 23 endSeconds: 183 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=23' heldReason: rights - ordinal: 2 text: null startSeconds: 23 endSeconds: 183 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=23' heldReason: rights - ordinal: 3 text: null startSeconds: 194 endSeconds: 292 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=194' heldReason: rights - ordinal: 4 text: null startSeconds: 303 endSeconds: 384 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=303' heldReason: rights - ordinal: 5 text: null startSeconds: 303 endSeconds: 384 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=303' heldReason: rights - ordinal: 6 text: null startSeconds: 394 endSeconds: 458 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=394' heldReason: rights - ordinal: 7 text: null startSeconds: 458 endSeconds: 470 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=458' heldReason: rights - ordinal: 8 text: null startSeconds: 526 endSeconds: 549 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=526' heldReason: rights - ordinal: 9 text: null startSeconds: 549 endSeconds: 560 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=549' heldReason: rights - ordinal: 10 text: null startSeconds: 560 endSeconds: 625 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=560' heldReason: rights - ordinal: 11 text: null startSeconds: 636 endSeconds: 887 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=636' heldReason: rights - ordinal: 12 text: null startSeconds: 636 endSeconds: 887 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=636' heldReason: rights - ordinal: 13 text: null startSeconds: 636 endSeconds: 887 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=636' heldReason: rights - ordinal: 14 text: null startSeconds: 887 endSeconds: 898 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=887' heldReason: rights - ordinal: 15 text: null startSeconds: 898 endSeconds: 1032 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=898' heldReason: rights - ordinal: 16 text: null startSeconds: 636 endSeconds: 887 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=636' heldReason: rights - ordinal: 17 text: null startSeconds: 1032 endSeconds: 1044 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=1032' heldReason: rights - ordinal: 18 text: null startSeconds: 1044 endSeconds: 1144 watch: 'https://liquidgold.cc/watch/UhCY231d0FQ?t=1044' heldReason: rights --- # GTM Engineering: The Technical Bits — Everett Berry, Clay Ask one data vendor for phone numbers across a set of countries and you get about half of them. Hence waterfalling: layer provider on provider until the field is filled, and run evals to know which to trust. Everett Berry's tour of the hard parts of GTM engineering starts with data, because the goal is a perfect virtual copy of your market and accounts refuse to hold still. A company gets acquired, opens offices, ships products, hires and fires while your own team markets and sells at it, and each of those changes the record. Refreshing everything is expensive when you buy the data, so you pick which fields update and how often. Orchestration is the second problem, and it is data engineering. Berry usually finds teams running twenty or thirty tools whose views of the world disagree: some need one record in real time, others hundreds of thousands nightly; employee count moves constantly, headquarters almost never. Worse, those tools sync to each other behind your back, so a contact created in the CRM must reach the sequencer before you can act on it. Clay's answer is a graph of general purpose nodes: agents, tool calls, conditionals, code, and a map reduce fan out. Third is agents, one per account, dormant most of the time, woken by a trigger, holding state across a deal cycle of weeks. Fourth is execution, where the constraints turn human. Send as the rep and a campaign that lands badly burns your domain reputation, so you spread across domains and then route the replies home. Speaker info: - https://x.com/retttx - https://www.linkedin.com/in/everettberry - https://retttx.com Timestamps: 0:00 - What GTM engineering is, and why the role exploded 2:59 - Data, and why accounts never hold still 4:51 - Waterfalling across hundreds of vendors 6:19 - Orchestration across twenty or thirty tools 7:37 - Different systems, different refresh needs 8:27 - When your tools sync behind your back 9:05 - A graph of general purpose nodes 10:23 - One long running agent per account 14:39 - Execution, and the domain reputation problem 17:12 - Q\&A: the hardest part is the human interface Canonical: https://liquidgold.cc/watch/UhCY231d0FQ · Channel: [AI Engineer](https://liquidgold.cc/channel/aidotengineer.md) > Search chunk text is held until public-source provenance is verified. ## Document chunks > Missing: no stored document chunks are available.