Everett Berry of Clay explains the technical challenges of GTM (go-to-market) engineering. He covers data as the foundation: waterfalling across data vendors to fill fields like phone numbers, running evals to gauge vendor trustworthiness, and choosing which account fields to refresh and how often since accounts change constantly through acquisitions, hiring, and product launches. He then covers orchestration as a data engineering problem across the twenty-plus tools a typical team runs, whose sync needs differ by field and system, describing Clay's graph-based model of general purpose nodes (agents, tool calls, conditionals, code, map-reduce fan-out). He also discusses long-running per-account agents that hold state across deal cycles, and execution concerns around sending as the rep, protecting domain reputation by spreading sends across domains, and routing replies back. # Observable Channel Presentation Evidence ## Video Identity - **Title:** *GTM Engineering: The Technical Bits — Everett Berry, Clay* - **Format:** Conference-style talk with live audience, Q&A at the end ("I have about 90 seconds for questions if anyone wants to ask anything"), followed by a handoff ("I will hand it to the next speaker now"). - **Speaker:** Everett Berry, presenting as a representative of Clay. ## Intended Audience The speaker explicitly names two audience segments: > "if you're an engineer or GTM engineer that's working on these things, some ways to think about how to structure it. And then if you're a founder in this space, some of the interesting problems that I think are worth uh tackling." - **Practitioners:** engineers and GTM engineers implementing these systems. - **Founders:** people building in the GTM tooling space. - **Event attendees:** a morning conference audience ("good morning everyone. I'm stoked to kick things off this morning"). ## Claimed Scope - **Topic scope:** technical problems in go-to-market engineering, broken into four areas: **data** (waterfalling, entity resolution, enrichment), **orchestration** (multi-tool sync, graph-based orchestration), **agents** (long-running account agents, persistent state), and **execution** (messaging, domain reputation, multi-channel coordination). - **Scope boundary:** speaker states GTM engineering "covers all of GTM," including inbound ("the orchestration problem is pretty acute in inbound"). ## Explicit Self-Description by the Creator - **Company affiliation and product framing:** > "If you're not familiar with Clay, we are obviously building infrastructure that kind of attacks these areas. But this is not meant to be a sales pitch." - **Internal practice claim:** describes Clay's own GTM cadence — "every 2 weeks we're pushing new data to our teams" — and Clay's CRM examples and agent architectures ("at Clari what that looks like…" [transcript rendering], "Here's an example of this um in in clay"). - **Industry observation claim:** "most advanced GTM teams are now hiring GTM engineers or looking for this role, and in my opinion it's one of the first roles that actually is an index on the advances that we're making in AI." ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Educational/technical register:** walks through architectures, data models, and trade-offs (update frequency trade-offs, waits/loops for sync dependencies, agent field separation from deterministic fields). - **First-party case demonstration:** repeatedly uses Clay's own systems as worked examples (CRM fields, closed-loss "reawaken" agent, rep-proxy email setup with multiple domains). - **Opinion-flagged commentary:** distinguishes personal judgment from fact ("in my view," "in my opinion," "I consider to be the most technically interesting"). - **Cites external data in passing:** channel effectiveness comparisons attributed loosely ("statistics from Smart Lead… across, I think, 20 million emails"), demonstrating a pattern of referencing third-party benchmarks. - **Open problem framing:** positions continual learning and next-best-action as "cutting edge problems… not fully solved yet," signaling the channel presents unsolved technical frontiers, not only solutions. ## Audience Engagement Evidence - Q&A handled directly, with substantive answers on the human-agent interface being "probably one of the hardest problems" and confirming the role spans software development knowledge plus GTM context. - Directs follow-up off-platform: "You can see me on LinkedIn. There's a URL there" and "if you want to chat with me more about this, I'll just be right outside." # Delivery Observation: "GTM Engineering: The Technical Bits" — Everett Berry ## Tone & Overall Style - **Conversational, engineer-to-engineer tone**: Uses casual intensifiers throughout — "I'm stoked to kick things off," "data is the lifeblood of GTM," "really, really hard to execute." - **Measured, first-person framing**: Leans heavily on "I think," "in my view," and "in my opinion" when offering judgments, giving opinions a hedged, personal quality rather than absolute claims. ## Structure & Teaching Habits - **Announced roadmap at the start**: Signals a "lightning round" format — "I'm going to get into kind of the areas that I consider to be the most technically interesting and challenging." - **Numbered, sequential framework**: "I kind of break it down into four areas," then walks through **data → orchestration → agents → execution** in order, with explicit transitions ("So, the next piece that I need to get right is orchestration"; "The last step that that is important here is the actual execution step"). - **Problem/solution patterning per section**: Each area is presented as a challenge, then a technique or architecture (e.g., waterfalling, graph-based orchestration, per-account agents). - **Explicit disclaimers of intent**: "this is not meant to be a sales pitch. It's more meant to be..." — pre-empts audience skepticism while demoing his own product. ## Vocabulary & Recurring Phrases - **Qualifier "kind of" used pervasively** — one of the most frequent verbal habits: > "GTM teams have kind of realized," "a kind of lightning review," "kind of dormant for most of the time." - **"So, um" as a recurring transition device** between points: "So, GTM is pretty new," "So, um, to do this you need a couple fundamentals." - **First-person walkthrough framing**: Explains concepts through his own workflow — "the first thing that I am doing," "I need to," "I'm layering in third-party information." - **Technical vocabulary set**: *waterfalling, firmographics, technographics, entity resolution, map reduce, heartbeat, evals, fan out, orchestration* — pitched at an engineering audience. ## Metaphors & Analogies - **Analogy to engineering practice as a core rhetorical device**: > "it is now possible to ship as fast as a product and engineering team" ... "pushing changes to their GTM structure almost at the same cadence that an engineering team might be doing releases." - **"Perfect virtual copy of the market"** as a memorable goal-statement for the data layer. - **Personified accounts/agents**: accounts "exist in a state of constant change"; agents "wake up" and are "dormant." ## Concrete Statistics & Evidence Citing - Cites figures with explicit sourcing but hedges on precision: > "This is across, I think, 20 million emails" — "somewhere between a half a percent and 1% reply rates." - Qualifies chart claims: "I actually think these are pretty elevated rates for some of these, but the relative differences between these channels is correct." ## Audience Awareness - **Addresses multiple audience segments explicitly**: "if you're an engineer or GTM engineer that's working on these things... And then if you're a founder in this space." - **Hands-on Q&A close**: References time constraints ("looks like I have about 90 seconds for questions") and invites follow-up ("I'll just be right outside"). ## Isolated Moments vs. Stable Patterns - **Stable patterns**: "kind of," first-person workflow narration, problem→solution section structure, hedged opinion markers ("I think," "in my view") recur across the entire talk and Q&A. - **Isolated moments**: The opening enthusiasm ("stoked") and the apology-free product demo framing ("not meant to be a sales pitch") appear once each; insufficient repetition to call them habits. - **Uncertainty note**: Fillers ("um") are frequent in the transcript, but exact frequency judgments are limited by transcript formatting; only their presence, not rate, is directly observable. # GTM Engineering: The Technical Bits — Everett Berry, Clay ## Speaker - **Everett Berry** (Clay) — sole presenter; Q&A includes unnamed audience members. ## Overview of GTM Engineering - GTM engineering is new, motivated partly by GTM teams realizing they can **ship as fast as product/engineering teams**. - At Clay: every 2 weeks new data, automations, and campaigns are pushed. - Defined as: **removing constraints that historically stopped GTM teams from shipping at speed** using technology. - The role has exploded; Berry claims it is "one of the first roles that is an index on advances in AI" — more powerful models → more leverage. ## 1. Data - Goal: a **"perfect virtual copy of the market"** — ideal customers, accounts, contacts. - Accounts are in constant change (acquisitions, new offices, hiring/firing) — plus GTM's own actions change account state. - Process: fill accounts with contacts, layer third-party data (**account hierarchy, firmographics, technographics, signals**). - **Waterfalling**: no single vendor has complete data; must query multiple providers (e.g., Forager alone covers only part of phone-number needs); run evals against providers. - Tensions/qualifications: - Updating data is expensive → must **selectively choose which fields to update**. - Multiple sources represent the same account differently → **entity resolution** required. - Berry: without a great data layer, "it's really, really hard to execute automated GTM plays." ## 2. Orchestration - Dozens of tools (CRM, warehouse, sequencer, dialer, note taker, Slack); usually 10–30 tools per team, each with a different view of the world. - Different systems have different needs: real-time single-record vs. bulk daily/weekly/monthly updates; volatile fields (employee count) vs. stable ones (HQ location). - Classic problem: systems sync independently of the orchestrator (e.g., Salesforce ↔ Outreach), requiring **waits and loops** to check readiness. - Clay's solution: a **graph-based view** with general-purpose nodes (agents, tool calls, conditional logic, code, map-reduce fan-out). Berry frames buy-vs-build as open but calls this "the modern way to set this up." ## 3. Agents - Context: reps currently sort through complex account state manually; agents can now manage this. - Same problems as LLMs, plus GTM-specific ones: - **Long-running agents** (weeks/months) over a deal cycle. - **High bar for error** — customer communication mistakes are "disastrous." - Unstructured agent output pushed into structured systems (CRM) → mapping matters. - Architecture: **one agent per account with persistent state**, mostly dormant, woken by smart triggers/heartbeats, ingesting context from data + orchestration layers, with feedback loops. - **Unsolved / cutting edge**: continual learning and next-best-action suggestions ("not fully solved yet"). - Practice tip: **separate agent-updated CRM fields** from deterministic/human-updated fields. - Example: closed-lost reawaken agent (Gong, email, CRM, warehouse) triggered on a **time delay**, not immediately after loss. ## 4. Execution / Messaging - "Messaging and execution is one of the hardest problems in GTM engineering." - Cold email effectiveness declines over time; channel comparisons (Berry qualifies absolute numbers as elevated, but relative ordering "correct"): LinkedIn ~3–4x cold email; cold calling ≈ cold email; SmartLead stats (~20M emails): **0.5–1% reply rates** — ~1 reply per 100 contacts, raising the stakes for agentic execution. - Human/infrastructure problems: - Rep-sent email risks **domain reputation**; mitigation is multiple domains, which creates a **routing problem** back to the main domain. - Multi-channel coordination: call meeting booked → suppress email sequence, unenroll from lifecycle campaign. - Clay uses rep-proxied inboxes for some accounts, multiple domains for others. ## Q&A - **Hardest challenge (Berry)**: the **human–agent interface** — reps may disagree with or be unaware of agent actions; ultimately a human must get on a call, so coordinating automated systems with reps is very hard. - **Outbound vs. inbound (Berry)**: applies to **all of GTM**; orchestration is "pretty acute in inbound" (routing, qualification, historical context). ## Stated Caveats - Talk explicitly "not meant to be a sales pitch" despite Clay building infrastructure in the space. - Some data/stat slides qualified by the speaker as inaccurate in absolute terms. - Continual learning and next-best-action remain open problems. # Speaker Attribution Record ## Video - **Title:** GTM Engineering: The Technical Bits — Everett Berry, Clay - **ID:** `01a15ca7-c342-712e-807b-28536517845b` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Everett Berry** | **Primary presenter / creator-side speaker** | Opens with "I'm stoked to kick things off this morning"; introduces himself via talk framing; associated with Clay ("we've iterated on this problem... at Clay") and the talk title. Handles Q&A answers. | | **Unidentified moderator/host** | **Other (session host)** | "Any any questions for Everett? Raise your hand." and "I will hand it to the next speaker now." | | **Unidentified audience member #1** | **Guest (questioner)** | Asks about "biggest challenge... within the org." | | **Unidentified audience member #2** | **Guest (questioner)** | Asks whether GTM engineers are software developers and whether the approach covers outbound vs. inbound. | ## Promotional Segments - **Explicit disclaimer of sales intent:** Speaker states Clay builds infrastructure for these areas, but "this is not meant to be a sales pitch." - **Product-showing segments** (Clay-centric, despite disclaimer): - Clay CRM account-fields example - Clay waterfalling / Forager phone-number example - Clay graph-based orchestration node architecture - Clay agent examples (closed-lost reawaken agent, rep-proxied inbox setup) - **Self-promotion:** Ends by directing audience to his LinkedIn URL and offering to chat outside. ## Referenced Sources & Third-Party Claims - **Forager** — cited as a phone-number data provider example in waterfalling. - **Smart Lead** — source of email reply-rate statistics ("across, I think, 20 million emails"; ~0.5–1% reply rates). Attribution is the speaker's recollection ("I think"). - **Named tools/systems** mentioned as stack components or integrations: Salesforce, Outreach (sequencer example), Gong, Slack, CRM/data warehouse/dialer/note taker (generic). - **Unattributed statistic:** LinkedIn effectiveness "three to four times more effective than cold email" — no source given. - **General claim:** "hundreds of vendors" for GTM data — speaker's characterization. ## Provenance Notes & Uncertainty - Audience speakers are **not named** in the transcript or metadata. - The moderator is **not named**. - Smart Lead sample size ("20 million emails") is hedged by the speaker ("I think"). - No curated metadata (comment availability, description) was supplied. ## Availability Limits - No comment availability information provided. - No timestamps available in transcript. \>\> Okay, good morning everyone. I'm stoked to kick things off this morning. Um, today's talk is going to start off with just a brief look at GTM engineering and what it is, and then I'm going to get into kind of the areas that I consider to be the most technically interesting and challenging um, within this space. So, GTM is pretty new. Um, it's arisen out of a couple factors, but one of the main motivating ones is that GTM teams have kind of realized that it is now possible to ship as fast as a product and engineering team. And so, the best GTM teams that I work with are generally um, pushing changes to their GTM structure almost at the same cadence that an engineering team might be doing releases. And so, at Clari what that looks like is something like this, where every 2 weeks we're pushing new data to our teams, we're pushing new automations, we're of course running new campaigns, and we're constantly iterating on the things that we're shipping and trying to keep pace with the speed that is um, that our engineering team is working at. So, um, to do this you need a couple fundamentals in place, and in my view GTM engineering at its heart is really about removing the constraints that have historically stopped GTM teams from shipping at speed using technology. Um, and the role itself has exploded. So, um, I would venture to say that most advanced GTM teams are now hiring GTM engineers or looking for this role, and in my opinion it's one of the first roles that actually is an index on the advances that we're making in AI. And so, as models have become more powerful, GTM engineers have gained more leverage within their organization and become more valuable, and we've seen tremendous growth in this role. So, um I kind of break it down into four areas. And what I hope to do with this talk is kind of lightning round go through some of the technical problems and solutions that I see for this. If you're not familiar with Clay, we are obviously building infrastructure that kind of attacks these areas. But this is not meant to be a sales pitch. It's more meant to be if you're an engineer or GTM engineer that's working on these things, some ways to think about how to structure it. And then if you're a founder in this space, some of the interesting problems that I think are worth uh tackling. So, the first is data. And more than most teams within a company, data is the lifeblood of GTM. And the core goal that I think we're trying to accomplish with our data is to create a perfect virtual copy of the market, the ideal customers, the accounts and contacts that you're going after. So, um most teams start out with something that looks like this. You have accounts, which are the companies that you're targeting, and contacts, which are the people that you're going after. The problem though that makes this challenging is that accounts at least exist in a state of constant change. As an organization, a company might be getting acquired, it might be spinning up new offices, it might be launching new products. So, the company itself is always changing. In addition, you as the GTM team are doing things that company that is making it change as well. So, you're marketing at them, you're selling towards them, you're trying to book meetings. That's changing the state of the account. And then also, the company itself is hiring people and firing people and doing things that provide signals for you. So, as GTM engineers, we need to manage all of this state within our accounts. And um we don't have all the data that we need to do this kind of right off the bat. So, um this is what a an example from Clay's CRM looks like. You can see I have a ton of fields that are simply telling me what state this account is in, whether they're a customer or not, whether they're expanding or churning, how big they are, how well they're scoring. And so, one of the fundamental things that we need to do is make sure that our records are updated so that we can actively accurately action on what's happening here. And so, as a you know, in a brand new CRM or a or a CRM that I'm going into, the first thing that I am doing is actually filling up the account with relevant contacts. And then I'm layering in third-party information that is going to help me figure out which accounts to target and which ones are in in market. Primarily, I'm looking at the account hierarchy, the firmographics that uh describe how big the company is and so forth, the technographics that describe what technology they're using, and then I'm trying to create signals on top of those accounts that are going to allow me to go after that um that company. And so, because uh there's a lot of third-party data involved here, we need to actually go out and source and procure that data. And within GTM, there is literally hundreds of vendors that you can turn to to um to get the data that you need, but none of those vendors is going to have a complete picture of all the information you you desire. And so, the key technique here is called waterfalling. This is where I'm going to actually go and look into multiple providers to try to fill in all the information that I need. If you see here, if I was just using Forager to get phone numbers for this um this set of countries, I'd only get halfway there. So, instead, what I need to do is layer on all of these other providers. And that's not only true for phone numbers, but for most the other data points that we care about within GTM. And so, either you or the vendor that you're using needs to run evals against these data providers in order to obtain the most accurate information. And so, not only do I need to sync in third-party information to my data layer, I also need to incorporate first-party information, and I need to keep that constantly up to date. It's also incredibly expensive to update data all the time, especially if you're purchasing it. So, I can't just update all the fields. I need to kind of selectively choose which fields to update. And not only am I pulling information from various sources, but if I'm running a signals program, information that I need is getting pushed to me all the time as well. And because I'm using multiple third-party sources, the actual representation of a single account in those different sources is going to be different. So, I need to resolve the entities um in between them. And so, a great data layer will tackle all of these things and allow me to kind of move on to the more interesting work, but without this, it's really, really hard to execute automated GTM plays. So, the next piece that I need to get right is orchestration. And this occurs because within go-to-market, there are literally dozens of tools that most teams are using. So, I might have a sequencer or a dialer or a bunch of places where my reps are living or my field marketing is living. And in most cases, the view of the world that those tools have is different depending on where you look. And so, orchestration, in my view, is really the act of keeping all of that up to date. And so, what happens to our data model then is I'm um on top of my enriched information, I'm sending emails and calling into my contacts. The account is generating events that I need to keep track of. And I now need a system to actually plug all of this into my data layer. And so, most teams are going to have something that looks like this as their basic stack: CRM, data warehouse, sequencer, a dialer, a note taker for call recording, and some chat interface like Slack. However, um I usually see like 10 or 20 or 30 tools that actually these teams are interfacing with. And orchestration needs to kind of keep that information up to date. The problem with orchestration is um all of these different systems have different data needs. So, some systems need kind of like real-time updates one record at a time. Other systems are going to need hundreds of thousands of records, maybe updated once a day. I might need to schedule updates on a monthly or weekly basis depending on the data I'm using. Some data points like employee count change all the time. Other data points like headquarters location change very rarely. Um and I'm not going to be making updates to all the fields at the same time. So I need logic within these systems that helps with that. I also need to be able to take a single um system that I'm working with and actually fan its information out to multiple different systems. And because I end up with this kind of distributed setup, I also have failures that are happening all the time. So this turns into a fairly complex data engineering problem that we need to resolve. A classic example of this is um when I'm working with these different systems, usually they are not fully orchestrated, which means that one system is talking to each other while I'm trying to talk to both of those systems at the same time. So for example, if you have a salesforce uh connected to outreach or a sequencer, usually that CRM that seek sequencer are syncing independently of your orchestration system. And so if you create contacts in your CRM, you actually need to wait for that contact to sync to the sequencer before you can then take action on it. This creates some difficult problems where you actually need to introduce things like weights and loops to check if information is ready. So Clay, we've iterated on this problem um quite a bit and we've ended up in a place where we are basically taking a graph-based view of the orchestration problem with a series of general purpose nodes that are executing various things. And so we have nodes that run agents, nodes that make tool calls, nodes that handle our conditional logic, nodes that run code, and then nodes that run effectively this map reduce system to fan out the information and bring it back. And so a great orchestration layer will handle all of these and whether you buy it or build it, I think this is like fundamentally the the kind of modern way to set this up. Here's an example of this um in in clay. And again, you can use other tools for this, but basically I'm going to have some sort of event that kicks off my orchestration, some trigger or some schedule. I'm going to then talk to a couple different systems. I'm going to combine that information back together, and then I'm going to push it out to different interfaces that, uh, my reps are using. Okay, so now that I have a data layer set up and I have my everything orchestrated, I now have this system which is starting to look a lot more complex. And if you spend a lot of time in go-to-market, uh, I think this is actually like one of the simplest views of what is happening with an account, where I have multiple signals that are occurring, I have data that needs to be updated, I have actions that my agents or reps are taking, and then I have meetings that are happening and feedback that's occurring. And so, um, the state of the world today is that we are relying on sales reps in a lot of cases to manually sort through this, but one of the great advances in the last year or so is that we can now use agents to take care of all of this context. Um, however, if you use agents, you actually run into some of the same problems that you are dealing with if you just use LLMs. So, um, in GTM in particular, we are trying to build very long-running agents, agents that run over a course of weeks or months that keep track of the state of an account throughout a deal cycle. We also have a high bar for error because a lot of the results of our GTM work is customer communication and getting that wrong can have disastrous con- uh, consequences. And then finally, the agents are often doing unstructured work and pushing that into systems that are highly structured like a CRM. And so, the the mapping of what the agent is producing is is super important. So, the architecture that we've landed on for this that I think is most powerful is an agent that exists for each account and maintains a persistent state of that account. It's always going to execute, and because it's executing over a of weeks or months, it's often going to be dormant for most of the time that it's available. So, we need to use smart triggers or a heartbeat or something to wake it up. And then when it wakes up, it needs to kind of ingest the current context of the account from our data layer and our orchestration layer. And because the agent is making decisions for us in many cases automatically, we need to allow for feedback on the agent as well. The um cutting edge of doing this is the learning phase where as the agent works on an account or a series of accounts, it updates its own view of what's working. Today in GTM, this is not fully solved yet. And in fact, the continual learning um effort and the next best action suggestions are kind of one of the cutting edge problems that that we're working on. So, here's a look at um a a kind of a basic agent. You can see here that I'm pulling in information from a couple different sources. I'm using reasoning steps here. And then critically, I'm also updating different values in my CRM that are just for the agents. So, I always recommend separating the fields that agents are updating from the fields that deterministic systems are updating or that people are updating. And to look at a full uh view of an agent, this is a closed loss free awaken agent. So, you can see it's talking to Gong, email, CRM, and um my data warehouse. And so, it's pulling together multiple pieces of information. And this agent is triggered on a time basis. So, if if we lose an account, we're not going to kind of like immediately go after that account again. We're going to wait for a little bit of time in order to um in order to attack it again. So, there's a number of kind of timing and context issues that we have to address when we're building agents for GTM. The last step um that that is important here is the actual execution step. So, now that we have a data layer that contains the perfect copy of the virtual world, we have an orchestrated system that's um sharing context with all of our systems. We have agents that are making decisions and reasoning about what to do. We actually need to get in front of customers and execute our messaging. Uh unfortunately, uh messaging and execution is one of the hardest problems in GTM engineering. Here's a look at some of the um email open and reply rates over time. Generally, what we observe is that cold email works less and less well as the years go on. This is a trend that's been true forever. Look at a snapshot of this. Um if you look at the far left here, I actually think these are pretty uh elevated rates for some of these, but the relative differences between these channels is correct. So, you know, LinkedIn can be three to four times more effective than cold email. Cold calling and cold email are roughly the same. And then on the right here, um this is a series of uh statistics from Smart Lead. This is across, I think, 20 million emails. And so, you can see we've got somewhere between a half a percent and 1% reply rates. So, what that means is, of course, if we've got 100 contacts that we're sequencing, maybe one of them will reply. And so, that really raises the stakes for agentic execution within GTM because if your agents are doing the wrong things, then you're missing out on the margin, which is where most GTM teams are uh are having success. The other thing with execution is you have to solve some very human problems. So, for example, do you email on behalf of the rep, or do you let the agent do the emailing? If you email on behalf of the rep, what that means is like everett@clay.com is actually reaching out directly to customers. But, if I do that in the wrong way, or I don't get the replies that I need, that then means that my overall domain reputation is going to suffer for for my company. So, a common technique then is to use multiple domains to get in touch with customers. But, then if I do that, I actually need to find a way to route responses on that domain back to my main domain so my reps can process it. And that's just email. There's also multi-channel outreach, which is tricky as well because you then have to, for example, if you get a call connection and a meeting booked on your call sequence, you then need to suppress your email sequence and maybe unenrolled someone from a life cycle marketing campaign. So, the coordination of the execution of all of this is also a hard problem and also something that we can use agents to to help resolve. So, here's a look at one way that that we're tackling this. This is a setup for a kind of rep proxied view where we have a bunch of rep inboxes that are connected to our sequencer and we're actually sending that on behalf of reps. But like I said, we do this for kind of a portion of our accounts. For many of of our accounts, we actually use multiple domains to go after them and then we have to tackle the routing problem. So, that was kind of a lightning review of what I consider to be some of the like harder problems within GTM engineering. I think if you get these pieces right, you can end up in a place where you're providing a technical foundation for growth that is helping your company achieve incredible results. But I think a lot of teams actually overlook some of the harder pieces here and and don't necessarily design around some of the constraints that they have to deal with. So, that's my talk. You can see me on LinkedIn. There's a URL there and looks like I have about 90 seconds for questions if anyone wants to ask anything. \>\> \[applause\] \>\> Any any questions for Everett? Raise your hand. I can Okay. \>\> Just uh curious as to what your um biggest challenge is with all these new um, within the org. \>\> I think one of the harder problems is probably the interface between the human and the agent. Like I said, I think the most powerful use of agents within GTM is to act as the reasoning and decision layer for a lot of tasks that a sales rep was previously doing. Um, and so you run into a lot of instances where the rep might think that they should do something different or the rep might not know that the agent did something. So, um, because ultimately a human still needs to get on a call with a prospect, coordinating the, uh, connection between what the automated systems are doing and what the, um, what the human sales rep is doing and making that work well, I think is probably one of the hardest problems. Okay, well, oh, yeah, one more. \>\> Um, I have a couple questions. So, um, GTM engineers are fundamentally software developers that have this, uh, knowledge. And, well, my other question is that, uh, this is mainly for outbound or inbound as well is included in this product. \>\> For everything, yeah. So, um, like the orchestration problem is pretty acute in inbound. You have to get the routing right. You have to qualify the account properly. There's usually historical context on inbound that comes in that needs to be, um, needs to be understood. So, uh, yeah, this I think GTM engineering covers, uh, covers all of GTM. And, uh, if you want to chat with me more about this, I'll just be right outside, but I will hand it to the next speaker now. Thank you.