a16z Podcast - Decagon’s Playbook for Building Enterprise AI Applications

Episode Date: July 31, 2026

Sarah Wang and Kimberly Tan are joined by Jesse Zhang and Ashwin Sreenivas, co-founders of Decagon, to discuss the evolution of enterprise AI agents, why the company increasingly relies on open-source models, and how it is helping some of the world’s largest companies deploy AI in production. Decagon has become one of the fastest-growing AI companies by building agents that automate customer support, sales, and operational workflows. Jesse, Decagon’s CEO, and Ashwin, its president, explain how the company is building enterprise AI at scale. They unpack why Decagon moved most of its inference to open-source models, how latency, evaluation, and fine-tuning shape production AI systems, and why enterprise AI requires far more than simply plugging into frontier models. The conversation also explores forward-deployed engineering, enterprise sales, AI’s impact on jobs, and why application companies will continue to thrive alongside the foundation model labs.   Resources: Follow Jesse Zhang on X: https://x.com/thejessezhang Follow Ashwin Sreenivas on X: https://x.com/AshwinSreenivas Follow Sarah Wang on X: https://x.com/sarahdingwang Follow Kimberly Tan on X: https://x.com/kimberlywtan Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

An AI agent should just be the front door of your business. And every interaction, whether it's reactive or proactive with a customer, should be handled by AI. This narrative dominated the first half of 26, which is that anthropic, open AI, they're the last startups. They're going to take over everything. Even once you have AGI, agents are going to need somewhere to store work and pull information from and reason about things. I don't think software as a whole in any meaningful ways going away. Unfortunately, the Frontier Labs, they do have small models. but you can't really control them in the way that you want.

So today, 90% of a workflow is on open source. On the specific tasks we want them to do, they actually outperform the large, smart state of the rock model. The thing that we built was not an agent that does customer support well, but rather an agent that follows business process well. Instead of us having to write these AOPs, do I just does all of that? Let's say like we hit AGI and the models can do all sorts of things we can't even imagine today.

What's Decagon's moat and like, why does Decagon's moat? like 10 years from now, still have a right to exist. The biggest breakthroughs in enterprise AI aren't just happening inside foundation models. They're happening in the products built around them. In this episode, Sarah Wang and Kimberley-Tan sit down with Decagon co-founders, Jesse Zhang and Ashwin Srinivas,

to discuss why they shifted most of their AI stack to open source models, how they think about deploying AI inside large enterprises, and why the future of enterprise software will be shaped by AI agents not just better models. Hey guys, welcome back to the studio. Thanks for having us.

Yeah, good to see. Thank you for being here. Before we get into customer support, I actually wanted to widen out a bit. And, Jesse, I'm going to actually mention a piece that you wrote recently that went pretty viral because it's right in the middle of the zeitgeist of conversation right now on open source versus closed source models. And then thinking machines, KimiK3, some very interesting open source models came out sort of right after.

And there's this really interesting debate going on around what does it mean to own your destiny when it comes to AI, especially in the enterprise. And what does that evolution look like by use case? So actually, since that's a pretty live topic right now, why don't we start there? Sounds good. So I'm going to talk about our journey first, just to make it very concrete for people. So when we started the company, the goal was just to get something working. The goal is to get something working, of course, you're just going to use the frontier models because you want to get something out there and have it. actually deliver value. And so we were using Open AI Anthropic. At that time, they were kind of

like one-upying each other in terms of how the models performed. And then at some point, as we got to larger scale, we started working with larger and larger companies, and they had millions of customers, and then we also launched our voice agent, right? So a big factor became latency. So it wasn't just like can deliver good responses. You have to deliver them really fast. And the only way to get latency down, but also kind of make our agent operate the way we wanted to, is to use smaller models. And when you want to go to smaller models, unfortunately, the Frontier Labs, they do have small models, but you can't really control them the way that you want. And most small models out of the box are not going to be good enough at the task that we want them to do. So you have to fine-tude them. You have to change them. And so that's when we started looking at open source. So this was about a year plus ago. And it worked really well because if you think about it in the agent, right, so in our agent's job is to have conversations. So it needs to do a lot of things at once, right? Like, The first step I might do is, hmm, what topic is this person talking about? Or something else it might do is, oh, is this person a bad actor that's coming in and trying to mess things up?

There's all these tasks it has to do. Each individual task doesn't need all of the intelligence of a big model. So all the frontier models are obviously very smart, but they can do a bunch of different things. Like they can do math, they can do coding. You just need them to be good at that one task. And so that's why you can use a smaller model. And if you fine tune it to be really good at that task, it can be just as good or better than the big models. So that was step one for us.

About a year ago, we were like, okay, let's start using these open source models. We took the small ones and then that's why we have now a research team. And it's a very expensive team. We have it because we need people that are really good at taking these open source models and tuning them. So today, 90% of our workflow is on open source. And again, the main reason was for latency to really optimize our voice agents. And I think we've just over the last year, we've seen tremendous improvement in how it sounds, how it feels. but still also keeping the accuracy high.

And then the remaining 10% of course, we're still using the close source models and the frontier models for a lot of new projects or new products. And I think that's just where the industry is moving to. So if you kind of were to generalize this, every model you can kind of evaluate along three dimensions. It's costs, intelligence, and latency.

And depending on what you need, you want to kind of be at the limit of those three. And sometimes you can trade off for it. So in our case, we knew that we actually pull back on intelligence because we all I had to do was that one task, but now we get these latency advantages. I want to push a tiny bit on that point, actually, because oftentimes when you see these debates being had on Twitter, the tradeoff tends to be, oh, do we want the smartest model that is very expensive, or can we dumb it down a little bit and get it cheaper? I actually think

that is a false tradeoff, right? Because what we've seen in practice is, even if you have a, quote, dumber model, you can get it, and we've seen this in practice, you can get it to higher performance on that specific task. So when we fine-tune smaller, dumber models, it's that they're just not as general purpose, but on the specific tasks we want them to do, they actually outperform the large, smart state-of-the-rock models. Right? So we end up getting all three things. It is better at the task, it is cheaper, and it is faster. And so do you feel like today, like you need the most frontier models for really anything at Decagon because your performance is very good already. We do and we often end up meeting them for auxiliary tasks, right, where when you sort of have

auxiliary models to our sort of primary conversational flow, you have an agent and it's helping a customer with their rebooking or it's helping them with a process in health care. Then these are like well-defined pots. So we have smart, fast models to do that. But we've, for instance, launched duet autopilot right which is our agent that improves the core conversational agent now for something like autopilot it is doing a very complicated job right it's saying i'm going to go and review a million conversations that just happened i'm going to try and find trends i'm going to create variants of the primary model and see which of those variants does better so now this is a much more broad open-ended exploratory task so we think for jobs like that frontier models that are very smart

that can try out a lot of things make a lot of sense Do you think that, I mean, you guys obviously, and you referenced it, Jesse, that you have a research team, right? You guys launched Decagon Labs, but even before the formal launch, it's always been a part of your culture. Do you think that enterprises will get there as well on post-training open-source models? Oh, okay. What's the timeline? Yeah, I think they'll get there, but it'll probably take longer than people think, because even with our team, fine-tuning these models is non-trivial. It's not just, oh, you can say, all right, we made decisions to use open-source. Let's just use open source.

Like you have to get the data, and then more importantly, you have to, like, have good evals. And if you think about our evils, right, our evils are very specific to us. You can't just, like, use some public eval set and like that just does the job. It's like we're testing it on our task. And so we have to generate our own benchmarks and evils. But I think the point is that at a certain point, it's strictly better to use Omensource models because when your use case is solidified and you're in production at scale and you're pretty sure this is the sort of shape of the agent, then there's no reason not to use open source

