Context Is GTM Infrastructure, Not a Tool Connector

Machine-generated transcript from the episode video. Speaker labels are not included and some names and product terms may be transcribed phonetically.

[0:00] Someone gave every rep a clawed co-work. Every team built its own chat GPT project. Now the same question gets two different answers depending on who you ask. Alex Bilz calls it aentic hellscape. One of his customers had a rep pitch a product line that did not exist because chatgpt told them to. The fix is not better tools. It is centralized context layer that encodes how the company actually sells. Alex has raised over 47 million for Endgame. Customers include Brace, Scale AI, Better Up, Monte Carlo, and Monte Carlo hit 80% AI adoption across their GTM team. In this episode, Alex breaks down the context layer. Why weekend Chat GPD prototypes collapse the moment teams try to scale them. Welcome to GTM Vault, trusted by over 26,000 founders and operators, building the future of revenue. Alex is a serial entrepreneur having co-founded and sold his previous company. Alex, thanks so much for joining the pod.

[1:03] Uh, thanks for having me, Rick. One of the things I noticed that you guys are doing is you're trying to unify the revenue function with one platform um while while leading with a sales solution. I'd like to understand what took you on this journey. Yeah. Well, first of all, that's a good frame. I would say the revenue function and the go to market function more broadly includes agents not just humans. So when we talk about unifying go to market we talk about unifying all the people with all the agents that are doing a lot of work for them. And so what took us on this journey was actually starting with a different product uh and a different value proposition. And we initially coined the term I don't know if you've heard of productled sales and built a PLG CRM. We had customers like Figma and Loom and Kalanley and Launch Darkly and a lot of PLG companies that were trying to solve kind of a similar problem just in a very different in a very different domain at a different time. And so what we learned in that process was everyone was ultimately trying to solve the data challenges and the data challenges are even more prevalent today when you have agents that are basically using data to

[2:11] go do work for go to market teams. So we we over the last two years have spent a ton of time and energy building a context graph for for go to market teams and what that does is it unifies humans and agents on the same source of truth. So if you have agents that are querying a graph um they get the same consistent accurate answers and similarly if you have a person querying it they also get the same consistent accurate answers. And so our thesis is if you take a company's knowledge, all their tribal knowledge, all their data, and you turn it into context that agents can actually execute on, you're able to have everybody working off the same source of truth, a single brain, if you will. And that just through architecture and design unifies um everyone around kind of one uh you know, one point of truth. Yeah. Yeah, that makes a lot of sense. I noticed that while looking over some of the different solutions you offer, some are more comprehensive than others and I'd like you to walk me through how the market has changed which has enabled these these these new solutions and how for certain departments maybe we're not

[3:18] there yet whereas like starting with sales it seems like you have a much stronger solution say compared to the marketing function. I'll start at the top level which is engineering is the furthest ahead by far. You've got teams that are almost fully offloading their work to agents. Even our engineering team as an example mostly works through agents writing code and that's pretty prevalent. You've got systems like uh cursor and clog code that people use and you just say go fix this and the machine goes and and fixes it. Similarly in legal you've got platforms like uh Harvey and Lora that are kind of taking over an entire function and providing workflows and then support obviously companies like Sierra they just raised another round today and and decagon are kind of doing that autonomous agent work for an entire function and and the results are pretty impressive. revenue as a whole is definitely furthest behind. And part of that is because the context is so sort of disagregated and fragmented across the or to sell to a single person with a single account. You've got to have um you know information that currently lives in Salesforce and Gong and email and you've got the company's methodology and playbooks and positioning and pricing

