Knowledge Systems: The New GTM Stack — Jeffrey Wang, Exa

Transcript

. Hey everybody, I'm Jeff. I guess I was introduced, but I'm the co-founder of Exa, and today I'm going to give a talk on turning go-to-market into an AI engineering problem in the spirit of this AI engineering affair. And just a quick show of hands to understand the audience: raise your hand if you're technical. Okay, great. Okay. So I oriented this talk around go-to-market as presented to engineers. So I'm happy that I did that. Cool. So first, just to ground what Exa is, because it's relevant inside of this presentation, Exa is a search engine for agents. Think: agents are really smart, but they don't have access to the web. We're this web MCP, web tool that agents can access. We power Cursor, we power Cognition, we power a lot of the AI ecosystem at this point. And before we start, I also just want to talk about, especially as a technical audience, why should you even care? Why should you care about go-to-market? I guess this audience cares about go-to-market because you chose to go to this go-to-market talk. But I think there's this funny narrative right now, which is people are like, oh, product is the only thing that matters, or distribution is the only thing that matters. And there's all sorts of Twitter flame wars, like, oh, is Cluelly going to succeed because they're really good at distribution, but what the heck is their product? And then other people are like, oh, the product needs to be super good because agents shop for the product, so they'll shop for the best product. And so my view and my experience in the last few years is that you just have to do both. I think you have to get product right and you have to get go-to-market right. You've got to build the thing, it's got to be good, and then you've got to get it into people's hands. If you don't do both things, then you don't have a company. So that's my view on the matter. And I would say a really funny thing also is, as a technical person, when you start a company or you start some sort of project, very much so the bias is, hey, I'm going to just build the thing. I'm going to make it really, really freaking good, right? That's the bias you have as an engineer. That's the bias we had when we started EXO, and we were honestly pretty bad at go-to-market. We were not doing enough marketing, we were not doing enough sales. But I think the cool thing about go-to-market, particularly in 2026, is you can treat go-to-market like an engineering problem, and particularly an AI engineering problem. And so I think that's a super exciting thing. It's more fun for engineers than ever to do go-to-market, because you can automate things, you can do so much as one person, et cetera. Also, I want to make this interactive. If anybody has questions at any point, please ask, because I'm aware there's a lot of talks, and I don't want to bore you. Cool. So the hypothesis I have is if you're an engineer, or if you're anyone, you can treat go-to-market like an engineering problem. So first, what do go-to-market teams do? I have a laundry list of things here, of things that go-to-market teams do, but here are a few. One is you've got to research your customer, right? You've got to research your targets. You have to find out information about targets. You have to find the right people at particular companies. You have to build POCs. There's a ton of stuff you have to do, right? So I'm not going to list everything here, but what is the grand unifying theme? Well, go-to-market is a data problem, right? So you have this entire world of what your product does, and then this entire world of all your potential customers, and you're just trying to learn and figure out what your world looks like. And so this is my proposal. It's a data problem, and we have to solve it from a data perspective. Cool. So what is the data that is relevant? I propose that you need a live model of your world that agents can act on. And so what does that mean? Okay. Well, one is you have a ton of internal data, right? There's all this information that you know about your customers, about people that are at your company, data about how people use the product. That's internal data that you know. And then there's all sorts of external data, right? There's over 60 million companies in the world, and there's billions of people, over a billion that are on LinkedIn, for example, and all sorts of stuff is happening every day, right? There's all this news. And so when you're building this data go-to-market system, it's important to keep in mind all the different sources that exist and are available to your agents. And cool. So I'm going to go through, hopefully pretty fast, all the different components of what we've built at Exa. And just for context, I've been really passionate about this for a long time. So Exa was launched in the middle of 2023, and so we were post-GPT4, and GPT4 was really incredible because it could actually, even then, even though it's way worse than Fable or whatever, actually just automate entire parts of go-to-market. And so from the beginning, I've been thinking about our go-to-market from a very, very AI agent-first perspective. And so we're going to go over two interfaces that we have that help us, and then two agents. Cool. Cool. Okay, the first is what we call our ICP dashboard. And the ICP dashboard is a product that we have internally that answers the question: what is our world? What is the world of customers and use cases that we care about? And what we actually do is we go ahead and use Exa, and again, Exa is this arbitrarily powerful search engine for AIs, essentially, and we just classify every possible company that is inside of our total addressable market. And I blurred out some of the details on how much money we make from each category and stuff like that. But yeah, we have categories like model providers, AI coding platforms like, say, Cursor, go-to-market intelligence tools. And this makes up our TAM, and we have an understanding of almost every company within those segments. And then for each of those companies, we can deep dive, right? So here's the example of SpaceX. We can see how much annual spend we could anticipate them to have, then all this metadata about the company. So we have a list of all the companies and then a ton of data about each company. How do we do this? Again, we're able to do this because Exa is this search engine. We take the Internet, we crawl it, we train embeddings to do web search really well. And so basically, from a technical perspective, you could think about Exa as embeddings over the Internet. And when you have embeddings over the Internet, you have this arbitrarily powerful semantic filtering and slicing and dicing of any type of data that you want. And so we use that to generate this gigantic list of potential ICPs. Cool. Next, we have a tool we call Request Lens. Request Lens, what is Request Lens? Well, it's basically a system where any time something significant happens with any of our customers, we're alerted. Someone signed up. Someone used a ton of searches. Someone stopped using searches. Someone showed up that we really, really care about. All these things are signals that we are notified about and that our team can act on. Cool. So those are the two interfaces that we have. And then I'll go over two types of agents that we have. So one is coding agents. So our go-to-market team is crazy, crazy, crazy deep on agents. Our engineering team uses a lot of agents, but our go-to-market team is, you could look at some of their dev spend and other agent spend, it's really freaking high. And that's because everybody on our go-to-market team is constantly asking agents about our customers. We have account executives that build demos for our customers. It's a system where any time something significant happens with any of our customers, we're alerted. Someone signed up. Someone used a ton of searches. Someone stopped using searches. Someone showed up that we really, really care about. All these things are signals that we are notified about and that our team can act on. Cool. So those are the two interfaces that we have. And then I'll go over two types of agents that we have. So one is coding agents. Our go-to-market team is crazy, crazy, crazy deep on agents. Our engineering team uses a lot of agents, but our go-to-market team is, you could look at some of their dev spend and other agent spend. It's really freaking high. And that's because everybody on our go-to-market team is constantly asking agents about our customers. We have account executives that build demos for our customers. It's just this crazy ecosystem where we have maybe a dozen different agents inside of our Slack, and anybody can use any of them. They all have access to tons and tons of our internal data. And, yeah, any time we want to dig deeper on an account, any time we want to make a demo, et cetera, we depend heavily on agents. Cool. And then I want to talk about another really cool agent that I'm pretty proud of. We call it JeffBot. Or I call it JeffBot. JeffBot is an AI clone of myself as much as possible. So what is it? This winter break, I'm sure a lot of you spent that break playing with Opus 4.5, and I was no different. So I was in Puerto Rico. No, I was in Mexico. I was in Mexico, and I had a week off. And so my goal with that week and with Opus 4.5 was to just try to make a digital clone of myself. And so I did things like analyze 760 of my emails to figure out what my email voice is. Like, oh, I use 18 words on average per email. And I like to end emails with best and not sincerely. All that type of stuff, right? So I made a voice for myself. And then I also made a decision-making framework. So I made a decision-making framework where I analyzed hundreds of decisions I've made in the past. And I analyzed them, and I created evals. So I actually created evals from those decisions and calibrated this agent system to behave like myself. And then finally I gave it read and write access to all the data that I am. And I personally have. And there's a cool advantage to this because I basically have access to every single system at the company. Because I'm in the nice seat of having that. And so, yeah, this thing has access to everything. And basically what happens is anybody at the company can use JeffBot to create drafts of Slack messages that are basically answers or decisions that are made. And this is a huge, great thing. Our go-to-market team uses it to draft emails, for example. Cool. All right. So those are the systems that we have at Exa. It works pretty well. Our go-to-market team is very lean but very productive. And so, yeah. I just want to cover, lastly, just a few principles. Principles I have around what it means to be an agent-first company. So, firstly, to be agent-first, you must be API-first, right? All these systems that we built, whether it was those agents or whether it was those GUIs that we have, if there did not exist really good APIs on top of any internal and external data, we'd be out of luck, right? You need to create really good APIs. If you don't have really good APIs, your agents are not going to be able to have data access. So you can think about this as MCP, CLI, whatever, right? It doesn't really matter. You just need some interface that's programmatic. Secondly, I think there's still this mistake in the agent world that's made. Hey, does everything need to be a chatbot? I think the answer is no. I think both GUIs and chatbots are both super useful and have their own benefits. I don't know how many people in the room have thought about dynamic user interfaces, but yes, dynamic user interfaces are amazing. Yes, technically AI can just produce a new UI for any use case that you have. Just to answer a question, it could produce an HTML markdown file, right? But I think there is something really nice about being able to visit the same consistent UX for the same use cases over time so that you can learn how to use some tool. So, yeah, I think having crystallized UIs and then also arbitrarily powerful, flexible chat agents are both important components of being agent first. And then finally, there's this question, hey, should you shop for Salesforce or should you build your own CRM or something, right? I actually think this is a false dichotomy. It's not a choice. We don't live in a world where the choice is between purchasing SaaS and building things yourself. The way I like to think about it is you should just be using something that is arbitrarily customizable, right? Obviously, if you build something yourself, then it's arbitrarily customizable because you can vibe code and make it better at any given point. But also if you procure SaaS, if you can make that SaaS work on your behalf and be arbitrarily customizable, then that works too, right? You don't need to build this GUI and have a proactive roadmap as to what features make really great sense inside of some system. If you can arbitrarily customize the system, even if it's a system you've purchased, then you're pretty good, right? So, for example, we use Salesforce. We use Salesforce at Exa, and it's great because it's a really good database. It's made a lot of amazing choices around what sales should look like, choices that we don't want to make ourselves, and then it's exposed as MCP. So all of our agents have access to Salesforce MCP. It works really well. Our team uses it every day. And so, yeah, I think infinite customizability is really the highest-order bit. Cool. That's all I had. Yeah, does anybody have any questions? We have time for questions. Okay, coming. Hey, so you said you took all your past decisions. Can you elaborate a bit about that? What artifacts are those? Usually people don't save their decisions. Is it Slack? Is it email? Is it other artifacts? Yeah, good question. I looked at decisions I made within Slack and email. A surprisingly large amount of everything that goes on in a company is on Slack, right? So if you just read a ton of Slack history, you can definitely find hundreds of decisions that you've made in the past. Awesome. Quick question over here. So your go-to-market team, what's the split between, are they just all AI-cracked? Or do they also have the domain expertise too? What's the split between technical and non-technical? Because obviously you need them to know how to do marketing, sales, et cetera. But are they also upskilling in terms of using AI systems? Are you handing them tools or are they building their own? That's a very good question. So our go-to-market team is comprised of account executives, which run the deals. There are sales SDRs that help with demand generation. And then there are separately a FDE org, so Forward Deployed Engineering Organization. And what I'll say is that everyone that's not in FDE has learned how to use AI really well. So the answer is they're not vibe coding. They're not generally, with some exceptions, vibe coding these interfaces that we have. But they are using the tools really, really well. And we make sure that we have training sessions and just make sure that people really understand how to use these tools. And then we have this funny thing, which is that our Forward Deployed Engineering Organization is actually the one that does a lot of the maintenance and feature building of these AI systems. And so they're both running deals and supporting deals, but then also making everything smoother by doing sales, but then also building the sales system. It's kind of a funky thing we have going on. Yeah. So, the answer is they're not vibe coding. They're not generally, with some exceptions. They're not generally vibe coding these interfaces that we have. But they are using the tools really, really well. And we make sure that we have training sessions and just make sure that people really understand how to use these tools. And then this funny, we have this funny thing, which is our Forward Deployed Engineering Organization is actually the one that does a lot of the maintenance and feature building of these AI systems. And so they're both running deals and supporting deals, but then also making everything smoother by doing sales, but then also building the sales system. It's a funky thing we have going on. Yeah. How do you think about different security boundaries within your enterprise? What you said suggested that you've got Jeffbot, which runs with all of your full privileges, and then it's available to everybody, which suggests that there's one security level and everyone can see everything all the time. Is that what you're going with, or is there some other guardrails in place? Yeah, that's a good question. We pay pretty careful attention to guardrails. So, for example, in the case of Jeffbot, when I use Jeffbot and I call Jeffbot, it has access to a ton of systems and it can, for example, do reads and writes. However, when anybody else calls Jeffbot, all it can do is draft messages, and also I don't give Jeffbot permissions to all of our MCPs and tools in the case of what other people call it. And so, in short, it's pretty well defined, or we do pay some care to the security. Okay, last question. Can you share the origin story of the FDE team? Did that just happen organically or did you intentionally do it? I'm just really curious how that came to exist. Yeah, for sure. My hypothesis on this is once upon a time the FDE role didn't really exist. Palantir started calling some people FDEs, but that was really it. And what tech companies had was solutions and sales engineers and then account executives. I was a solution. Got it. Yeah, yeah. The thing that I think has changed is that because of AI, as a technical person that is supporting revenue generation, you can actually not only support their revenue generation but then very easily build the tooling to smooth everything over. And make your own life easier. Make the lives of AEs easier. Because of AI, this is just possible now. That's two, before that was two jobs and now it's one job. In theory. Now when our team grows, right now it's about eight or nine FDEs. Will it scale such that everyone does everything? Probably not. But at least right now that's what we have, and I think that's a really good working model to get pretty far. Eight out of how many? Oh, eight of, how big is our go to market org? You have eight FDEs and the size of the company right now. Oh, we're about 115 people. Okay. That's yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay you I mean, a surprisingly large amount of everything that goes on a company is on Slack, right? So, like, if you just read, like, a ton of Slack history, like, you can definitely find hundreds of decisions that you've made in the past. Awesome. Quick question over here. So your go-to-market team, what's the split between, are they just all, like, AI cracked? Or do they also have, like, the domain expertise, too? What's the split between technical and non-technical? Because obviously you need them to, like, know how to do marketing, sales, et cetera. But then do they also, are they also upskilling in terms of using AI systems? Are you handing them tools or are they building their own? That's a very good question. So our go-to-market team is comprised of, like, there's account executives which, like, run the deals. There are, like, sales, like, SDRs that help with demand generation. And then there are separately, like, a FDE org, so Forward Deployed Engineering Organization. And what I'll say is that, like, everyone that's, okay, everyone that's not in FDE is, like, has learned how to use AI really well. So, like, the answer is, like, they're not vibe coding. They're not generally with, you know, there's some exceptions. They're not generally vibe coding these interfaces that we have. But they are using the tools really, really well. And, like, we make sure that we have training sessions and, like, just make sure that people really understand how to use these tools. And then this funny, we have this funny thing, which is, like, our Forward Deployed Engineering Organization is actually the one that, like, does a lot of the maintenance and feature building of these AI systems. And so they're both running deals and, like, supporting deals, but then also making everything smoother by, like, doing sales, but then also building the sales system. Like, it's kind of a funky thing we have going on. Yeah. How do you think about different security? How do you think about different security boundaries within your enterprise? What you said suggested that you've got Jeffbot, which runs with all of your full privileges and then it's available to everybody, which suggests that there's one security level and everyone can see everything all the time. Is that what you're going with or is there some other guardrails in place? Yeah, that's a good question. We pay pretty special, we pay pretty careful attention to guardrails. So, for example, in the case of Jeffbot, when I use Jeffbot and I call Jeffbot, it has access to a ton of systems and it can, for example, do reads and writes. However, when anybody else calls Jeffbot, all it can do is draft messages and also I don't give Jeffbot permissions to all of our MCPs and tools in the case of what other people call it. And so, in short, it's pretty well defined or we do pay some care to the security. Okay, last question. Can you share the origin story of the FDE team? Did that just happen organically or did you intentionally do it? I'm just really curious like how that came to exist. Yeah, for sure. I mean, my hypothesis on this is like once upon a time the FDE role didn't really exist. Like Palantir started calling some people FDEs but that was really it. And what tech companies had was like solutions and sales engineers and then like account executives. I was a solution. Got it. Yeah, yeah. The thing that I think has changed is that because of AI, as like a technical person that is supporting revenue generation, you can actually not only support their revenue generation but then very easily build the tooling to smooth everything over. And make your own life easier. Make the lives of AEs easier. Like because of AI, this is just possible now. Like that's like two, before that was like two jobs and now it's like one job. In theory. Like now when our team grows, like right now it's about eight or nine FDEs. Like will it scale such that everyone does everything? Probably not. But at least right now that's what we have and I think that's a really good working model to get pretty far. Eight out of how many? Oh eight of like how big is our go to market org? You have eight FDEs and the size of the company right now. Oh, we're about 115 people. Okay. That's yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay yay you