because you get these latency benefits and at the same time you get the cost benefits. I mean, again, we didn't do these for cost benefits but that's a nice side effect. And once you're there, it's like, why use Frontier for that? But for everything that's new and sort of experimental or your, as Aschamu was saying, or like kind of these products where you really need the intelligence

and you're still going to use Frontier models. And it's just so much easier to use Frontier models. Don't worry about the Infra, you just use the APIs. And I think that's why in enterprises right now, even though there's a lot of hype for open source. The sort of share of open source inference is actually going down right now because people are spinning up all these new use cases. And if you're spending up new use cases, of course you're going to use the frontier models until they're working.

But of those use cases, some might die off, but like some might, like the enterprises are like, okay, great, we want to keep shipping this and all it out. Once it's at that point, they're heavily incentivized to use open source. It's way cheaper and faster. At that point, maybe they can do it in-house or maybe they'll need help from people to to help them fine-tune it, but that'll eventually happen. I just think it'll be kind of slow. Even right now in our experience,

like enterprises have a lot of desire to move, but they can only do so many use cases at once. There is inertia there, and you have to go through all the model risk governance and all the security things. And so I think it'll take time, but it will get there. Yeah. The other reason I think it makes a lot of sense

for enterprises to kind of build their co-bundered labs is that the shape of these models is changing constantly, right? We don't just build our set of open source models and then it's done, we can move on to our next thing and maybe we'll revisit this in two years. You often need to train new models all the time

because as the frontier changes, as the capability of the models changes, you come up with new use cases for them. You find new places where you're like, oh, this task seems to be getting repeated a lot because now I have this totally new frontier model or open source model that now has this capability that they didn't have before, right?

So we find ourselves constantly training new models and deprecating old ones that are no longer relevant because maybe the frontier has advanced a lot, the open source frontier has advanced a lot and the model out of the box can do a lot of things that it couldn't do before. So because the model landscape is changing so quickly, Dacagon Labs is in a way a model factory of source, right?

We really built it to compress the time between new model coming out and useful, fine-tuned to our task model kind of popping out the other end. Yeah. Just because this happens all the time. How do you guys think about what to in-house from a talent perspective versus there's also a pretty broad ecosystem right now that is, you know, could be RL as a service, e-vals, et cetera. Like, how do you guys, what's your framework for, hey, this is mission critical and we need to do this best versus, you know, you know, Yes, it'd be great to outsource this. You know, in practice, we've seen that so many things relevant to model training

are so tightly coupled to the use case that we have, right, that we find that we end up needing to build a lot of tooling internally. When we have open source models that we want to fine-tune, we find that if we can clearly tailor our e-vouts to customer outcomes, it's way better than just looking at like loss curves over time, right? We're not just saying, oh, can I do this one specific task? We're measuring the entire system end to end. We're not just saying, is this model good at this task?

We're saying, is this model working in concert with all these other models delivering the end customer outcome that we care about? And because that is so unique to our setup, we've found that in practice, we've needed to build a lot of the infrastructure that we need to train these models and evaluate them. Now, for other things like getting labeled data and measuring the diversity of our data sets, we're like, yep, these are tasks that are common across possible companies, in which case we want to buy things from other vendors because that will just help us get those models of production posture.

Ultimately, the only thing that we care about is how can we get the best model to production as quickly as we can. And so it sounds like, you know, there's a lot of talk right now about like tokenomics and how expensive it is to actually run a lot of these models. Based on this conversation, it doesn't sound like you guys spend that much time, actually thinking about the costs of these models. Is that correct? It's really about the performance for you. Performance, latency and accuracy is definitely the driver manufacturer for most of this, right? Cost is a nice benefit in that, you know, surprisingly, this is one of the few, like, tasks

where you kind of get all the things for free, right? Like, we don't actually have to trade off cost and latency and performance. And so just by optimizing for the driver's actually latency and performance, and we just get costs is a nice side benefit. And do you think that's like something that's unique to the way Decagon is run? Or do you think there's something about like this conversation about tokenomics

that for some reason just doesn't affect you guys in the same way? No, I think if you're a growth stage company, then you're honestly like, obviously we have to be responsible with our costs, but that's not the highest priority, right? The highest priority is just growing. And when you're talking to a customer,

they don't really care what your costs are. They just care about how well your agent performs. So that's that's the main thing. So actually if you look at like our unit of output of our agent, which is in our case of conversation, that's really what our customers care about. They don't really care about how much that conversation costs to us or how many tokens.

And actually over time, the number of tokens we're using per conversation has gone up because we're actually doing more model calls to make the quality better, to do more checks, to paralyze more things. And that's just the stage we're in right now. Like eventually, you know,

if we've won the market, then that's when it's like, okay, yeah, now it's time to look at our cost and see if we can optimize further. But it's just not the top priority. I also think we as a company are at a different stage than a lot of people that are talking about tokenomics on X, right? Because the toponomic debate really is around, hey, I'm on a frontier model today. How do I analyze my cost and should I move to open source? right and there I actually think it makes complete sense

if we ran our entire business exclusively on frontier models I would care a lot of that cost and I would think a lot about that but once you're already once you've already made the jump to saying okay now we know how to think about open source models we know how to decompose upon we know how to build train and deploy these models very very quickly all of a sudden that the cost aspect becomes a lot less pressing

but if you're still in the world where you're using frontier models for everything, then I do think about tokenomics makes a lot of sense. I just want to make this meta observation that a lot of the conversation, even just now, has been about things like training models, right? We're talking about reinforcement learning, and it really does blow away what I think is, you know, a lingering misperception about what an AI application is. And just to get into that debate a little bit, because I think it's sort of this narrative that dominated the first half of 2026, which is that anthropic, open AI, they're the last startups, they're going to take over everything, applications, they're thin UIs with FTEs, you know,

with implementation attached to it. You know, we talked a little bit about deck gun labs, but can you guys just share what is your, like, how do you think about this potentially false dichotomy of app versus infrastructure company? Clearly, you guys are so much more than the UI or the implementation. And, you know, does Agent Lab, you know, popular description floating around the last couple of weeks, like, does that describe it? Like, how do you guys think of Decagon? So I'll give a quick perspective just like from the, from the POV of like enterprise. And then maybe we can talk about like broader the industry. So let's say I'm like a Fortune 100 company, right? And I'm looking out there on all my use cases. And I have a choice of partnering with an application company or

for sort of using the labs and building from scratch. I think there is a lot of merit to partner with the labs in certain cases. I think if you look at our case, right, like we just talked about all this fine-tuning stuff. I think a common misconception that people have is, you know, fine-tuning is a way to, like, customize it for that customer. In fact, most of the fine-tuning we do is, like, customizing it for our use case, like the customer service use case. Yeah. And it's worth it for us to do it because that's all we do, right?

We do these agents across all of these different customers. And so it is worth it for us to put in a ton of time and research into like, how do you tune this one model to be good at selecting customer service topics? But if you're the enterprise, is it really worth your valuable research resources to, like, tune a model for these like customer service behaviors? Probably not. So that's like, that's one reason why people partner with applications. Another reason is, let's say I do put in the engineering effort to build like a,

some agent myself using the frontier models. And to my earlier point, you know, I'm not fine-tuning for behavior, but I'm sort of teaching the AI my own procedures. And again, that doesn't happen through fine-tuning. That happens like in context because if you were to fine-tune on that, you would have to reverse it every single time. You change your procedures, which doesn't make sense. And so you kind of build out your logic and you're building your business logic in.

Well, then you launch the agent. And then the second day, you look at your conversations and you're like, oh, well, actually I need to change these three things. And now it's more engineering effort to do that. And it's like constantly engineering effort. So I think people will partner with applications when the use case calls for a broader platform where there's a lot of value in using, you know, the stuff that we've fine-tuned and using the software stack we've built on top of the models to capture business logic.