[4:28] and packaging and so there's just a lot more complexity in revenue which is why it's harder to to automate. And so the the mechanism that we've seen work in what companies are doing today is really augmenting what humans are doing with AI so that AI can do a lot of the research prep kind of data synthesis and analysis ahead of time and we think that's the biggest opportunity in AI today because revenue is the function that makes the money. It's also the the biggest cost center and so companies really trying to figure out how to transform their their revenue or you know with agents at the core. Define the centralized context layer. what is in it, what is not, and what is the smallest viable version a team can build in a quarter. Yep. So, we start with kind of a few design principles, if you will. One is you kind of need to know everything. The more information you have, the better the context. I'll give you a very specific example. If you if you ask about what deals are stalled to really figure that out, you can't just look at Salesforce. You need to look at Salesforce. There might have been a caller an email that wasn't logged. So you got to go analyze the calls and the emails. There might have been a Slack conversation that talked about a meeting

[5:38] that somebody had playing golf call for whatever it is, right? And so just to answer a simple question of what deals are stalled, you really need to synthesize information across at least those sources just for that one question. So our view is pull everything in, process everything upstream of anyone asking that question. The minbar in terms of what needs to be from a data source perspective included is basically what I just mentioned. You need a CRM, you need Gong, you need email, you need Slack, and you need some documentation on your sales process and methodology. Sometimes that lives in Google Drive, sometimes that lives in an enablement system like Seismic or Highspot. So that's kind of the core data set. You can do a lot more. You can bring in product usage data from Snowflake and connect to, you know, custom systems and support and all that kind of stuff. But but typically we see companies do that as a phase two on the on the what it takes to build. Build versus buy is a very interesting topic now. And the reason is because what is build has really changed. So you you can with those sources connect you know claude uh directly to MCP servers. But what ends up happening is if you make the agent work really hard for every single question and kind of go and ask pieces

[6:47] of that question or that answer um across different sources. Everything happens at read time. And when things happen at read time you'll get very inconsistent answers because you need to go make a ton of different tool calls. accuracy is pretty low because you're kind of just looking for needle in in a haystack data points across all those sources. Um it's pretty expensive. So token costs are are are becoming a challenge for a lot of enterprises. And so you have to basically process all of that every time you ask a question. And so our approach is you take all of that, you bring it upstream and you pre-process it. And so what that means is we actually run fact extraction and and compression on the data ahead of time to basically turn it into really small dense documents that are fact checked and and updated. Which means if you give an agent like a single one pager on an account that has all the important stuff including the the deals that are open, the interaction history like across channels, you can imagine you're going to get a much faster, more accurate, more consistent response. Um and for a team to build that is pretty expensive. You have to have data engineering, applied AI teams that understand how to do this for for revenue as a domain. And so we've seen

[7:55] teams spend, you know, a quarter, six months just trying to kind of move data around and figure out how to model it to serve it to agents, which is a pretty expensive process, which is which is why why we exist. One of the things that I'm curious about is in the event that the enterprise does not have a CRO, how do you sell into the revenue or the GTM or considering your solution is a depart or a teamwide or a departmentwide solution? Let's say the whole revenue department or GTM department which touches on several different functions. Where where do you start and can you tell me a little bit about that process? Yeah, everything's fragmented and companies are trying stuff and not really able to figure it out. And the reason a lot of them can't figure it out is um per my earlier point, they're working with fragmented context and agents just don't do very well when they don't know what to do. So, you've got a lot of agents that are kind of being spun up and and doing a ton of crazy things. to your chat GPT point. I had a I had a customer tell me last week that one of their reps was using chat GPT without anything connected to it and it made up a ton of

[9:04] new products um and SKUs that the rep pitched to the customer. And if you extrapolate that across, you know, reps and and and kind of like orchestration mechanisms are just doing the wrong stuff because they don't know that kind of is the reason that some of these next things that I'm going to talk about have happened, which is on we're seeing a lot more technical teams in revenue go to market orgs whether within the function or sometimes the CTO or the CIO's office is being brought in to help fix some of these challenges. So even across a gotomarket or companies are realizing that you need to have context centralized. So what they're doing is they're spinning up whether it be go to market engineering teams or AI transformation teams that as I like to joke understand how software works and are basically working through how do we build the foundation and the infrastructure to serve all of these different use cases and that means that we sell to ultimately the CRO or the CIO. Sometimes it's the COO, but our technical champion is often somebody who's brought in under sort of emergency conditions to figure out how to fix uh quality across the outputs that agents are producing. And so that typically

