GTM engineering removes the technology constraints that stop go-to-market teams from shipping changes as quickly as product and engineering teams.
2
Reliable GTM automation needs a data layer that combines providers, updates fields at different rates, resolves entities, and tracks changing accounts.
3
Agents can reason over an account for weeks or months, but execution still has to handle human approval, domain reputation, reply routing, and coordination with sales reps.
Summary
Everett Berry describes GTM engineering as the technical work needed to let go-to-market teams ship data, automations, and campaigns at an engineering-like pace. He focuses on four problems. Data must track companies that are constantly changing, while combining incomplete information from many vendors and keeping update costs under control. Orchestration must connect ten to thirty tools with different data volumes, schedules, and failure modes. Agents need persistent state for each account, smart triggers, feedback, and separate CRM fields from those updated by people or deterministic systems. Execution is harder because outreach affects domain reputation, reply rates are low, and activity across email, calling, and marketing campaigns must stay coordinated. In the question period, Berry says the hardest part is the interface between agents and sales reps. Humans still need to understand what automation did before speaking with prospects.
GTM engineering lets go-to-market teams ship at an engineering-like pace
Berry says GTM teams have realized they can ship as fast as product and engineering teams. At Clari, he describes pushing new data, automations, and campaigns every two weeks while iterating on what they release. He defines the role as removing the technology constraints that have historically slowed GTM work. In his view, the growth of the role tracks advances in AI because more capable models give GTM engineers more leverage inside their organizations. He frames the talk as a review of technical problems for engineers, GTM engineers, and founders building in this area.
A useful GTM data layer must model accounts as changing state
Berry describes the goal of GTM data as a perfect virtual copy of the market, including target accounts and contacts. That copy is difficult because companies are always changing. An account can be acquired, open offices, launch products, hire people, or fire people. The GTM team's own marketing, sales activity, and meeting attempts also change the account's state. A CRM therefore needs fields that describe whether an account is a customer, expanding, or churning, along with its size and score. Berry starts by filling accounts with contacts, then adds account hierarchy, firmographics, technographics, and signals that indicate which companies to pursue.
Waterfalling combines incomplete providers and requires data evaluations
Berry says hundreds of vendors provide GTM data, but none has a complete view. Waterfalling means querying several providers in sequence to fill missing fields. His example uses phone numbers across a set of countries: relying only on Forager gets about half of the numbers, so other providers must be layered on. A vendor or its customer has to run evaluations against providers to learn which sources produce the most accurate information. The data layer also combines first-party and third-party information, selects which fields to refresh because purchased data is expensive, and resolves the different representations of one account across providers.
Orchestration is a distributed data engineering problem
Most GTM teams use many systems, including a CRM, data warehouse, sequencer, dialer, call note taker, and chat interface. Berry usually sees ten, twenty, or thirty tools, and their views of the world differ. Some need one record updated in real time, while others need hundreds of thousands of records updated daily. Employee count may change often, while headquarters location changes rarely. One system may also need to fan information out to several others, and failures occur across the distributed setup. Berry gives the example of a CRM syncing independently with Outreach or another sequencer, which forces an orchestration system to wait and check whether a contact is ready.
A graph of general-purpose nodes can coordinate GTM systems
Clay's approach treats orchestration as a graph made from general-purpose nodes. Some nodes run agents, some make tool calls, some handle conditionals, and others run code. A map-reduce-style node can fan information out and bring it back together. Berry's example starts with an event, trigger, or schedule, gathers information from several systems, combines it, and sends the result to the interfaces used by reps. He presents this graph structure as a way to build or buy an orchestration layer that can handle the different operations and data flows in a GTM stack.
Long-running agents need persistent account state and controlled wakeups
Berry describes an agent for each account that maintains persistent state across a deal cycle lasting weeks or months. These agents are dormant most of the time, so a trigger or heartbeat must wake them. When active, an agent ingests current context from the data and orchestration layers, reasons about what to do, and can update agent-specific CRM fields. Berry recommends separating fields updated by agents from fields updated by deterministic systems or people. Agents also need feedback, and continual learning plus next-best-action suggestions remain unsolved areas. Timing matters too. After a lost account, an agent may wait before trying to act on it again.
Outreach execution has low reply rates and real domain costs
Berry says cold email has become less effective over time. He cites a SmartLead snapshot across about 20 million emails, with reply rates between roughly half a percent and one percent. LinkedIn can be three to four times more effective than cold email in the comparison he shows, while cold calling and cold email are roughly similar. These rates leave little room for agents to make poor decisions. Sending as a rep can make the message feel direct, but bad sending can damage the company's domain reputation. Using multiple domains reduces that exposure, then creates a routing problem because replies must reach the main domain and the appropriate reps.
The hardest interface is between an agent's actions and the sales rep
In the question period, Berry identifies the human-agent interface as one of the hardest problems. Agents can act as the reasoning and decision layer for tasks that sales reps previously handled, but a rep may disagree with an agent's decision or may not know what the agent already did. The rep still has to speak with the prospect, so the automated system's actions and the rep's actions need to fit together. Berry also says GTM engineering applies to inbound as well as outbound. Inbound creates its own orchestration problems around routing, account qualification, and understanding historical context.
"GTM engineering at its heart is really about removing the constraints that have historically stopped GTM teams from shipping at speed using technology."01:11
Who should watch
You are building a GTM data layer and need to combine several providers without refreshing every field at the same rate.
Your automation spans a CRM, sequencer, dialer, warehouse, and other tools that sync independently and fail in different ways.
You are deploying agents for account work and need to decide how persistent state, rep visibility, reply routing, and domain protection should work.