And that stuff has nothing to do with the models, right? Like how did business logic gets captured by this AI? Like, how do you handle someone calling in because, you know, their flight was canceled and they need to rebook three people at once. That is business logic that the AI needs to know and you're encoding that, but that has nothing to do with the models themselves. And so that has to exist in the application layer. I think that's where applications will still shine because you still need the application

there and it's not so much the models. And the labs themselves will have more application capabilities, but those will be fairly general. Like you can maybe build general agents that can do this thing or that thing. But for a lot of these like core verticals, you know, like ours, our thesis is that, you know, you're going to need something that's, like, very deep and has all the integrations, has all the ability to capture business logic, has the ability to run, you know, tests and experiments and then review the conversations and run QA and, like, you know,

have tooling for your compliance team to monitor, like, what's happening. So that's our thesis on it. And so it's kind of, it's, it's not black and white. Like, there will be some use cases where it does make sense to use the frontier models, but there will be these, like, core verticals where going super deep makes sense. Yeah. I also think. think everyone is kind of bleeding into everybody else's space alone. True. That's a convergence. All the labs are building applications on top of it because rightly so, they're saying this is how the enterprises dot us more, right? And this is how the enterprises see ROI from using

our products. Us on the application layer, we're realizing that, hey, we can squeeze out a lot more performance and latency and cost for the use cases that we care about by building our own models. And I think this split, this kind of bleed over makes sense. And I think it'll continue. I'm not as bought into the labs or last startup view of the world, though. And I think this is true both for SaaS companies and for the new AI startups. Because in a way, human beings are kind of AGII, right?

and human beings have needed to use software for lots of things. You know, you need databases to put stuff there. You need CRMs to track things. And I think even once you have AGI, all our AGI agents are going to need somewhere to store work and pull information from and reason about things. So I think, you know, a certain class of SaaS companies that were solely built for people to do work

might face a bit of heat. I don't think software as a whole in any meaningful ways going on. And I still think on the application layer, there's so many different kinds of work that need to be done that can be done fostered more efficiently, more cheaply. So I think there will always be a space for application layer companies. Maybe in the long term, application layer companies just become labs for specific verticals, you know, because your primary product ends up being the models that are just really good at doing those specific tasks. But I think the application layer is probably here to stay. I also want to kind of pick on another thing that you kind of said in pausing. Yeah, please.

And maybe this is like a spicier take of, oh, our application layer companies just four deployed companies that are kind of doing the last mile of work. Yes, right. Well, I was saying that's a misperception, but I think it is a common one. Yeah. I think it's a really hot thing. Also, again, not to pick on tech Twitter to be like, oh, like, you know, we need to bring back the forward deployed engineer and, you know, every company is hiring tons of four deployed

engineers. I think this is a trap, actually. Oh, say more. Okay. My view on this is that four deployed engineers are necessary or newly necessary for early stage AI companies because the workflows are new, right? If you're building a SaaS company five years ago, most SaaS products are pretty well explored, right? Like, you roughly know what the user is trying to do, and your job is maybe come with a slightly cleaner workflows, but broadly you know what the user's trying to do with a design app or a CRM or something like that because those workflows have been explored.

With AI products, nobody knows what the workflows are because nobody's used these things before. So a forward-deployed engineer in this case is honestly just embedding with the customer to learn the workflow for the first time as the customer learns the workflow for the first time. And they're kind of, you know, kind of paving the road.

like, you know, they're kind of laying out the track as they see which way the train is going in a way. But long term, I think they should just be building product, right? Like, once you know what the workflow is, you should not be relying on forward deployed engineers anymore. Because once you know what the workflow is, if you can productize it, you should productize it and then become, you know, typical company with these scaling properties of a tech company. And if you can't do that, then you're just building a glorified consulting truck. Well, I'd love to dig into this more because I know when we started working together, probably almost exactly three years ago, and you guys landed on this idea, there were two things that were relatively contrarian that now feel kind of standard. The first was when you started an AI customer service, a lot of people are like, that's a GPT wrapper. And we talked a lot about why that's not the case.

And then the second thing you did was say, like, hey, we actually want to do the work ourselves. Like, we don't want to just be a software platform. And now we have the term for that. That's like AI agents and everything. And you've popularized agent PMs and forwarded as a new. type of role or more common type of role in Silicon Valley. But your agent PM slash forward deployed team has actually evolved a lot since you first got started to now. And so we'd love to talk about that. Like in the early days, what did it actually look like? And then as you started to learn

about these workflows and we're able to productize them better, how is that function actually evolved for you guys? Yeah. If you look at a lot of our forward deployed teams, they are building product in one way or another, right? So all of our four deployed engineers, for instance, build core product, right? Their job is to go in and understand, as we're working with an enterprise, what are the things that they need that the product does not do today? But the output of that is not a one-off thing that is just built for that customer. It is something that is contributed to core product in a way that the next 10 customers that ask about the same thing get it for free. Right. Similarly,

our agent PMs are working with our customers to understand, you know, how is the product broken today? How can this actually be deployable within an enterprise? What are the new things that we need to build to our core product to make it deployable within an enterprise? So at the end of the day, all of this boils out, boils down into product improvements, either through actual product improvements or through honestly process improvements, right? Like we work with very, very large And we help them through the journey to go from, okay, this is what your org looks like today. Here is how we can take you through changing your processes, through implementing new technology, into this world where agents are doing a lot of work for you. So a lot of their product work is

also processizing a lot of, you know, how we make that, how we help a company through that transition. And also, when you used to be a deployment strategist at Palantir, so you're very familiar with the forward deployed model that Palantir popularized. How different is that? at what you did at Palantir versus the way you conceptualize this role at Decagon. So I do think people use the term FDE very loosely in Silicon Valley. Yeah, and I think it's dangerous to mix the two of free consulting work versus actually doing product. You know, Sharm, who's the CTF Palantir today, had a phrase, internal, I think now it's been written about a ton.

He would say, four deployed engineers eat pain and extreme product. Yeah, I think it's a massive misconception because people are like, oh, Palantir is such a hot company and they're doing so well. And this is like a cool take on how to implement stuff. But first of all, very few companies, if any, can do what Palantir does, which is like close massive deals off the bat. And like it's kind of worth it to spend all that effort.

So I think a lot of the people that are doing this like super forward-employed strategy and like, hey, we'll do any AI use case for you, they will eventually have to reckon with, like, okay, can we find a product that's scalable? Otherwise, you are just building, like, a modern, like, eccentric or something, which, yeah, could be good if that's what you want to do, but I think people kind of conflate the two. It's like, hey, I'm building a hot, like, software company

and, you know, we also have FTEs and, like, that's our big strategy. So that's something that we've generally been very mindful about from the beginning is that we really view ourselves in our core. it's a product-led company, right? In the sense of, you know, we're building a core product that everyone can use, and we're not just here to, even though we have a large team now, just like build whatever use case that pops up, because, you know, ultimately everything has to go into the core product.

Otherwise, you can't scale. At the same time, of course, you know, I should say we also kind of sales-led in the sense of, like, the product is informed by sales. So we're not sitting there and just, you know, coming up with product to build. And so you kind of have this system where, as Asshma was saying, we have all these people that are forward-deployed in the sense that they work very closely with the customers. Their job isn't just the spin-up, like,

random new use cases here and there and just doing whatever the customer wants. Because in the short term, it could actually lead to larger contracts, and you can kind of hunt for wherever the pain is, but then long-term is just very difficult to scale. So their job is to kind of compile all those learnings from sales into a core product.

And the goal at the end of the day is, like, we should have the best product out there and be able to iterate on that faster than everyone else. And that's in our space, at least, our vision of like, hey, the winner in this space is going to be very product. I actually want to pull on this thread of, you know, that you talked about where your FDs are actually approving the product. You know, DeKon is a very product-driven company. So just to kick off with a very small, seemingly unrelated anecdote, but I was just trying to convince someone on the broader team to not leave.