[10:10] gives us a point person who's much more technical who, as I said, understand how software works to kind of work through um how to make things more consistent and accurate across their use cases. What's tricky is you'll have in some cases companies that have already spun up, you know, a thousand agents as an example. And so it's really hard to go remove all of the work that's been done and the workflows that have been created. And so our mechanism typically is to say, you already have a ton of agents, great. Instead of calling 20 different MCP tools, replace those with one from us. Keep your workflows, keep your interfaces. And so that typically means that we work at at a layer that's sort of below from a from an architectural perspective the agent orchestration or kind of people querying claw. The context layer encodes the company's sales methodology not just this data.

[10:59] Whoever curates it controls how the team sells who owns it inside your best customers. I think this is one of the most important questions in AI for go to market. I like to joke that the new role is the chief propaganda officer. My parents come from the Soviet Union and they ran away because they didn't want to be brainwashed. But brainwashing in the Soviet Union was very expensive. You now have the ability to just feed AI what you want reps to do and then when reps ask what should I do, AI tells them what to do. I think this is probably the most slept on opportunity in AI for go to market as I call that. Who does that? It's funny the the role traditionally is enablement and in some of our best customers we actually have very technical enablement people that will feed the right data in actually build their own internal applications with our MCP server uh you know one customer build an entire whale dashboard application for their top 50 accounts so everybody in the company could just go to this internal app and it's like here's exactly what we should do based on our methodology here's exactly what we should not do based on the situation of this account and our methodology and so the roles I think are shifting enablement teams are just very used to manual enablement which is kind of

[12:08] siloed from how people do work versus kind of agentic enablement as I call it agents need need to be taught and trained too right so that that I think is shifting pretty quickly sometimes we see it come from enablement sometimes it's ops sometimes again you have like SE or SA or kind of go to market engineering technical teams that understand this and just work directly with the CRO being like here's what we want reps to do here's what we don't want them to do I'm going to create a you know a markdown file or or just a set of documents and feed those into endgame so that anytime a rep asks like what should I do on this account and it's like you need to qualify metrics from from medic as an example and so there are more sophisticated mechanisms of that as well like we're seeing a lot of policy stuff a company's knowledge base usually has a lot of contradicting information do we do we allow this discount usually no if it's a certain type of customer and it's the last week of the quarter do it and so we actually again upstream name of the kind of you know agent you know doing the reasoning work kind of pre-process that and kind of extract what are the plays what are the directives what are the things that we want the agent to enforce but the the who part is definitely fluid I would say across our best customers it's it's sort

[13:17] of a combination of enablement ops new AI functions one of our best customers just created a new AI go to market leader and that person actually came from solutions architecture and their only job is like make agents work for go to market. I love that you hinted hiring managers will start spending headcount budget on agents instead of humans. Walk through one customer doing this which seat got replaced. There's some sensitive context here because a few of our customers have had fairly significant layoffs. The the metric that really if you think about AI everybody's lading to is revenue per employee. I like to say that revenue per employee is is the new endgame. And what that looks like is basically segmenting out areas that are expensive, inefficient, and replacing a lot of the work with agents. I don't think it's as direct of a headcount replacement onetoone. But what that looks like is you end up having much smaller sales teams. You have more generalists, fewer handoffs. So as an example, full cycle AES that land and expand because they don't have to be specialized because the agent can go do a lot of the specialized

