Jeffrey Wang, cofounder of Exa, argues that go-to-market is now an AI engineering and data problem, requiring a live model of your world that agents can act on. He describes building an AI clone of himself ("Jeffbot") by analyzing 760 of his own emails and calibrating it with evals from past decisions. He outlines two interfaces— an ICP dashboard classifying the whole addressable market with anticipated spend, and Request Lens, which alerts on meaningful customer events like signups or search surges— plus a dozen agents run by the go-to-market team in Slack. He closes with three principles: agent-first requires API-first; not everything should be a chatbot; and buy-vs-build is a false dichotomy, with arbitrary customizability as the real criterion. A Q&A covers Jeffbot's security boundaries and the FDE model. # Channel Presentation Observations: "Knowledge Systems: The New GTM Stack — Jeffrey Wang, Exa" ## Video Format & Context - This is a **recorded conference/event talk** ("in the spirit of this AI engineering fair"), presented live with audience questions at the end. - Speaker: **Jeffrey Wang, co-founder of Exa**, self-introduced: > "I'm the co-founder of Exa, and today going to give a talk on turning go-to-market into an AI engineering problem." - Interactive format with Q&A; speaker explicitly invites interruptions: > "If anybody has questions at any point, please please ask." ## Intended Audience - Explicitly aimed at a **technical/engineering audience**. Speaker polls the room ("raise your hand if you're a technical"), then states: > "I kind of oriented this talk around like go-to-market as presented to engineers." - References engineers' cultural bias toward product over distribution: > "As a technical person when you start a company... the bias is like, 'Hey, I'm going to just build the thing.'" ## Claimed Scope of Content - Core thesis: **go-to-market can be treated as an AI engineering / data problem** — > "Go-to-market is a data problem... you need basically a live model of your world that agents can act on." - Content covers Exa's internal systems: **ICP dashboard**, **Request Lens**, agent usage (coding agents, "Jeff Bots" AI clone), and principles for agent-first companies (API-first, GUIs + chatbots, infinite customizability). ## Channel Self-Description Evidence - Company self-description: > "Exa is a search engine for agents... We power Cursor, we power Cognition, we power a lot of the AI ecosystem." - Technical framing of the product: > "You can think about Exa as like embeddings over the internet." - Company scale (stated in Q&A): **~115 people**, with **8–9 FDEs** in go-to-market. - Speaker shares a personal origin narrative: analyzing **760 of his own emails** and past Slack decisions to build "Jeff Bots." ## Demonstrated Presentation Patterns (Observable) - **First-person practitioner narrative**: claims are grounded in his own company's experience ("what we've built at Exa"), not third-party case studies. - **Opinionated stance on debates** (product vs. distribution, build vs. buy): > "You just kind of have to do both... If you don't do both things, then you don't have a company." - **Candid self-critique**: admits early weakness — > "When we started... we were honestly pretty bad at go-to-market." - **Handles audience pushback directly**, including a security question about Jeffbot's permissions, answered with specific guardrail details. ## Claims vs. Demonstrations — Notes - **Creator claims**: Exa's scale of impact ("power a lot of the AI ecosystem"), effectiveness of the systems ("It works pretty well. Our go-to-market team is very lean, but very productive"). - **Demonstrated**: detailed operational knowledge of internal tooling, agent workflows, and org structure — consistent with an insider practitioner, though no external verification is present in the material. - No inference made about speaker motivations beyond stated views. # Delivery Observations: Jeffrey Wang — "Knowledge Systems: The New GTM Stack" ## Tone & Register - **Conversational and casual**: heavy use of filler phrases like "like," "you know," "sort of," "kind of" throughout: > "So, first just to like ground the ground like what what Exa is cuz it's sort of relevant inside of this presentation." - **Self-deprecating and informal humor**: > "we were like honestly pretty bad at go-to-market. Like we — [laughter] — we were not doing enough marketing, we were not doing enough sales." - **Engineer-to-engineer framing**: explicitly addresses the audience's technical identity: > "as a technical person when you start a company... very much so the bias is like, 'Hey, I'm going to just build the thing.'" ## Vocabulary - **Engineer's lexicon applied to GTM**: "data problem," "embeddings," "APIs," "MCP," "evals," "calibrated," "CLI," "GUI," "ICP," "TAM." - **Recurring intensifiers**: "really" and "crazy" used frequently — > "crazy crazy crazy deep on agents," > "it's really freaking high," > "make it really really freaking good," > "this crazy ecosystem." - **Startup/AI-community slang**: "vibe coding," "Twitter flame wars," "shop for the best product," "cracked" (audience's word, echoed by speaker). ## Recurring Phrases & Verbal Habits - **"Cool" as a transition marker** — used repeatedly to pivot between slides/topics: - > "Cool. So um cool. So so the hypothesis I have is..." - > "Cool. Next, we have a tool we call Request Lens." - > "Cool. Um that's that's all I had." - **Self-questioning as a rhetorical device**: frames topics as question-then-answer: - > "So, what does that mean?" - > "How do we do this?" - > "Request Lens, what is Request Lens? Well, it's basically a system where..." - > "So first, I guess like what does what do go-to-market teams do?" - **Restatement/repair loops**: frequently repeats or corrects words mid-sentence: > "Exa is a Exa is a search engine for agents"; > "I was in Puerto No, I was in Mexico." ## Teaching Habits & Structure - **Audience calibration at the start**: show-of-hands poll: > "raise your hand if you're a technical. Okay, great." - **Explicit signposting of structure**: > "we're going to go over two interfaces that we have that help us, and then two agents" — then delivers exactly that. - **Motivation-before-mechanics**: begins with "why should you even care?" before diving into systems. - **Invites interruption**: > "If anybody has questions at any point, please please ask cuz I'm aware there's a lot of talks and I don't want to bore you." - **Numbered principles at the close**: three takeaway principles (API-first, GUIs+chatbots, infinite customizability), each introduced with "firstly," "secondly," "finally." - **Concrete numbers as evidence**: "760 of my emails," "18 words on average per email," "115 people," "eight or nine FDEs," "60 million companies." ## Q&A Communication Patterns - **Affirming questions before answering**: > "Yeah, good question." / > "That's a very good question." / > "Yeah, that's a good question." (repeated for most questioners). - **Hedged, epistemic honesty**: flags uncertainty rather than overclaiming: > "Um in theory. Like, now when our team grows... will it scale such that everyone does everything? Probably not." - **Engages with audience interjections**: > "I was a solutions engineer." → "Got it. Yeah, yeah." — acknowledges and incorporates the audience member's context. ## Stable Patterns vs. Isolated Moments - **Stable (highly repeated)**: "cool" transitions, self-question framing, casual fillers, question-praise in Q&A, engineer-flavored vocabulary. - **Isolated**: the show-of-hands poll (opening only), the Puerto Rico/Mexico self-correction anecdote, the Palantir/FDE history digression in the final Q&A — none of these recur. ## Uncertainty Notes - Delivery pace, gestures, and visual aids are not observable from the transcript alone; observations are limited to spoken content. The [laughter] tag indicates audience reaction but tone of voice itself cannot be verified. # Observation Document: "Knowledge Systems: The New GTM Stack" — Jeffrey Wang, Exa ## Context & Framing - Speaker: **Jeffrey Wang**, co-founder of Exa (also references starting "X.ai" — likely a transcription of Exa), presenting at an **AI engineering fair** to a largely technical audience. - Exa described as a **"search engine for agents"** — a web tool/MCP that agents access; powers Cursor, Cognition, and "a lot of the AI ecosystem." ## Core Claims & Reasoning ### Product vs. Distribution - Wang rejects the Twitter flame war framing ("product is the only thing" vs. "distribution is the only thing," citing Glean debates). - His stated view: **"you just kind of have to do both"** — without both product and go-to-market (GTM), "you don't have a company." - Admits Exa's own bias: as engineers they initially were "honestly pretty bad at go-to-market" — not enough marketing or sales. ### Central Hypothesis - GTM can be treated as an **engineering problem, specifically an AI engineering problem** — more feasible in 2026 than ever because one person can automate much. - Reasoning: GTM teams research targets, find people, build POCs, etc.; the "grand unifying theme" is that **GTM is a data problem** — learning a model of your world of potential customers. - Proposed solution: **a live model of your world that agents can act on**, combining internal data (customer usage, product data) and external data (60M+ companies, billions of people, 1B+ on LinkedIn, news). ## Exa's Systems (as described by Wang) ### Two Interfaces - **ICP Dashboard** (internal product): answers "what is our world?" Classifies nearly every company in Exa's TAM (model providers, AI coding platforms, GTM intelligence tools) using Exa's search; deep-dives per company (e.g., SpaceX anticipated annual spend, metadata). Technical basis: crawling the web and training embeddings — "embeddings over the internet" enabling semantic filtering. - **Request Lens**: alerts on significant customer events (signups, heavy usage, churn signals, high-priority signups) for the team to act on. ### Two Agent Types - **Coding/agent ecosystem**: GTM team is "crazy deep" on agents (high Devin and other agent spend); AEs build demos; ~a dozen agents in Slack with access to internal data, usable by anyone. - **Jeff Bot**: an AI clone of Wang, built over winter break in Mexico using Opus 4.5: - Analyzed ~760 of his emails to capture voice (18 words average, signs "best" not "sincerely"). - Built a decision-making framework from hundreds of past decisions (drawn from Slack and email history), created **evals**, calibrated the agent to behave like him. - Given read/write access to all systems Wang can access; anyone can use it to **draft** Slack messages and emails. ### Principles of an Agent-First Company 1. **Agent-first requires API-first** — without programmatic interfaces (MCP, CLI) on internal/external data, agents are "out of luck." 2. **Not everything is a chatbot** — both GUIs and chatbots matter; he values **consistent, crystallized UX** for repeated use cases even though AI could generate dynamic UIs. 3. **Build vs. buy is a false dichotomy** — the key is **arbitrary customizability**. Exa uses Salesforce: good database, good opinionated defaults, exposes MCP. "Infinite customizability is really the highest order bit." ## Q&A Positions ### On decision artifacts - Decisions analyzed were found in **Slack history and email**; "a surprisingly large amount of everything" at a company lives in Slack. ### On GTM team composition - AEs run deals; SDRs do demand gen; separate **FDE org** (forward-deployed engineering). - Non-FDE staff use AI tools well (training sessions provided) but generally don't vibe-code the interfaces; the **FDEs maintain and build the AI systems** while also running/supporting deals. ### On security - Questioned whether Jeff Bot implies one security level. Wang: guardrails exist — when Wang calls Jeff Bot it has read/write across many systems, but **when others call it, it can only draft messages** and lacks permissions to all MCPs/tools. ### On FDE origin - Wang's hypothesis: the FDE role barely existed (Palantir being the exception); companies had solutions/sales engineers and AEs. What changed: **AI lets one technical person both support revenue AND build the tooling** — "Before that was like two jobs, and now it's like one job. In theory." - Qualification preserved: **"Probably not"** — he doesn't expect this to scale indefinitely as the team grows; currently ~8–9 FDEs at a company of ~115 people, and it's "a really good working model to get pretty far." ## Unresolved Tensions / Qualifications Noted - The engineer's bias toward "just build the thing" vs. the necessity of GTM — admitted as Exa's own past failing. - Dynamic UIs vs. crystallized UX: acknowledged both without fully resolving. - Build-vs-buy answered via customizability, not a definitive either/or. - FDE "one job" model explicitly tentative ("in theory"; scalability doubted). # Speaker Attribution Record — "Knowledge Systems: The New GTM Stack — Jeffrey Wang, Exa" ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Jeffrey ("Jeff") Wang** | Creator / primary speaker — co-founder of Exa, talk presenter | Self-identified: "I'm Jeff... I'm the co-founder of Exa" | | **Audience members (unnamed)** | Guests / Q&A participants | Ask four questions post-talk; one identifies self: "I was a solutions engineer" | | **Off-screen moderator/organizer voice** | Other — talk facilitator | "we have time for a few questions. Okay, coming." | ## Talk Structure & Provenance - **Setting**: An "AI engineering fair" (per speaker); talk oriented toward a technical audience (confirmed by show of hands). - **Format**: Single-speaker presentation followed by moderated audience Q&A. - **Timestamps**: None present in transcript. ## Internal Tools / Systems Described (first-party claims, not independently verified) - **ICP Dashboard** — internal product classifying companies within Exa's TAM using Exa search. - **Request Lens** — internal alerting system for customer activity signals. - **Jeff Bots** — AI clone of the speaker, built with "Opus 4.5" during winter break; trained on ~760 of his emails and past decisions via Slack/email history; read/write access to his systems (permission-restricted for other users). - **Agents**: coding agents in Slack (mentions "devin" spend); Salesforce accessed via MCP. ## Third-Party Entities & Claims Referenced - **Exa customers**: Cursor, Cognition (claimed: "We power Cursor, we power Cognition"). - **Products/models named**: GPT-4, Opus 4.5, "Fable" (comparison), Salesforce, LinkedIn (billion users claim), X.ai (speaker says "when we started X.ai" — likely self-referring to Exa; ambiguity preserved). - **Palantir** — credited with originating the "FDE" (forward deployed engineer) role label. - **Glean** — cited only in the context of a "Twitter flame wars" narrative about distribution vs. product; no substantive claim made. ## Promotional Segments - **Explicit flag — promotional content**: Opening framing "what Exa is... Exa is a search engine for agents... We power Cursor, we power Cognition, we power a lot of the AI ecosystem" constitutes promotion of the speaker's own company. Additional promotion recurs during the ICP Dashboard section ("arbitrarily powerful search engine for AIs"). ## Source & Availability Limits - **No curated metadata supplied** — no speaker bios, cited source documents, or links beyond in-talk references. - **Comment availability**: Not indicated; unknown. - **Unverified figures** (speaker-asserted only): 60M+ companies worldwide, 115-person company size, 8–9 FDEs, ~760 emails analyzed, 2023 Exa launch date. - **Transcript gaps**: Audience questions partially garbled/incomplete; one attendee question about FDE origin includes an interjected identification ("I was a solutions engineer") with no name given. \>\> Hey everybody, I'm Jeff. I guess I was introduced, but I'm the co-founder of Exa, and today going to give a talk on turning go-to-market into an AI engineering problem in the spirit of this AI engineering fair. And just a quick show of hands just to like understand the audience, like raise your hand if you're a technical. Okay, great. Okay, so I kind of oriented this talk around like go-to-market as presented to to engineers. So, happy that I did that. Cool. So, first just to like ground the ground like what what Exa is cuz it's sort of relevant inside of this presentation. Exa is a Exa is a search engine for agents. Think like agents are really smart, but they don't have access to the web. We're like 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 like talk about, you know, especially to the technical audience, like why should you even care? Like why should you care about go-to-market? I guess this audience cares about go-to-market cuz you chose to go to this go-to-market talk, but I think there's this like funny narrative right now, which is like people are like, "Oh, like product is the only thing that matters." Or "Distribution is the only thing that matters." And there's all sort of like all sorts of like Twitter flame wars like like oh, is Glean going to succeed because they're really good at distribution, but they're like what what the heck is their product? And then and other people are like, "Oh, the like the the product needs to be super good cuz agents you know, agents shop for the product, so they'll shop the for the best product." And so, my view and my experience in the last few years is that you just kind of have to do both. Like I think you have to get product right and you have to get go-to-market right. Like you got to build this thing, it's got to be good, and then you 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 kind of my view on the matter. And I I say like a really funny thing also is like as a technical person when you start a company or you start some some sort of project, like very much so the bias is like, "Hey, I'm going to just build the thing. I'm going to make it really really freaking good, right?" Like that's kind of like the bias you have as like an engineer. That's the bias we had when we started X.ai and we were like honestly pretty bad at go-to-market. Like we \>\> \[laughter\] \>\> we were not doing enough marketing, we were not doing enough sales. Um but I think the cool thing about about um 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 like a super exciting thing. Like it's like more fun for engineers than ever to do go-to-market cuz you can automate things. You can you can do so much as one person and uh etc. Also um I want to make this interactive. If if anybody has questions at any point, please please ask cuz I'm aware there's a lot of talks and I don't want to bore you. Cool. So um cool. So so the hypothesis I have is if you're an engineer or or if you're anyone, you can treat go-to-market like an engineering problem. So first, I guess like what does what do go-to-market teams do? So I have like a laundry list of things here of things that go-to-market teams do, but here are a few. Like one is you got to research like your customer, right? You got to research your targets. You have to find out information about your about targets. You have to find the right people at particular companies. You have to build POCs. Um there's like a just a ton of stuff you have to do, right? Um so you know, I'm not going to I'm not going to list everything here, but like what is the grand unifying theme? Well, go-to-market is a data problem, right? So you have all you have this like entire world of uh of of what your product does and then and this entire world of like all your potential customers and you're just going to like learn and figure out what your world looks like. And so this is my this is my uh proposal. It's a data problem and we have to solve from a data perspective. Cool. So okay, so what is data that is relevant? Uh I propose that you need basically 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, uh data about how people use the product. That's like internal data that you know. And then there's all sorts of external data, right? Like there's over 60 million companies in the world, and there's like billions of people, like over a billion that are on LinkedIn, for example, and all sorts of stuff are is is like happening every day, right? Like there's all this news. And so, when you're building like this data go-to-market system, um it's important to keep in mind just like all the different sources that exist and and and uh and are available to your agents. And cool. So, I'm going to like go through, hopefully pretty fast, just all the different components of what we've built at Exa. And just for like context, uh I've been really passionate about this for a long time. So, like Exa was launched in uh the middle of 2023, and so we were post-GPT-4. And GPT-4 was really incredible, cuz it could actually, even then, even though it's way worse than like Fable or whatever, like it could actually just automate entire parts of go-to-market. And so, from the beginning, I've been thinking about our go-to-market from from a very, very uh 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, like what is our world? Like 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 like uh arbitrarily powerful search engine for AIs essentially. And we just classify basically like every possible company that is inside of our total addressable market. And I kind of blurred out some of the details on like how much money we make from each category and stuff like that. But yeah, we have like 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 literally like 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 like 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 we train embeddings to do web search really well. And so basically from a technical perspective you can think about Exa as like embeddings over the internet. And when you have embeddings over the internet you have this like arbitrarily powerful semantic filtering and slicing and dicing of any type of data that you want. And so we use that to generate this this like 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 anytime 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. So like like our our our engineering team uses a lot of agents, but our go-to-market team is like like you could look you could look at some of their like devin spend and like 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. Uh we have like like account executives that build demos for our customers. Like it's just this crazy ecosystem where we have like 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 uh yeah. Anytime we want to dig deeper on account, anytime we want to make a demo, etc., 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 Jeff Bots. Uh or I call it Jeff Bots. Uh Jeff Bots is an AI clone of myself. Uh as much as possible. So, what is it? Well, basically this winter break uh 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 No, I was in Mexico. I was in Mexico and I would I had a week off. And so, my goal with that week and with Opus 4.5 was to uh just try to make a digital clone of myself. And so, I did things like analyze like 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. Like all all that type of stuff, right? So, I made like a like a voice for myself. And then I also made a decision-making framework. So, I made like a decision-making framework where I analyzed hundreds of decisions I've made in the past. And I 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 like read and write access to all the data that I personally have. And there's a cool advantage to this because like I basically have access to every single system at the company uh cuz I'm in the the the nice seat of of having that and so like um yeah, this thing has access to like everything. And basically what happens is anybody at the company can use Jeffbot to create drafts of Slack messages that are basically like answers or decisions that are made. And this is a huge great thing. Like our go-to-market team uses it to like draft emails, for example. Cool. Um all right, so those those are the systems that uh that we have at at Exa. It works pretty well. Our go-to-market team is very lean, but very productive. Um and so yeah, I just want to cover like lastly just a few principles um 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? So like all these systems that we built, whether they were those whether it was those agents or whether it was those GUIs that we have, like if there did not exist really good APIs on top of any internal and external data we'd be we'd be out of luck, right? Like 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? Like it doesn't really matter. Uh you just need some interface that's programmatic. Secondly is like I I think there's like still this mistake in the agent world which is made that's like hey, does everything need to be a chatbot? Uh I think the answer is no. Like I think I think both GUIs and chatbots are are both super useful and have their own benefits. Like uh I don't know how many people in this room have thought about dynamic user interfaces but like yes, dynamic user interfaces are amazing. Like yes, technically AI can just produce a new UI for any use case that you have. Like just to answer a question, it could produce like 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 like learn how to use some tool. Um so yeah, I think like having crystallized UIs and then also arbitrarily powerful flexible chat agents are both important components of being agent first. And then finally, uh you know, there's this question like, "Hey, should you like shop for like Salesforce or should you like build your own CRM or something, right?" I actually think this is like a false dichotomy. It's like like there it's not a choice. Like we don't live in a world where the choice is between purchasing SaaS and building things yourself. Like the way I like to think about it is like you should just be using something that is arbitrarily customizable, right? Like whether you like obviously if you build something yourself, then it's arbitrarily customizable cuz you can write code and make it better at any given point. But also if you procure SaaS, um if you can make that SaaS work on your behalf and be arbitrarily customizable, then that works too, right? Like you don't need to build this like GUI and like have a proactive roadmap as to like what features would make really great sense inside of some system. Like if you can arbitrarily customize the system, even if it's a system you've purchased, then you're like pretty good, right? So like for example, we use Salesforce. Like we use Salesforce at X.ai and uh it's great because uh it's a really good 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 exposes MCP. So all of our agents have access to Salesforce MCP. Works really well. Our team uses it every day. And so yeah, I think infinite customizability um is is really the highest order bit. Cool. Um that's that's all I had. Uh Yeah, does anyone have any questions? \>\> Oh, we have time for a few questions. Okay, coming. \>\> Hey, um so you said you uh took all your past decisions. Can you elaborate a bit about that? What What artifacts are those? Usually people don't save like their decisions. Is it Slack? Is it email? Is it other other artifacts? \>\> Yeah, good question. I looked at decisions I made within Slack and email. I mean, a surprisingly large amount of everything that goes on a company is is 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 made in the past. \>\> Awesome. Quick question uh over here. Uh so your go-to-market team, what's the split between uh 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, etc. But then do they also are they also upskilling in terms of using AI systems? Are you handing them tools or they building their own? \>\> That's a very good question. So our go-to-market team is comprised of like there's there's account executives which like run the deals. There are like sales like SDRs that help with uh demand generation. And then there are separately they're separate like a FDE org. So forward deployed engineering organization. And what I'll say is that like everyone that's Okay, everyone that's uh not 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, in some there's some exceptions. They're not generally vibe coding these interfaces that we have. Um but they're 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 four deployed engineering organization is actually the one that like does a lot of the maintenance and feature building uh of these AI systems. And so they're both running deals and like like supporting deals um but then also making everything smoother by like doing sales but then also building the sales system. Like it's it's kind of it's kind of a funky thing we have going on. Yeah. \>\> How do you think about uh different security? \>\> Oh. \>\> Hey. How do you think about different uh security boundaries within your enterprise? What do you What you said suggested that you've got Jeffbot which had 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 uh other guardrails in place? \>\> Yeah, that's a good question. We we pay pretty special we we pay pretty careful attention to guardrails. So for example um in the case of Jeffbot um when I use Jeffbot and I call Jeffbot has access to a ton of systems and it can for example do reads and writes. However, when anybody else calls Jeffbot all can do is draft messages and also I don't give Jeffbot permissions to all of our MCPs and tools in the case where other people call it. And so in short it's like pretty it's pretty well defined or we we we do pay some care to the security. Yeah. \>\> Okay, last question. \>\> Um, can you 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, uh my my philos- my 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 it that was really it. And what tech companies had was like solutions and sales engineers. And then, like account executives. \>\> I was a solutions engineer. \>\> Got it. Yeah, yeah. The thing The thing that I think has changed is that um because of AI, as like en- as a technical person that is supporting revenue generation, you can actually not only support the 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. Um in theory. Like, now when our team grows, like right now it's about eight or nine FDEs, like what will 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? \>\> Uh eight Oh, eight of like how big is our go-to-market org? \>\> Or eight You have eight FDEs, and the size of the company right now is how many? \>\> Oh, the We're about 115 people. \>\> Okay. \>\> Yeah.