Everett Berry led GTM engineering at Clay at the time of his World’s Fair 2026 appearance, bringing software and data engineering to sales and growth operations. Earlier, he co-founded the computer-vision company Perceive and worked in growth at Arctype and Vantage. His work addresses the practical details that determine whether automation can serve customers: changing account records, synchronization delays, agents that retain context over months, and coordination with human salespeople.
From computer vision to growth
Berry earned a BS in computer engineering from Purdue University and worked with Yung-Hsiang Lu’s HELPS research lab. He co-founded Perceive with Kyle McNulty, Andrew Blejde, and Lu, developing video analytics to understand human interactions in physical stores. The company aimed to help retailers assess customer service continuously, rather than relying on occasional observations by managers or mystery shoppers.
As Perceive’s chief technology officer, Berry worked on software that measured interactions between store associates and shoppers. The company received National Science Foundation support, including a $750,000 Phase II SBIR grant after an earlier Phase I award. By November 2019, Berry was its chief executive, and its vision software addressed foot traffic, customer–employee interactions, operational efficiency, investigations, and safety. These applications turned information in business video into measurements and alerts that could inform operational decisions.
He subsequently worked in growth at Arctype and then became head of growth at Vantage. His personal account of that career also describes technical writing and former maintenance of ec2instances.info, an instance-comparison site. Those roles extended his experience from building technical products to helping people discover, evaluate, and buy them.
GTM engineering at Clay
In his account of Clay’s sales organization, Berry describes GTM engineering as a role that combines responsibilities traditionally divided among sales development representatives, account executives, and sales engineers. Sellers develop technical product expertise, build automated workflows, and manage customer relationships. A useful workflow can become a system that colleagues reuse, allowing improvements to carry across campaigns instead of remaining with an individual seller. He distinguishes this work from revenue operations: revenue operations maintains the core systems, while GTM engineers build and test growth experiments on that foundation.
Berry’s technical framework for GTM engineering explains how data, orchestration, agents, and customer-facing execution depend on one another. He sees the discipline as removing constraints that have historically prevented sales and marketing teams from shipping changes at the pace of engineering teams. The challenge extends well beyond generating outreach messages.
Building the systems behind sales automation
Account data: Account data must represent a market that keeps changing. Companies acquire businesses, open offices, hire employees, and adopt technologies; outreach and customer relationships also change an account’s state. Berry starts with relevant contacts, company hierarchies, firmographics such as company size, and technographics describing the tools a company uses. Signals layered onto those records help a team decide which accounts to pursue and when. Because no provider has complete coverage, he uses data waterfalling: consulting multiple providers to fill gaps, while evaluating their accuracy. Combining those sources also requires resolving different representations of the same company. Refreshing every field continuously is expensive, so the system must choose what to update and how often; employee counts and headquarters locations have different rates of change.
Orchestration: Orchestration keeps that information usable across the CRM, warehouse, email sequencer, dialer, call-recording tools, and interfaces where salespeople work. These systems need different update schedules and volumes, and their independent synchronization can create dependencies. Creating a contact in Salesforce, for example, does not make it immediately available in a connected sequencer. An orchestration workflow must wait and check that the contact has arrived before acting on it. Berry describes Clay’s team arriving at graph-based orchestration, with nodes for tool calls, agents, conditional logic, code, and operations that distribute work and combine results. The graph must accommodate failures as well as successful execution.
Persistent account agents: On that foundation, Berry favors persistent account agents that retain an account’s state through a deal cycle lasting weeks or months. An agent can spend most of that time dormant, waking on a signal, schedule, or heartbeat to gather current context and decide what to do. He recommends separating agent-maintained CRM fields from fields updated by people or deterministic software, giving agent-generated state its own place in a highly structured system. Feedback is necessary, but he treats continual learning and next-best-action selection as unresolved problems. One example is an agent that revisits a lost opportunity after a waiting period, combining information from Gong, email, the CRM, and a warehouse before deciding whether renewed outreach makes sense.
Outreach execution: Execution introduces both technical and human constraints. Sending on a salesperson’s behalf raises questions about domain reputation and responsibility for replies. Using additional domains creates a routing problem: responses still need to reach the salesperson who can handle them. Outreach must also coordinate across channels. If a call produces a booked meeting, the system should suppress the email sequence and remove conflicting marketing activity.
Coordinating agents with salespeople
Berry identifies human-agent coordination as one of the hardest problems in this work. A salesperson may disagree with an agent’s decision or be unaware that an automated action occurred, yet that person still needs to speak with the prospect. Effective automation therefore requires shared context between the decision system and the human handling the relationship. He applies the same reasoning to inbound work, where account qualification, routing, and historical context also matter.
On his personal site, Berry describes an ambition to found another computer-vision or AI company after further developing his sales and marketing skills. His career brings together two kinds of engineering experience: building technology that interprets business activity, and building the systems through which technical products reach customers.
Everett Berry of Clay traces the engineering beneath fast-moving go-to-market teams: mutable account data, asynchronous tool orchestration, persistent agents, and customer outreach where small automation mistakes can damage real relationships.
GTM engineering treats changes to data, automations, and campaigns as shipped systems that need release cadence, iteration, and operational ownership.
A usable account model combines first-party activity, third-party enrichment, entity resolution, selective refresh policies, and evaluations of competing data providers.
Orchestration must model asynchronous dependencies explicitly: a successful write in one tool does not mean a downstream tool is ready, so waits, checks, retries, fan-out, and joins belong in the control flow.
A long-running GTM agent can be assigned per account, remain dormant between triggers, reload current context, and preserve state across a deal cycle—but continual learning and next-best-action selection remain unresolved.
Customer-facing execution needs domain-reputation controls, reply routing, and cross-channel suppression because locally correct automations can combine into a harmful customer experience.
The final coordination problem is human: reps need to see what agents did, understand why, disagree when necessary, and arrive at customer conversations with the same account context as the automated system.
▶ Watch ↗