[14:23] prep and analysis work. Seeing smaller SDR functions for sure. one customer of ours, you know, replaced a good chunk of their SDR team with basically a go to market engineer endgame MCP and some really creative semi-automated plays with approval loops to fewer people that can just be like, "Yes, this looks good. Send it." And so, uh, I I think what we'll see at a market level is smaller sales teams, also flatter orgs, fewer sales managers, more reps per manager. We're seeing that shake out in different ways across customers, but the the end result is pretty much the same, which is you have fewer better people with a lot more assistants that are kind of running um the book or or doing the work of a previously larger team. You know, a couple years ago, uh to effectively run the marketing or sales function, you still needed uh a really good data foundation.

[15:14] Still true. Yeah. So it really is more more true than ever. Operators hear this this term data foundation and glaze over it and it's not like it was much different in the past. That's why I sometimes I just don't understand why and they treat it like a six-month CRM project. What is the minimum viable foundation for a team that wants agents in a quarter and say not not in a year? Yep. Uh my background is data so I'm very familiar with this. Um a few things that I'll say on better data foundation is more important for agents versus less important and the reason is a human can kind of connect some context or fill in the gaps on an accurate information and agent doesn't have that tribal knowledge. Uh they just work with what they have. The second piece is previous attempts at solving data were structured data and it's almost impossible to solve a lot of the structured data challenges.

[16:08] Uh what I mean by that is you have different tables that you have to join together. you have to kind of you know process and and kind of restructure data at the database level. We're dealing with unstructured data mostly. Unstructured data is you can sort of fix in a number of different ways. It's softer. You can do a lot with search. You have you know poorly joined database but you have a ton of different kind of you know documents and facts and you can kind of search on it and kind of put it together. So it's a different it's a different problem. And then the third is humans used to fix data foundations and now agents can actually fix data foundations. So our primary IP is in how agents work with data upstream of people querying the data and reasoning. And so you have agents that will go through analyze data, fact check it across sources, rank the accuracy of a particular fact. And so you can move a lot faster because you don't have to have a human keep everything in their head. You basically have agent loops that just go and fix data and do that by actually replicating it into an unstructured semistructured form that I called out earlier is basically a document. It's like a wiki. So imagine you have you know a thousand agents are going across all your sources factecking

[17:18] it and stitching it into like a really well-reasoned wellwritten document that's built for agents to read not humans. You can move a lot faster. Every company on earth has data challenges and CRM challenges. Trying to fix data in the CRM is, I think, totally useless for what it's worth. Everybody has these six month uh we're going to go fix everything. The challenge is that those systems are typically fixed through human input and structured data. AI can do a much better job much faster without being slowed down by legacy SAS products that were built, you know, two decades ago and kind of build a new layer on top. And what that means is teams don't have to do much at all. They just have to have the right context layer, a context graph as we call it, that'll get built based on their underlying data, no matter how messy it is. And you must be updating this in some dynamic cadence, maybe daily, weekly, I don't know, based on event. So it's actually way more frequent than what you just said. So if a new call comes in, that call gets processed immediately and the graph gets updated immediately. And so yeah.

[18:18] And as a result of that, are you saying now any team member within the GTM function has access to the updated data? Not only do they have access to the updated data, it's automatically updated, it automatically gets seen by our MCP server. So if somebody's just using Claude as an example and has endgame connected to it, if they ask a question, they just get better, more accurate answers without them even having to think about how it works. That's phenomenal. Talk to me about the AI first GTM stack and what it will look like in say 12 months from now. Do you think it's going to be a new category? Nobody has named yet? That's a great question. I think what we're seeing is definitely a move toward horizontal layers and consolidation at those layers versus kind of point vertical solutions. Let me give you an example. Maybe 6 months ago, you would talk to a sales leader and they had a pipeline problem because every sales leader in history has always had a pipeline problem. And you would have a lot of these AI vendors come in and say, "We can 3X your pipeline." So as a sales leader, you're like, "This one's 3x, this one's 3x. If I buy 10, that's next.