A16Z for a Frontier Lab. And one of my arguments was that there was a good long-term career here. And the response that this person gave me was, we'll have AGI, we don't need careers in the long-term. It really hit me because I thought I was AGI pill, but I had really not thought about from that perspective. And I'm curious, you know, we talk about the product improving, right?

Can you make that concrete for us? Like, what are some of the oh-shit moment? as you improve your product for your customer, either from your end or your customer's end, if you can share on like, oh my God, I didn't realize AI could do that. And then, of course, I'm going to ask you your thoughts on AGI and what that timeline looks like

because you're in the nitty-gritty trenches of the enterprises using AI. So you may have a different perspective than, you know, we do. The first thing I want to say is I'm like certain there will be careers after AGI. The reason for that is like most of our jobs for sure are four jobs are kind of like made up

most jobs are made I have a very real job unless you're like building infrastructure or like growing food or something like most jobs are kind of like layers of abstraction built on top of like other stuff right and that isn't to say like the jobs aren't valuable it's just they're kind of made up

so when AGI is here like it will change people's jobs but people will stop jobs because you're still going to do things for other humans and whatever So I don't really believe that couriers will be gone after AG. I don't think people are just going to be sitting around. I'll say one observation which is like for me it was definitely duet.

So early days when we're building the product, right, like the core problem we're solving, again, being back to sales led. We talked to a bunch of customers and they're like, yeah, the value we want to get out of what you're building for us is that we can put it in front of customers. They can have conversations. And it's giving them much better experience. And also it's like, you know, way easier for us operationally, right? It's like you're saving cost and you're making customers happier. So that's like the first agent that we built. And that was like the core agent we worked on for the first like year,

year, two years. And the agent on our end, when we were building it, can sit up a ton of stuff. Like we would have to, you know, write these procedures. And we kind of create our own format of procedures. We call them agent operating procedures that teach the AI how to do things. We have to write these tools that the procedures can use to access systems and pull APIs and whatever. And then after that,

we need to like create all these tests to make sure that this thing is working well and that you can kind of simulate all these different situations and afterwards once they're in production like we would manually be reading conversations right there's like a ton of work that goes into it even though the core product we're building is is itself an agent and so what a duet is is it's kind of a separate agent it's like a second agent that's much bigger much slower but its job is to do all the tasks I just described so now instead of us having to write these aops and write these integrates and write these integrations and tools into their systems and write these tests and monitor the conversations, do I just does all of that?

So it's like a second agent that is smarter to do all of these things. And it just feels very magical because you can just literally tell it like, hey, I have nothing built yet so far, but here's a bunch of transcripts I have and here's some documentation, like you go figure out the best way to like do all these procedures I want. And it'll go do it. And then of its own accord, it'll also write the test and simulation. that go along with those. And once you're done with that,

and you actually put it in front of customers, it'll be the one that's monitoring all the conversations and it'll flag things where things are going well or poorly. And it'll say, yeah, I read these 1,000 conversations. And actually, there's this one topic that we do really poorly on. And I've noticed that. And I've also drafted these improvements for you. So it's like one agent that can do all of that.

And so that's very magical because, well, first of all, it was not possible when we first started the company. It only became possible when all the reasoning models got better. And of course, Anthropic Open AI are making these reasoning models mostly for the cloud codes of the world. But they are also really good for like, do it, for example. And that was kind of like a moment where it's like, oh, wow. Like, first of all, you can just see the improvement over time of the models. And two, it can do all these tasks where it just would not be able,

you would not have expected AI to be able to do all these tasks at once. but it can do them very well. And I think that's, that was like a very visceral moment of like, well, the models are getting a lot better and they're becoming very generalized. You know, like they can do all these things. Like clearly the models were not trained on like our specific task, which is in writing these procedures and writing these tests, but they're still good at it. And also to your other question of how, you know,

how did we come up with all this and how did the product improve? every single thing that Jesse just talked about was the result of four deployed people doing things and us figuring out how to productize it.

Right? So for instance, we realized that hey, when we go into a new customer, we need to spend all this time writing up the AOPs manually. And we're like,

wow, this is quite a lot of time. How do we productize this? And we built that into Duet. And then the second part, which we called Duet autopilot was once we built Duet, you know, people were using Duet to write things up

and then we're like, oh, wow, there's still a lot of of time that goes into iterating upon the agent, right? Once it goes live, like, reviewing conversations, figuring out how to improve it. And we're like, great, let's productize that as do autopilot. In fact, AOPs themselves were a result of this exact scenario, because before AOPs, you would have to write all these procedures in code. And then we found that, oh, it's taking a lot of forward-deployed engineering work to write all these things in code. Wow, wouldn't it be so

much easier and efficient if we could productize it by writing it in plain text? Right. So, So the way we think about like product improvements, forward-deployed engineering investment, everything is built around what can be productized from forward-deployed work so that engineers and any kind of customer-facing resources on our team don't need to be kind of as heavily involved. Can I ask you as like kind of a blunt question on this line of thinking?

So I know we've already talked about like why open-Aanthropic won't be the last startups and you've talked about like why there's room to have like much more specific use cases and specific companies. But, you know, you've also got had like, oh, shit moments where you're like, these labs are getting so much better and the models are getting so much better. And so long term, let's say like we hit AGI and the models can do all sorts of things we can't even imagine today. What's Decagon's moat at the end of the day after all of that? And like, why does Decagon like 10 years from now still have a right to exist? I think in the short term, actually, it is. the ability to work with enterprise resources.

And what I mean by this is that the capability of models today is far greater than they are being used for within the enterprise, right? By which you can't just take a model and say, I'm just going to give this model access to everything within the enterprise and it'll just figure everything out, right? Like that's practically not how these things work. So to make models like this deployable within the enterprise, price, right? Like, let's assume that every model is, like, just perfect and makes no mistakes.

But to make something like this deployable within the enterprise, you need to say, okay, I need a way to be able to tell the model what it can and cannot do and make sure that it cannot do anything like catastrophically wrong. Then I need a way to make sure that, you know, hundreds of people within the enterprise can collaborate to make sure that the agent is behaving as expected in the use cases in which they're experts. Then I need a way to be able to test this model and make sure that it doesn't cross any like regulatory lines that I have and tested, make sure it works well. Then I need a way to, you know, look over the, you know, millions of conversations that happen for me to extract insights for the rest of my teams, right? So there's a lot of just infrastructure

and software that you need to build around these models to make them deployable within an enterprise, to make them work with all the legacy systems that these companies have. And so I think for the next few years, that's probably going to be, you know, the primary thing that these models need to be able to work. Now, once that gets commoditized because the agents can build that on the fly, that I don't know and we'll regret in three years from now. By the way, I think just listening to you guys, it's very clear that you guys deeply understand how to sell AI to the enterprise. And I don't just mean, you know, mid-market, newly IPOed companies. I'm talking about some of the largest companies in the world. And I think this is particularly interesting because you both are very, very technical, but also go-to-market animals.

So I want to talk a little bit about that. But, you know, it just feels like you've turned what maybe started as feeling more like a David and Goliath with multiple Goliaths market dynamic to really a two-horse race between you and Sierra. So share a little bit more about why some of the largest enterprises in the world are buying for. you guys. And I think what's really remarkable to us is people have studied application software for over a decade. The sales cycles are crazy fast. I mean, I'm sure you guys with urgency want them to be faster, but like usually you don't sell contracts that big to enterprises that big, right? That takes two years sometimes. So maybe just share a little bit more on, it's a long question, but like, how did you grow that commercial? Did you come with that into founding the business

and what's resonating with these large companies that enables you to get in and move so quickly. Yeah, I mean, we have a lot of respect for Sierra and also just other folks in the space, generally the big platforms. Like they all, the platforms themselves move a bit slower, but I think we've met a lot of those teams.