[19:24] The math works." And so they'd buy 10 point solutions and pipeline increased. So they were like, "What what what do we do now?" Which is, by the way, one of the reasons technical teams uh came in because they focus a lot more on the how versus the why. And so we we've sort of seen this progression from from why to what to how. And right now everybody's in in hell mode. Like how is this actually going to work and how is it going to move my number? What I think is more likely to happen is far fewer systems that sit between the underlying data sources and the agents whatever they are that do the work. So I think that's going to look kind of function to function or departmentto department dependent. So I talk through kind of like what engineering is doing and what legal is doing for go to market. I think you're going to basically connect all your legacy systems to something like endgame that's going to process all the information, give you a solid foundation that's, as I called out, faster, more accurate, more consistent, less manual effort to to maintain. And then you're just going to be very experimental with use cases because AI is moving so quickly. You don't know what you can do tomorrow. Some companies don't even know what you can do today. And I think the

[20:29] last mile workflow agent orchestration is going to be pretty flexible and pretty malleable. Six months ago, go to market teams were not using cloud. Uh today, every go to market team is either uh you know rolling out claude or about to roll out claude or some people are using it on their personal accounts already. You had open claw um open claw you know the the founder got bought by openai. They're building something that's going to be great. Enthropic is also building an autonomous agent. You've got systems like zapier make and you've got chat gpt's new workspace agents. That's all is happening in a pretty compressed time period. So what I think this is going to look like is go to market teams that are operating a lot more like product and engineering teams understand data understand the layers of the stack and I think most go to market teams are going to have a context graph context layer that just lets them build what they want to build and are going to ship in sprints and move really quickly and iterate in the same way that product and engineering teams do today. So I actually think it's going to look much more like product and engineering because that's what moves fastest and we've already seen how product and engineering teams are taking advantage of AI different mindset much more iterative with a deeper understanding of

[21:37] what happens logically at each layer. So you can QA it you can fix stuff you can kind of make things better as you go. I could see that. How do enterprises uh increase adoption from say 20 to 80%. Pretty easy. just give an MCP server into whatever people are already using. So if if somebody's working in claude, make the data available in cloud. If somebody's using chatgpt, make it available in chatgpt. If somebody's using slack, make it available in Slack. If somebody is using Zapier, make it available in Zapier. And that's the fastest way by far is you just go to where people already work in the way that they're already working and you just make it better, faster, cheaper, and more consistent. So, just to kind of like walk you through like a very specific example, if I as an admin of Claude in a company want to make sure that everybody's working off of Endgame's context graph, what I do is I go into the connector marketplace, I approve Endgame and then I just tell everybody to go hit a little switch that just says turn it on and just work the way that you were working. But now you're going to have a lot more access

[22:44] to your accounts, to our methodology, to synthesis across all the information. And if somebody says, "How do I prep for this meeting?" As a very basic use case, it's now going to look 10x better, more accurate. It has context and all the previous interactions, what the playbook and methodology is for how to show up to this meeting, can build you a deck, but instead of it just being a different deck every single time, because our context graph also has skill files in it. If I asked to make a deck, everybody that makes a deck off of Claude or even if some people use Chad GPT gets the same output with the same format and the same structure. Uh so you don't have to change behavior as much. Behavior change is the hardest part. Going to where people already work and aligning to how people already work is the best strategy I think. Well, it sounds like with this approach you're cutting out, I don't know, let's say on average 10 different SAS tools uh across the GTM function. um you're consolidating it all into one uh let's call it a contact layer that you can hook now to claude. How does the pricing here work? We'll tell you this is something we talk about a lot and we don't have a perfect answer and I don't think anybody really has a perfect answer. So we're very iterative with it.

[23:54] Our our core model is a platform fee which is based on you know documents that we process to build the graph. The more documents we process the richer the graph. The richer the graph the better the output. We also do charge based on seats, human seats or agent seats. And we on top of that tend to do a lot of forward deployed work, actually standing things up, helping people integrate into their workflows, build workflows just given what we see across our customer base. We've got some crazy customers that are doing some pretty fascinating things. And so we see what they're doing and we kind of uh bring that back to certain um certain accounts as best practices. So it's really a combination of platform seat and then forward deployed um you know services. if you want to call it that, sort of on top to help people actually get something running end to end and actually validate it and QA it and fact check it and and actually align it to business metrics in in every single one of our customer scenarios. we we actually can build pretty um pretty fascinating like ROI analysis on things like win rate and overall revenue impact because we can track you know every question um that gets asked