They're very competent teams. There's optimizing for a lot of different things at once. Decadgon versus Sierra, I mean, our most recent customer actually turned off of Sierra to come to Decagon. And sort of the reasoning when we asked them was, it kind of goes back to this like deployment model. It's like, you know, when they worked with Sierra, it was mostly FDEs,

and it just felt like a black box where, you know, the FDEs were good, but they had to go through the FDEs for everything, so to build new journeys or to even get like a deeper understanding of what was happening in the conversations. And then over time, that kind of just created a lot of drag on how quickly they could move, right? So in the initial deployment, that was good, but then over time, maybe the FDEs were staffed at other things. and it just took them a while to get insight into what was happening and then build out new journeys, right?

So over the course of the year, they may be built out, I think they said three. And so the reason they came to us is because they had that frustration and they wanted to kind of have a different model where it was a lot more productized, right? Back to us being like very product driven in our vision. It's they should have a core product that even if we're there helping them, even if we are forward deployed, it is like a, in service of helping us. helping them build a product that they can use themselves and iterate really fast and kind of have everything in their control. Right. So we like to call this like a glass box approach instead of a black box.

And yeah, so within basically a month, they spun up like seven new journeys on deckingling. Wow. Yeah. And it'd taken three, a year to get three. Yeah. Okay. And so it's just kind of the speed of iteration. Like some teams will really like this, like, hey, we have control of it.

Our teams, especially our non-technical people, can come in. and do things and they understand what's happening and in the conversations. And maybe there's other teams out there that actually do like the, like, hey, you guys do everything for us and that approach. But that's kind of the difference in their approaches. And that's why we've been, I would say,

having a lot of success there. And then zooming out, just selling to the enterprise. Yeah, I mean, this is something that's, you know, Ashman and I have never sold to the enterprise before. And I think it just so happens that both of us find sales exciting. And the enterprise, it was kind of like quick learning curve for us. So I don't think, I think a lot of it obviously came kind of naturally just because our space is so hot.

And like generally in these conversations, we're not really having to convince people to like invest in this space. It's like more of, hey, we're the right approach for you. So like you partner with us. And yeah, with the enterprises, it's really just about like navigating the orgs and really having empathy for what they value and what they're afraid of. So yeah, I mean, we just back to being sales led, right? Like we always from the beginning we're like, hey, we're going to be like extremely strong on the go-to-market side and that's going to inform the product even though we have this product-driven philosophy. Like we don't want to just be dreaming up random products to build. So we always had that DNA and then in the early days we were just, yeah, pushing really hard.

I think I also want to say, I think we got kind of blessed with a really strong early sales team. And we have a lot of really talented people in that group. And that helped us really get leverage as we were talking to, you know, the big enterprise. Some of whom cold applied to you guys in the early days, I remember. Yes. Yeah, cold applied. Because I think they were working in the space already. And they were seeing from afar, like what Decagon was starting to do.

Yeah. Yeah, so some of them had like non-traditional sales backgrounds, you know. So they had non-traditional sales backgrounds that coming into sales. The other profile we had a lot of in the early day, We were just like Ivy League athletes, I guess. And those profiles were kind of a good foundation for the group. And we've had to scale that team really fast, which is never easy. So there are things that we're still trying to catch up on in terms of enablement and in orc structure.

But because we've always had that intensity on the sales side and the whole company knows that, like, you know, everything starts with sales and it kind of propagates back. You know, we've always had that focus. the other thing I think that helped us a lot, you know, to your earlier point about how did you get some of these large deals close so quickly was I think we were very curious about how we could productize parts of it within the enterprise. Right? By which I mean, we aren't a company that just says, hey, here's a product, we'll throw it over the wall and, you know, you get it a year later. Because within a lot of these enterprises, the question they have internally, in addition to, this product work for me is, can I actually get this live? Right. And with a lot of these enterprises, it's actually complicated, especially if you're in financial services and you're regulated, for instance. So we actually spent a lot of time sort of mapping out that part of the journey very well so that when we walk in to one of these enterprises, we can walk them through

in very granular detail how we go from this first meeting today to going live at 100. percent. So, you know, at this stage for a company like you, this is what your model risk process is likely to be. This is how your testing process should look like. This is how we should do the initial rollout. This is how we should catch any issues that come up and how we're going to fix them and how we'll ensure that they don't happen again. So the product and technology part of what we sell is important, but for these large companies, equally important is us helping them think through the process to actually get this deployed and at scale. Because I think that is something that often gets overlooked by tech companies selling into enterprise.

Yeah, for sure. And by the way, I can also personally attest to the strength of your early go-to-market team, having met a bunch of them. That being said, I don't want to underplay how many times a decision maker has told me that one of the reasons of many, right, that they're going with Decagon is they want to make a bet on you guys. They'll literally say we think the founding team of Decagon is going to move the fastest. This is a very fast-paced market.

It's changing on a weekly, if not daily basis. And we think that you guys are going to look at the chess pieces and make the right moves because it's not sort of like a, oh, everything's going to be the same in, you know, a year or even six months type of market. So I'm curious, I mean, don't give up too much alpha here, but how much time do you guys spend on sales as founders? and how has that evolved over time? I probably most of my time, like 80%, maybe. Yeah, okay. And yeah, I think a lot of it is just pushing speed.

So some of it is like, hey, like as one of the founders, you just have to be in calls and like, you know, people want to meet the founders. But also it's just how can I be the sort of the main force that's pushing our team to go faster, but also just like the partnership to move faster. One of the things with that is like, you know, now we work with, you know, several of the largest, you know, banks in the world and airlines and

and telcos. And no matter how fast you go, like, there's all, there's, those are still like massive organizations and it will take time. And so one of the things that we really try to do is, you know, kind of take the project and piecemeal it. So we're not just deploying across every surface area, every use case at once. That's really just pick, you know, one or two of the top use cases and just get a win there. And I would say that's, that's, that's, that's, helpful, right? If you navigate, like, a big bank, like, it's not going to be like a quick, like, you know, you just close a big deal. At least for us, it's not me. Some people can do it. But it's, yeah, it's still a lot of effort. And it's, it takes time. And so you have to figure out

ways to, you know, design things from a process perspective and an org perspective and in a product perspective as well that like just keep shortening that and like finding clever tactics. And that kind of takes founder involvement. You wouldn't really expect a sales team to just like constantly be coming up with new configurations there because they're not responsible for the product. They're not responsible for the end-to-end process that the company runs. So having the founder involved there is very important, I would say.

And then the salespeople, their job is to kind of execute on the sales side, like build champions and navigate the org and so on. The other reason to also spend a ton of time with both sales prospects and existing customers is also because the market is changing so quickly, being able to really quickly understand what are the things that we are not doing today that we should be doing very quickly, right? Because model capabilities are changing all the time. As models roll out, people are seeing other things that happen.

And they're like, oh, wow, this was really cool. And like, I'm seeing this here and you guys aren't doing that as well. So being able to like stay really, really close to that feedback loop because that's something we never want to, never want to let go off. Yeah. Do you want to talk about how that like informs product roadmap, meaning probably like two years ago or so, most of Decagon's customers were focused purely on customer support? And nowadays, I would say that's actually not true. You guys have broadened your vision to mostly, like, to be like an AI concierge for your customers.

Like, do you want to talk about what the distinction between those two actually is and in practice, like what that means for both your sales teams and your product teams? So, you know, when we launched the original set of use cases that we, sold were in customer support. And the reason was because, one, that was one of the biggest challenges that a lot of early customers were facing. And two, that was where the capabilities of the models ended at the time, right? Like, that is all, that is the pretty much the limit of what they were capable of doing.

Now, however, as models have gotten better and our customers have realized, well, why would I have one set of models that just learns about my customers when they have a problem? and something else when they come to me to buy something, right? And so we had a customer that we originally went live with them for customer support. And then they realized they were like, well, you know a lot about our product now. You know about the capabilities that it has because you need to do that for customer support. You know how we like talking to our customers and our brand. Can you help us with inbound sales, right?