[25:01] of our graph and we can you know link it to whatever the account is or the deal. So, we tend to do that as part of our forward deployed kind of orientation where we're just constantly showing here's what moved, here's what didn't move, here are recommendations on, you know, how you get this number to move and that's been pretty consultative so far. Um, and we're intentionally keeping it that way because market's changing very quickly as you know. Yeah. And I imagine selling in to one client is going to take you maybe couple months really to push it through considering like it's fundamentally like you're changing how several departments are working together. the the processes are changing, right? It depends. We've we've closed an enterprise deal in 15 days from first meeting because we got to the person who knew that they wanted to do this, had budget, was the signer, um was a they must have been nurtured for a few months though before that. No. Nope. They just knew that they had to fix this. Um had already decided on the shape of the solution.

[26:05] They they they were they were very problem aware and I would say somewhat solution aware and we came in with here's what it should look like and it was like let's go. In some cases though it can take upward of 6 months which is tricky because um things are shifting so quickly and people have to have internal conversations that within that 6 months you'll have I can build anything with Claude and we're like yes I know but you still needed to talk to the thing that will you know know about your business and your customers. um you should build it with cloud but you're missing a layer and people like I don't know I can build the layer with cloud I can do anything with cloud and so there's and then by the way um in this particular example that same same company came back and was like we try to build everything and we now have like an agent sprawl problem and everything is giving us different you know answers and so we actually realize that we need this kind of centralized foundation so so that's that all happens within a pretty short amount of time because cycles on on everything are really compressing so quickly so it's I wish I had a clearer answer on here's what it looks like across everyone one, but it it really really depends on the org and honestly leadership. Probably the biggest um the biggest shift is is kind of next generation leaders think much more in terms of systems than armies. And so you need to find somebody who's like I need the system to work. I'm not going to

[27:16] muscle my way through and what I call jokingly meat scale where I'm just going to hire 50 people and figure it out kind of like on the ground. Um they're kind of thinking through the architecture of their overall motion of their of their overall function. So if you if you find that person, it can move really fast. Tricky part is identifying those people. And there are more and more of them every single day by the way, but it's it's not yet globally pervasive. More so in technical teams, but again, in a market that moves as fast as this one, I'd rather be early than late. Yep. And if you were starting Endgame today from scratch, what would you build differently? I think I would have been more okay with the early momentum, which is tough to say. like we built the context layer plus the interface and our UI is great and we built our own assistant that talks to our graph to kind of like keep it much more collapsed. The challenge and I think we knew this was going to come up. we just thought it was going to take longer was it would if people already work in claude you're just competing with claude on the interface and we always had a thesis that you know claude and chpt and whatever else comes out next is going to be kind of how people work and they're just going to need to connect to to context and that

[28:24] needs to be good. I think I probably would have built less on the assistant stuff and we're rebuilding a lot of it now so that you can just access endgame in in kind of the tools that you're using again. you can today, but there's just way more that you build in a more focused approach where you understand that you never own the reasoning layer. So like how you design the tools, how you design the MCP server, how you like pass instructions back into there's a lot of nuance. Um, and I think I would have probably doubled down on that sooner, but it's hard because at the time nobody was using cloud. So what you know today um you know is is is sort of always different than than what you knew before. Cool. Alex, I'd like to move on to the rapid fire section of the pod. AISDR is worth building or worth burning. Burn. You can build little orchestrator like SDR machines where you have somebody really smart that's managing it and kind of coordinating across humans and kind of AI agents. like we're building something pretty similar, but it's not a separate thing. It's just a workflow that is deeply ingrained into like me, my personas, what should I be doing versus, you know, a rep versus