When someone comes in, answer questions about us, do some discovery, and then assign it to the right. enterprise rep if it's a deal of large enough value. We had another customer that started using us for a lot of operational workflows. So we are able to now proactively reach out to them once we start seeing any kind of issues on that customer's account. Because ultimately, at the end of the day, the thing that we built and we kind of built this intentionally from the start was not an agent that does customer support well, but rather an agent that follows business process well.

Right? And executing on operational workflows, doing sales lead qualifications, answering customer support questions. At the end of the day, is just an agent following a business process. And we kind of built it flexibly enough to kind of do all these things

because we realized that, hey, at a certain point, the models are going to get better and they have. And what do they specifically get better at that allows you to do that? It is specifically the ability to follow instructions well, right? So when you had models, you know, let's say a few years ago,

you'd have to give it very, very tight guidance, very specific instructions that you didn't want it to deviate from. And as the models got smarter, you could kind of give it broader and broader guidance, bigger and bigger instructions and just trust that the models have good enough sense to interpret it like a human would and kind of fill in any missing gaps, right? Because for, again, for customer support,

you can have a very tight pot that a model should fall, and that's all you really need. Whereas for sales qualifications, you kind of want to ask open-ended discovery questions. The conversation is going to kind of bob and weave, and so you need the model to kind of fill in with reasonable things. So that's specifically kind of what the model has got better out over the years. Yeah.

I think if you think about, you know, what is the like 12-month product roadmap? Because things are moving so fast, The real answer to that is like, you know, we're kind of like see how it evolves. And we obviously know what we're working on now. But I think realistically in today's AI world is very difficult to have like a 12-month roadmap to a T. You maybe know how like some themes of what you want to build. But ideally, if you have those things, you just build it like right now because it's so fast to build things now.

So I would say that that is one element. But then the sort of long-term vision is still very clear to us now, right? Which is we use the term concierge. but really just means like, hey, an AI agent should just be the front door of your business or your brand. And every interaction, whether it's like reactive or proactive with a customer, should be handled by AI. And we've already seen that AI is very good at that. Customer service is like a huge pillar of that or all these inbound interactions. But why not have also be able to do all these other things?

So over time, again, we're not trying to figure out on our own what these things are. We kind of have now have a lot of customers that will give a signal on the things that they care about and those will be the things that we built. We've talked a lot about how the models are getting better and, you know, obviously your capabilities are moving along, even, you know, ahead of that progress. What are some of the bottlenecks right now that you're seeing? Whether that's on the capability side, I don't know, it could also be, you know, around persistent memory. I don't know if you guys feel like that's kind of up to snuff on where you would like it or could be other bottlenecks. But curious, like,

What would you like to see and what's kind of holding you back? Hiring. Got it. So it's less on the AI side. It's actually like people. We are, we are voracious consumers of tokens, but we've always loved more great people.

I think there's so much to build these days. Yeah. It's, you know. And why can't you hire AI agents to do the things that you're doing? Yeah, we are baracious consumers of token. Like our token bills are better than large. but, you know, there are still things, I don't quite yet think we're at the point

where we can have the AI agents make decisions on what to build and kind of have that, the taste of is this done yet, right? So we can outsource a lot of specific execution steps, but I don't yet think they're at the point where they can make the call on what to build, what to exclude things like that. So the model's improving,

have they since, like, you found it three years ago, has it changed your hiring needs at all? Because a lot of people are like, oh, you can build, like, one person, unicorns, you know? Yeah. You know, I think, you know, this argument does get tossed around a lot, but I think the, the,

an easy counter example to this is all the, the AI coding startups are hiring like crazy. You know, they're like the most sophisticated. users presumably and they are hiring like crazy. I think the reason is just because everybody has access

to these tools. And so if our competitors are going to use them and build more things, we need to build more things, right? If somebody else said, oh, here's our roadmap and now we can get through it in a third of the time and then they just stop hiring,

we would just take that to mean, wow, we can get through it in a third of the time. Great, let's build three times as much stuff. And it turns out everybody you know, does the same calculus, so everybody both needs to keep hiring more and ships more. So it is great for consumers of these models, but I don't think it has material to change our hard on plan. It's so funny.

I thought you were going to say something like, I don't know, latency of voice models or something like that, but it seems like on the technological bottleneck side, it's pretty. Yeah, there's still stuff that we're waiting for, right? Like, you know, voice to voice models is an interesting frontier that there's some. still research happening on, you know, the getting smaller models to be smarter, smart out of the box, right? So there's, there are going to be still developments that we are watching closely that we care about. But from a business perspective, it's less on the model side and more on the, just like, can you build the company fast? Yeah. Actually, maybe since

we're on the topic of hiring, and, you know, I feel like grind slop has become this theme on X. And it's so funny because, you know, as a VC, like, I'll admit, you know, when I, I mean, you guys are famously in the office, six, seven days a week. I hope this doesn't get marked as Grindslop now. But, you know, I think constantly hustling for your teams and your customers. And it's so funny to see that kind of turned on its head. And so I'm just curious, what are your thoughts on the narrative out there? And, like, grindslop is such a general term. but, like, you know, you guys grind, but there's also a lot of camaraderie

and excitement in the office. So, like, just, you know, say more about that and, like, how you're building the culture. Yeah, I mean, grind slops a funny term. So we have never posted grindslop because we kind of view that, like, working hard is just, like, I don't think people are, like, working hard to grind. It's just like, oh, there's a lot of stuff to do.

Like, we kind of, people spend time there mostly because like, hey, it's, you know, this is like a fun time of our life. Like, we want to take advantage of our talent and sort of potential so that it's not wasted. I think that's, that's the main reason. And it's a very sort of like, it's like many orders from like the main goal, which is like, can you build a good product and can you win in a space? And but it's like, one of the effects of that is that people work harder. And even from the beginning, like, we, yes, we have an office culture, but like, we're never mandating people to come. coming on the weekends. We don't really care how long they are in the office. It's just

people are in the office just so that like we can maximize communication. And that's how we view it. Like I don't view ourselves as like, you know, abnormally grindy or abnormally ambitious. I think like we're, I think we just like I have a lot of ambitious people around me like Ashvin and all these people. So it kind of just become normal and like everyone works hard. because it's kind of like normal. So I don't think it's like something that we view as, you know, something like super special. Yeah.

And we kind of also view a lot of what we do very much as a team sport, right? Where we very rarely have lines between our orgs in that you will very commonly see engineers on early stage sales calls. You will see salespeople like debugging parts of the product. You will see our APM team. in absolutely both ends of the spectrum. And so I think being able to have teams that are so kind of disparate from like a function perspective

all working together, kind of, one, kind of needs people in the office because everybody's kind of jamming on ideas together. But two, it also makes it fun in a way because, you know, everyone is like working together towards some very specific outcome, right? It's either building this thing for this customer in time for the deal to close or launching this new thing. And because it's so many different teams working together,

it's kind of a, it's kind of a we're all in this together to cross the line. Yeah. And how does that scale as, you know, you've launched a lot of new offices. Recently, you've a new Australia office, London office. Your New York office is growing like crazy. Yeah. How do you maintain that culture when you guys are both in San Francisco? I don't know.

I mean, I don't think it's a solved problem for us. like we're constantly working on it and like every single time the company gets to the next days there's like new things we have the institute to just make sure that everyone understands the culture and there's like very high accountability and um you know there there is pressure because there should be and so that's something that we're constantly adding on because in the first 100 people it doesn't really matter because everyone kind of knows each other and like everyone's but like as you grow people might not have no one's communicated the vision to them or communicated the culture to them And, yeah, I know like Ben was talking to us about the A16Z culture, right?

It's like how it's very like action-oriented. And you can't just like put like fluffy stuff on there. And so, yeah, it's all these things that we're trying to do a better job of as we grow. The other thing is also we bring everybody that we hire out to San Francisco for a couple of weeks when they start. So they're kind of immersed in the kind of the original kind of super, Yeah. Of culture. And then for every new office, right, at this point, New York and London, all these offices

are big enough that they have the original Decton culture there anyway. But for brand new offices, we actually have people from one of these huds go out and spend a few months there, really, until the office becomes big enough and has its own kind of culture so that it doesn't kind of become too different from what kind of the original. back we've got into culture was. Actually, on the topic of international, we're, so we brought on Ragu, Ragnaram last year,

obviously former CEO of VMware. And in addition to investing, he's helping us build out a ton of our international capabilities. And I think one of the things that we've seen is that our AI companies are just getting pulled internationally way earlier. Like, for you to have an Australia office,

it seems premature, except for the fact that, you have customer pull. Your scale is quite large for, you know, how long ago you were founded. But maybe you say more about that. Like, does that translate, like, does your product translate well to these other GOs? Are there more enterprise concerns or fewer? Or is it kind of just comparable to the U.S. market? Yeah, I think there's two trends. One is that AI is just such a phenomenon that every buyer out there has, you know, tried chat GPT or whatever. And so there, there is a lot of just top-down pressure from boards and C-Suite's to just get moving on something.

And if you think about a lot of these businesses, they're like, hmm, how do we adopt AI? Well, it's, you know, let's do some coding agents and, like, let's do customer service because those are, like, the obvious ones. And so there is a lot of pull to your points. And then the other trend is that language is a lot easier with AI. So in the past, maybe a blocker would be, oh, my language just doesn't work in, or my app just doesn't work in German. pick your language, right? But now it's a lot easier is to adapt to your app. So I think for those reasons, international has been a lot faster. At the same time, right, like we also want to make sure that we're not getting spread too thin. And so it's kind of this balance where it's like

very unclear what the perfect answer is. But, you know, we've kind of made a determination of like which markets were okay with really investing in. And if we're going to invest, we're going to really invest. And generally those markets are ones where we've already just like naturally picked up some customers out of the U.S. office or something. Yeah. And then now it's like time to deploy people. Because, yeah, even though these, there are these trends that make it easier to go internationally, like, you know, there's also other things that you don't really think

about, right? Like, you have to have data residency. There's all these things where there's like local competitors, which are, you just know the market a lot better. And so you have to navigate that well. Yeah. Absolutely. So I think there is like a space for,

like local competitors to the large categories that we know about? I mean, there is space for them. I think the question is like long-term is their consolidation. And it's, you can see that for both the geographies, but also verticals. And then also market segments, right? So, like, there are going to be people that find their niche in different places. Like, our view, the reason why we've kind of built so horizontally is that we believe that in our space, the winners are going to be horizontal.

There's just not that much that is like super verticalized that where like you could see a pure vertical solution surviving. And historically that's just been true in our space, right? Like Salesforce is very horizontal, Zendes, very horizontal. Like all these solutions are very horizontal because you just gain more from having that scale and having a very robust and deep product than you do from like having very vertical specific features. And over time, we're also going to build, you know, vertical features into it. But our view is that like from a vertical and sort of market point of view, there will be consolidation. Just sort of unrelated to consolidation, but maybe not just geographic consolidation. I'm curious if AI concierge becomes really the interface between the business and its customers,

do you see, like how does CRM and all of these, you know, sort of traditional data, very, very important systems of record, right, for the end customer. How do those evolve in this new world? And do you see any consolidation there in terms of your own role? Yeah. I don't think it's necessarily in either or, right? Because ultimately, what we're doing here is trying to democratize access or availability of these consortia issues, right? Which is if you were going to business where you are spending $100,000 a year, you would get the most personalized treatment. They would know exactly who you are, what your preferences were. They want to help you, you know, shop, for instance. They'll shut the whole store down for you. Actually, I don't know if they do that

for $100,000. But you get the general. You've never, you've never tried that before. However, if you're at a business where you're spending $10, they can't do this for you because they can't make it economical, right? It is not a lack of desire to do this for their customers. It is just that the unit economics don't support that. And so effectively all we're doing here is saying, okay, if you couldn't give them that experience for 10 cents, all of a sudden it is economical and they'd want to do that. Now, to the point of, does that mean CRMs go away?

I mean, my answer is no, because if you have a company today where your concierge is a human, being. Yeah. They still write your info in a CRM so they can track it for later. So, and I think when we have these AI agents, they will need somewhere to put that information. Mm-hmm. So I don't necessarily think those kind of auxiliary pieces of software go away.

Mm-hmm. Because for us, as we're building these conciergeurs, our goal really is how do we create that great experience? We will still need places to put that data somewhere. Right. Yeah. I actually think CRMs could do quite well. They'll be slight different in the sense of like CRMs are kind of databases in a way. And, you know, the frustration people have with them sometimes is that the interfaces are really difficult to use, etc. But in the future, maybe the agents are just using the interfaces and you don't even have graphical interfaces or whatever. And so the CRMs are still very valuable because they hold the source of truth. And, you know, then the agents, there's just got. not getting pinged a lot more because the agents are using them. So that is one possible world.

So that's kind of bullish on CRMs. And for us personally, like, so far with Deccan, there's like we have zero desire to build a CRM because we think there's so much to do in the agentic layer. And that's where we want to focus. Yeah. Okay. So SaaS is not dead.

Cool. Maybe last thing is we were chatting right before we started recording that you guys have done some little AI experimentation on your own as you just figure out how to, you know, make your own life more productive and effective. And Austin would sound like you've done something kind of interesting. Yeah. You know, I think the models have gotten very smart over the last several years. And, you know, the two of us will often use it to brainstorm ideas, right?

Because they are genuinely very smart at coming up with great ideas. However, the bottleneck, I realize at least for a lot of the work that I do, is business context. right? There's a lot of context for every idea around, okay, the constraints that we have, the goals that we're going for and things I've had that is difficult to re-explain to the agents every time. And so I actually spent a while building agents for myself to capture all the business context well. So it just kind of looks over my shoulder all the time and is constantly compiling context on, oh, here are the people that we've hired. Here are the people that we need to hire. Here are the deals that we're working on.

Here are the problems. Here are the current challenges that we have. So that later on, I can just go to it and say, hey, there's this new person that we're thinking of hiring. What do you think? And now it's able to automatically be reasonable. Well, we had two candidates that were very similar. And, you know, these candidates had these kind of drawbacks or skills that they didn't

have. And so if we hire this person, it's going to be another person that has those, you know, kind of exact same things. So we need someone complimentary. So this is probably not the best person to have. Or, you know, in this deal, we're barreling down a very similar path because, you know, we didn't validate these things early enough. So this time we should validate them slightly earlier. So it's really all about how do you capture context well?

Because then, you know, my job is making decisions with lots of context. So if I can outsource that more and more tomorrow, maybe I can put myself on a job quicker. Sounds like you created Jesse. There we go. I like to create ourselves. I think one of the big struggles of being a solo founder is you don't have anyone to bounce ideas off of, so you just arrive at conclusions a lot slower. You guys were both solo founders in the past. Yeah, so like us working together, I think the reason it was so much easier is that we could, you know, iterate on things much faster.

You can I just talk something out. And yeah, now you talk to fable or whatever. It's like pretty good, honestly. You seem like very original. Because in the past it's just like they just kind of are kind of. a sick offense, right? Or they just agree with you. Oh, it's a good idea.

But now they're like, no, that's a bad idea. Don't do that. I actually, for a while, Mark at one point had posted the prof that he used for Claude. It's like, you know, disagree with me, be very dirty, things like that. So I actually used that for one. It was great. The funny story on this was, I really enjoyed because it would agree with me very aggressively. It would disagree with me very aggressively.