[29:34] what's going from marketing. So, I would say solve solve outbound as a use case with a go to market engineering function. Don't try to buy a headcount replacement for an SDR because it just doesn't work that way. And the results from those systems have been pretty bad. The most overrated metric in AIGM reporting uh we don't see as much of that but I have a personal mission to eradicate MQL as a metric that anybody ever looks at because it's it's it's mostly CYA and just kind of arguing about politics. I think that one's highly overrated. Typically, mole metrics other than I think pipeline win rate even for marketing are highly overrated. Particularly for enterprise looking at things through the lens of an account is much more useful for SMB. It's just revenue because the cycle is so short and conversion. Obviously, one thing every CRO gets wrong about AI adoption. They don't understand it for themselves. They don't build their own instinct and they hand it off to people who also don't know how to use AI or have an instinct. It becomes a lot of platitudes and we're using AI. We we bought Claude. We're using AI. We we have co-pilot. We're using AI. It

[30:42] becomes um you know posturing if you will sort of performance theater. Absolutely. And my biggest advice to CRO and any executives is stop listening to people. Don't even listen to me. Definitely don't listen to investors. I actually did a um a talk with my board member and I was like, "It's his fault." You know, investors tell you something and you just go with it. You have to build intuition and understanding that comes from you and the best leaders I know spend nights, weekends building stuff on their own. They're like, "Oh, now I understand." And and and I think intuition is very underrated. Um and traditionally hasn't been as big of a part of leadership. You kind of like say, "Here's what I want done and people go figure it out." I think that's really shifting. I think leaders need to focus on the how much more than ever. I think that will continue. CRO's CRO particularly. Yeah.

[31:29] The belief about agents that is completely wrong. Most teams are focused on having agents do more. So the market narrative right now is I want them to do the work. I want them to be autonomous. I don't think that's wrong, but I think it's missing the point. Having any agent or even any classical software system, you could just write a script to be like go do a thousand things. Doing stuff is actually easy with software. Doing the right thing is very, very hard. So everybody's focused on autonomy, doing more stuff, doing more work. We actually see the best results come from people thinking through how does it work, what's the right thing to do. Um, and you know, the investment mix on what to do versus doing it is probably 8020. Um, in the favor of knowing what to do. Uh, so autonomy only comes when you have agents that have very good instructions and know what to do. And I don't think that's the current narrative. And I think that needs to shift quickly. I think the push back here becomes when when you're working on in a highly competitive market and your competitors are are moving really fast and there's a lot of pressure on you for to to deliver results. You you you you you buy an AISDR and you send uh 10 million emails, you get no

[32:40] conversion, you burn your domain and your competitors still win, right? No. So the point that I'm trying to make is the the solution is uh fundamentally rearchitecting the revenue function or the GTM or which is going to take some time and it's not going to happen overnight and then you have to get everyone to follow suit and kind of learn this new way of operating. And so how do you kind of like juggle both the moving train in parallel with you know rebuilding it as as you're going? I'll give you a different story. My last company got acquired and the acquiring company was a larger company and wanted to build a new product and the old part of the team had a really tough time and you know a lot of you know 10 years of company history what is this new product at the time it was going cloud native now my joke is it's cloud native but that's a the way that we did it and what I see a lot of companies do really well is basically do a startup within a startup um you have a core group of people that can move fast that are first principal thinkers that can iterate and test stuff. A lot of those happen to be more technical or more curious or

[33:47] ideally both. If you're more curious, you tend to be more technical if that makes sense. Uh so kind of, you know, areas that can move much faster. Sometimes I've seen it happen by function. Sometimes I've just seen it happen within the same team of like certain kind of AI champions that go forward and do stuff and then everybody else follows. It depends a little bit on the or but even in all those cases, it has to work and if it doesn't work, it doesn't work. And so focusing on making things work, I just think is still the thing that most companies miss because people want to say that AI agents are doing the work. Quality build versus buy on the context layer. What's your honest answer? The market is definitely moving towards build on almost everything. Our CTO and I have talked and I've said I don't know what software I would buy today if I was starting a company from zero. Maybe payroll like Ripling or something like that and probably some databases so I can build stuff on top. There are very few things that I think you should buy.