and I'd take it to my wife and I was like, oh, this is great and you should use it, she put it on. And then, you know, a day later, she was like, wow, Claude was being so mean to me all day. I had to turn it up. I'm like, and just kept telling me.

Yeah, it was a disagreement on me so aggressively. Amazing. Well, since we're on this topic of founders using AI to do things, I have to bring up the whole AI slop fiasco, is a strong word that Brian Chesky just went through. And I want to bring it up because you both

have grown your profile a lot over these last few years. And, you know, I sort of mentioned, Jess, you had these pieces that were just hitting the zeitgeist of the discussion that everyone wanted to have and came in with a very differentiated take. And, you know, that's the kind of stuff that we see exactly hit on, you know, you're hitting the conversation right at the, you know, right message, right time, unique message, right time. Do you use AI for writing? And separately, this is more of a meta question, but how important is X and like the sentiment on X to you?

So, yeah, for most of our early days, it was mostly on LinkedIn with the reasoning of like, hey, our customers are on LinkedIn. You know, we're not going to get someone seeing us on Twitter and then coming as a customer probably. But I think the sort of learning we had with that, is, or at least I was kind of reflecting on it. X is kind of like the timeline that people talk about. And most of that timeline is not really about your company. Like if you're if you're very like just like promoting yourself on X, like it's going to get no traction whatsoever.

Totally. But it is sort of like a single timeline that everyone reads. So it kind of like it kind of like my controls everyone to be thinking about the same thing. Yes. And that's where it's valuable to have some say in it. And who was just like listening to? There's like, there's this guy like Jeremy Giffon or something who's on Patrick O'Shaughnessy's podcast, I like, and you like doing, he like made some claim about how like, you know, it used to be that like the big status symbols in the world is like everyone wants to be a billionaire because like he calls it like the priest class or whatever. So it's like, billionaires are the priest class. But nowadays, actually it's when people become billionaires, now they want to become ex-influencers. because like those people hold the real power

because they can like influence what the whole world's thinking about. So that's like one reason to have some presence on X, I suppose. And when we, now when I post on X, I don't really post about like DeCon specifically. It's more about, you know,

our thoughts on what is happening. So I think that's like a good, good way to do it. And but it is very different. You write it all yourself, right? Yeah. I mean, AI is good for sort of helping you brainstorm like what topics to write about.

I think that's pretty good. But I think that's kind of learning that like LinkedIn and X work very differently. You can't just like come up with something cool and like post the same thing on both. Because like very few things like do well on both. Yeah. So like LinkedIn's really good for, you know, classic stuff. You're making announcements and talking about your product and, you know, fundraise or whatever. I guess you can do fundraise on X as well.

but X is a lot more about kind of like place yourself on top of that single timeline that everyone's on. And is that, so is it too much of a simple, you know, simplification to say X for hiring, especially, you know, AI research talent, et cetera, maybe ecosystem as well

and then LinkedIn more for enterprise customers or are you actually seeing enterprise CIOs pay attention to X? Artribution's hard, obviously. Yeah, it's hard because, you know, I think you could say like, oh, well, you know, I made a post on X and then, you know, the people on the all-in podcast were talking about it. Like, CIOs definitely. Yes, I saw that. So it's like a, like indirectly, I'm sure we got like some eyeballs from CIOs. Like is the CIO themselves, like scrolling X all day? Maybe not. But if you are part of that major timeline, then you have, there's all these like secondary effects. And then, and then like reporters will reach out to like from my mainstream.

media. And then if they write about you, then like, Ashton was on the New York Times recently, you know, it's like, if they write about you, then those for sure get eyeballed. You were? That would just open so much stuff. Kimberly's only on X, so. You didn't put an X article, I didn't see it. I guess maybe the last question would be just since we touched on like hot button X topics. What, and this is kind of a serious one, actually, but it sort of reentered the narrative, I think,

with, you know, the anthropic video, and it's just sort of maybe never left the narrative, but it's on this concept as progress gets better around jobs. And the messaging around that is a sensitive topic, obviously, but it's interesting because I really think customer support was maybe the first end-to-end use case where you could really take an entire job, sorry, do an entire job, I should say.

Take is the wrong word. Versus coding was always, you know, pair programming to start with. How has that, you know, we sort of joked before, but, you know, we weren't really joking that AI is actually creating jobs. I'm curious, how do you turn that narrative on its head that folks are just losing their jobs, right? Like, do you see the up-leveling of folks with AI where, you know, maybe they were doing this job and now they're doing something else? Yeah, I mean, we see this all the time. Because if you recall earlier on when we were talking about, hey, what are we truly doing?

We found that, for a lot of our customers, there's actually just more demand for things like customer support than there's supply. Right? Where companies realize that they're like, okay, if our cost of doing customer support drops by 30%, most of them are not just immediately saying, okay, now what I will do is, you know, let go up 60% of my team. They're saying, okay, now that this thing, which is clearly valuable for my customers is much cheaper,

let me do more of it so that my customers retain for longer so that, you know, they don't turn off as much so that they activate sooner, things like that. You know, we had a customer in the early days. They, and this was, you know, probably two and a half years ago at this point, where they said, you know, our ticket volume, you know, the amount of customer support inquiries that we get per month was I think,

I think it was like $50,000 a month or something based on, you know, the existing surfaces that they had. Once they started using us, they said, wow, turned out our customers have a lot of problems. They said, let us make support more easily accessible, right? So instead of it just being in one part, like buried within a support panel, They're like, let's put support on every page and let's make it more prominent in places where people are more likely to get stuck.

Let's allow immediate support for even free users rather than only paying users. Right. So because of this kind of, there's more kind of leated demand for support than there is supply. So automating things doesn't necessarily result in just kind of people laying off their entire teams. That may be the best example of Jevin's paradox in real life that I've heard. So it's exactly. Yeah, I think it's like AI will kill jobs, but not careers in a way. Because like those jobs that are being done currently should not be done by humans.

Like they're very mundane and menial. It's like it's like a super high volume use case. And people are just like kind of picking out the phone. It's like, okay, let me click here, click here. And like, okay, here's the answer, right? And that should be done by AI. But there is actually like a near infinite amount of things that people could be doing to make their customers happier and, you know, take care of them more.

And so people end up doing those things and more and more of the mundane repeatable things will get each and up by AI. So that's what we think will happen. Jesse, I think on a podcast, maybe Patrick O'Shaughnessy's podcast a couple months ago, you would mention that even your customers, when they've been using BPO's for customer support instead,

you haven't actually seen like layoffs at the BPO. It just turns out that those employees have gone and done other things instead. Is that still true? Oh, I mean, it's, it really depends on the situation. So there are definitely scenarios where people use their BPO's a lot less or don't need the BPO anymore.

The other situations where they are not in cost-cutting mode whatsoever. And their goal is to either their business is growing so quickly they don't want to scale their operations along with their growth. And so with Dekkegon, they can kind of like keep the flat or whatnot.

Or it's actually we still need people but now there's all these other things they could be doing. and it could be more revenue generating things. You know, that's like a big area for us, Siemens. Like as the AI matures, you first start with these costs cutting use cases because those are easy, but then like revenue generating use cases should also be able to be done through this conversational interface.

So, yeah, it really depends on the customer, but, you know, we definitely have customers that have made massive changes. Actually, I like to end it on that uplifting note. And just to repeat what Jesse said, it may kill jobs but not careers. I love that. Thank you so much for joining us, guys. A pleasure to have you. Thanks for having us. Thanks for listening to this episode of the A16Z podcast. If you like this episode, be sure to like, comment, subscribe, leave us a rating or review, and share it with your friends and family. For more episodes, go to YouTube, Apple Podcast, and Spotify. Follow us on X and A16Z and subscribe to our

substack at A16z.com. Thanks again for listening, and I'll see you in the next episode. As a reminder, the content here is for informational purposes only. Should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast.

For more details, including a link to our investments, please see A16Z.com forward slash disclosures.