[34:37] To be very candid, I don't think you should buy custom agents. I don't think you should buy workflow tools. You know, you can use claude. I don't know if that means build or buy, whatever you want to call it. Infrastructure, I would buy because you don't want your team actually spending R&D resources on building something that they could be building in product or applied to another area. And domain expertise is really important. So the the cross-section of infrastructure and domain expertise where if you do something for 10 years, it's just going to be a lot better than if you started today. I would look at kind of context graphs as part of that. You could build it. It's very expensive. I like to joke we have very expensive engineers and that requires a lot of data understanding like ops understanding like how to run databases infrastructure at scale how to serve things in subsecond sub you know like very short kind of response times to tons of agents that are hitting your system I would not build that personally like we don't build our own databases and if you move that abstraction one layer up you're going to have domain specific data context layers that I would definitely not build outside of that think I'd build almost everything or have a few platforms that can do a lot of the things. So quote unquote build is

[35:45] basically a use case or a workflow. I would not buy point SAS solutions for anything. Docuine by the way and there's a really interesting conversation on docuine when they're like hey it's really cheap to replace docuine. Docuine is really expensive but docuign is something that you send to a customer and it's got brand recognition. So, I would pay more for Docu Sign so I don't look like a, you know, a little startup that's just like we decided to vibe our own document signing tool when you're when you're dealing with a million dollar contract. I just wouldn't do that. So, there's kind of maybe a few examples. So, I'll I'll I'll I'll say exceptions prove the rule. That's an exception. Chief Propaganda Officer, real role in 12 months or just a great LinkedIn post? Well, I think I think that's probably my job. I don't know. I don't think it's a real role. um uh if somebody calls himself that it would be pretty entertaining but I I don't see that at an orchart level happening very broadly.

[36:34] I do think the job to be done is how do you teach AI to give the responses that you want. This is interesting actually. There's a lot of talk on bias in LM from the Frontier Labs like on certain topics. LLMs are biased. Um I don't know if you've seen these reports. It's like everybody has a different point of view on what LLM is biased towards what. Bias is usually bad, but bias is sometimes good. Like a bias towards action is a good thing, right? And that's like an operating principle that that a lot of companies use and I personally live by. So what do you want to bias people toward I think is is is really kind of an important philosophical question and I think biasing people towards doing the right thing when the alternative is biasing people towards doing the wrong thing for your business is is important. So, I think that's going to be an executive level topic and who ends up being the quote unquote chief propaganda officer. Um, I don't know. It'll probably be split across a few people.

[37:30] Ultimately, the CEO definitely has some say in kind of what they want to buy a company. If a CRO listens to this and wants to do exactly one thing in the next 30 days, what is it? Not the right answer. The first move. Yep. First move is get I'll give you two. get really tight on the one-two use cases that move the needle today. That could be something as simple as like we have a ton of revenue and existing customers and we need to improve account planning. Very basic, but kind of like first step. Two would be get the base amount of data structured in a way where you can iterate on it pretty quickly. So use endgame or something that you can find that does something similar so that you're kind of building and compounding use cases off you know a centralized context layer because you're otherwise you're going to spend all your time kind of fixing stuff and not moving quickly.

[38:16] So one two tight use cases that move the needle to set the foundation so as you move past those use cases you're not rebuilding infrastructure every single day. The agent hellscape is real. The fix is not more tools. It is a centralized context layer that encodes how your company sells. The gap between super intelligent revenue teams and everyone else is widening fast. The only question is which side of it is your team on? If you're building GTM under real constraints, explore GTM vault. Build architecture, not activity. Thanks, Alex.